One document matched: draft-polk-ecrit-emergency-dialstring-00.txt
ECRIT Working Group James Polk
Internet-Draft Cisco Systems
Expires: Aug 27th, 2006 Feb 27th, 2006
Using the Session Initiation Protocol REGISTER Method
To Obtain an Emergency Dialstring
draft-polk-ecrit-emergency-dialstring-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27th, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Most efforts to address emergency calling challenges over IP (and
cellular technologies such as GSM, TDMA, CDMA, etc, for that matter)
have focused on locating the calling user in order to route the
emergency call set-up request to the appropriate Public Safety
Answering Point (PSAP). Little or no effort to date has focused on
informing the caller what dialstring sequence they may need to use
to initiate a call for emergency help. This document describes how
the Session Initiation Protocol (SIP) REGISTER Request message is
used to inform a user of which emergency dialstring (of the 60 known
dialstring choices around the world) they should use, for where they
are geographically.
Polk Expires August 27th, 2006 [Page 1]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Conventions used in this document . . . . . . . . . . . . 3
2. SIP Options to Provide Dialstring . . . . . . . . . . . . . . 3
3. Requirements on Transaction to Learn Dialstring . . . . . . . 4
4. Basic Assumptions About Location . . . . . . . . . . . . . . 5
5. Transaction Overview . . . . . . . . . . . . . . . . . . . . 6
6. Option #1 - SIP REGISTER with a Header . . . . . . . . . . . 6
6.1 New Emergency-Dialstring Header in SIP . . . . . . . . . . 6
6.2 Usage of Emergency-Dialstring Header Fields . . . . . . . . 7
6.3 Emergency Dialstring Option Tag . . . . . . . . . . . . . . 7
6.4 SIP Element Rules . . . . . . . . . . . . . . . . . . . . . 7
7. Option #2 - SIP REGISTER with a new event package . . . . . . 11
8. Option #3 - UA Performs a HTTP Query to a Remote Server . . . 11
9. Option #4 - SIP SUBSCRIBE With a New Event Packet . . . . . . 11
10. Examples of All Four Options . . . . . . . . . . . . . . . . 12
10.1 Example of Emergency-Dialstring Header Transaction . . . . 12
10.2 Example of SIP REGISTER Event Package Transaction . . . . 15
10.3 Example of HTTP Transaction . . . . . . . . . . . . . . . 15
10.4 Example of SIP SUBSCRIBE Event Package Transaction . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1 Normative References . . . . . . . . . . . . . . . . . . 16
14.2 Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . 17
1. Introduction
[ID-SOS] describes a universal emergency call URN to be used to
identify a call as an emergency call. This URN is not intended to
be dialed, but rather is to be used by the User Agent as an address.
The intention is to translate (as with any other dial plan) the
existing emergency dialstring to the universal URN.
In many countries, short codes are used as emergency dialstrings to
identify emergency calls. In others, a complete local telephone
number is needed. These dialstrings are locally specific, typically
by country, and may vary in length. In some countries, a single
dialstring is used ('999' is the dialstring for all emergency calls
in the United Kingdom). In other countries, there are different
dialstrings for different emergency services; '116' is the
dialstring for police in Switzerland, '117' is the dialstring for
fire.
Users are taught, often from a very early age, what the local
Polk Expires August 27th, 2006 [Page 2]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
dialstrings for emergency calls are, and it is not practical to
attempt to change the dialstring to a more uniform choice. When
using systems that permit roaming, local laws often require that
telephony systems recognize the local ("visited") emergency
dialstrings.
What is needed is a mechanism for a User Agent (or other device that
can place emergency calls) to learn the local emergency
dialstring(s) so that it can recognize an emergency call when that
numeric sequence is dialed by the user. This visited emergency
dialstring(s) may be displayed to the user in its screen when
learned, if the phone has that capability.
1.1 Conventions used in this document
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC
2119 [RFC2119], and indicate requirement levels for compliant
implementations.
2. SIP Options to Provide Dialstring
Fundamentally, there are 3 pieces of information specified in this
document to be requested, and responded with:
- an emergency dialstring,
- a Service Identifier
- a Country Code
The need for the emergency dialstring is self evident.
The reason for the Service Identifier, mentioned in [ID-SOS] and
[ID-DHC-DIAL], is to identify what type of emergency dialstring this
one is. Is this dialstring for police or fire or mountain-rescue?
In countries that have these choices, this is really important to
keep the existing functionality.
The reason for the Country Code is two-fold. First, it matches the
Service ID with the dialstring. In other words, having a Country
Code for of 'US', and a Service ID of 'police' wouldn't make sense
yet, because the US does not have this granularity. Secondly, this
is a means of requesting the Country Code when location is in a Geo
(Lat/Lon) format.
There are four options given here on how to get an emergency
dialstring to a SIP user agent:
Polk Expires August 27th, 2006 [Page 3]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
Option #1 - SIP REGISTER with a header in the request
Option #2 - SIP REGISTER with a new event package
Option #3 - UA performs a HTTP Query to a remote server
Option #4 - SIP SUBSCRIBE with a new event packet
The advantages of placing this function in a SIP REGISTER message is
that in travels with the device configuration. Meaning the UA would
learn of this information at boot time, with appropriate indicators
to tell the UA when the Registrar can and cannot perform this task.
Using a new event package creates more flexibility in what
information can be provided lateral to the dialstring, for example
what the dialstring 116 is for in Switzerland. This would require
two additional pieces of information: a ISO-3166 country code, and a
type of use field to indicate what exactly this dialstring is used
for. Most locations would have a single general purpose dialstring,
but others would want to use at least the different offerings they
have now. An event package also has the advantage of including more
than one dialstring while listing each unique type of use.
Constructing a dialstring request and response, to return at least
these 3 pieces of information in a SIP header is challenging and not
very flexible. It would be especially difficult, it appears, to
have multiple dialstrings returned in the same header in the
successful response to a REGISTER message.
Creating this capability in HTTP should be fairly straight forward,
but there have been some issues raised lately that not all HTTP
implementations are created equal, and this would force HTTP onto
every UA that wanted this capability, which may not be the case, and
may not be desired.
Here we talk about an HTTP server being any server running HTTP, and
not a necessarily (any or all) traditional Web-server(s).
It is possible that the same, or a similar, event package could be
used in a SIP SUBSCRIBE message as is suggested above for a REGISTER
message.
3. Requirements on Transaction to Learn Dialstring
The following are the requirements necessary for a UA to learn its
emergency dialstring in its registration transaction:
Req#1 - A (SIP or HTTP) user agent MUST be able to indicate it
requires an emergency dialstring during a transaction with a
remote entity.
Polk Expires August 27th, 2006 [Page 4]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
Req#2 - A (SIP or HTTP) user agent MUST be able to indicate it
requires an ISO country code during a transaction with a
remote entity.
Req#3 - A (SIP or HTTP) user agent SHOULD be able to indicate which
type of emergency dialstring it is seeking during a
transaction with a remote entity (i.e. only police or fire).
Req#4 - A (SIP or HTTP) user agent SHOULD be able to indicate more
than one type of emergency dialstring it is seeking during a
transaction with a remote entity (i.e. to a general request,
respond with all that apply in that location/country).
Req#5 - A server node (SIP Registrar Server or server running HTTP)
MUST recognize a request for an emergency dialstring from
the UA, then process and determine the emergency dialstring
for the UA based on a well-formed PIDF-LO by-value or by-
reference within the REGISTER Request message.
Req#6 - A server node (SIP Registrar or HTTP Server) MUST be able to
return the emergency dialstring, service ID, and country
code to a registering (SIP or HTTP) user agent during the
response part of the transaction.
Req#7 - A server node (SIP Registrar or HTTP Server) MUST be able to
respond with just a country code in the response of a
transaction with the user agent.
Req#8 - A server node (SIP Registrar or HTTP Server) MUST respond
with which type of service indication the emergency
dialstring is in the transaction response to the user agent.
Req#9 - A (SIP or HTTP) user agent MUST be able to include more than
one type of emergency dialstring in the response of a
transaction with the user agent.
Req#10 - A user agent MUST be able to request and update existing
information at any time the device can contact the server.
4. Basic Assumptions About Location
One basic assumption has to be made here: the UA knows its location,
either by-value or by-reference. Without this knowledge, any
request for the appropriate emergency dialstring would yield a known
to be valid answer, because there is such a list to choose from.
This document does not discuss how the UA was sent, retrieved or
knows its location; just that it has to know where it is, at least
at a country level, in order to expect a server to plausibly be able
to answer this request for information.
This document makes no assumptions nor dictates how a server
Polk Expires August 27th, 2006 [Page 5]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
determines which dialstring or dialstrings to return to the SIP or
HTTP UA from this request.
5. Transaction Overview
Here is the basic message flow of this transaction, regardless of
which option is chosen:
Here Alice is registering to a (SIP or HTTP) server.
Alice SIP or HTTP Server
[M1] Request
------------------------>
[M2] Response
<------------------------
From a "where in the request is the request indication for the
dialstring/service-ID/country-code"? It does not matter from a
messaging point of view. The request indication could be in a
Header or a new event package message body. The event package could
be different for what goes in a SIP REGISTER and SUBSCRIBE Request,
the transaction looks the same. It also looks similar to an HTTP
transaction, even it the message body is different.
The key facet of the request is two-fold:
- That the message contains location by-value or by-reference, and
- That the message requests what it seeks
This message MAY be a device boot time in each of these messages, or
it MAY be after device boot time with any of these messages.
6. Option #1 - SIP REGISTER with a Header
6.1 New Emergency-Dialstring Header in SIP
Communicating the emergency dialstring in a request or response can
be accomplished with a new header. The Emergency-dialstring header
would have the following syntax (The "token-nodot" production is
copied from [RFC3265]):
Emergency-dialstring = "Emergency-dialstring " HCOLON
Emergency-dialstring-value *(COMMA
Emergency-dialstring-value)
Emergency-dialstring-value = (numeric-string "." service-identifier /
option-tag)
numeric string = numeric-token
service-identifier = token-nodot
Polk Expires August 27th, 2006 [Page 6]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
option-tag = string
NOTE: we aren't sure this BNF is correct. The goal is to get this
Result as a Request:
Emergency-Dialstring: <psap.police; country-code=country>,
<psap.fire; country-code=country>
And this result in a Response (the example here is for the US):
Emergency-Dialstring: <911.psap; country-code=us>
6.2 Usage of Emergency-Dialstring Header Fields
The following table extends the values in Tables 2&3 of RFC 3261
[RFC3261].
Header field where proxy INV ACK CAN BYE REG OPT PRA
----------------------------------------------------------------
Emergency-dialstring Rr o - - - o o -
Header field where proxy SUB NOT UPD MSG REF INF PUB
----------------------------------------------------------------
Emergency-dialstring Rr o o o o - o -
This header is opaque to proxy servers. It has optional usage in
the INV [RFC3261], REG [RFC3261], OPT [RFC3261], SUB/NOT [RFC3265],
UPD [RFC3311], INF [RFC2976] and MSG [RC3428] - all these are
discussed in Section 8.
6.3 Emergency Dialstring Option Tag
This document creates a new option tag "emergency-dialstring" to be
used in Requires, Supported and Unsupported headers in SIP between
compliant SIP elements of this extension. At this time, the authors
do not see any need for this option tag to be placed in the
Proxy-Requires header, as this extension should be opaque to proxies
and merely propagated by B2BUAs. The IANA registration of this
option tag is in Section 11.
6.4 SIP Element Rules
Here are the behaviors of the relevant SIP elements within this
operation. This SIP extension is opaque to SIP Proxies, SHOULD be
copied unchanged from receiving request to transmitted request by
B2BUAs and SBCs.
Polk Expires August 27th, 2006 [Page 7]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
6.4.1 UAC Behavior with Emergency-Dialstring Header Option
A UAC wanting an appropriate emergency dialstring be returned during
registration process will do the following:
- The UAC SHOULD include emergency-dialstring Option-tag in a
Requires header, but MAY include option-tag in Supported header to
prevent initial 420 if Registrar doesn't understand this
extension.
- The UAC MUST include location in the REGISTER Request message,
by-value is RECOMMENDED, but MAY send location by-reference in
Location header [ID-SIP-LOC].
- The UAC SHOULD include a Location header in the request, with a
cid indication of where location is in the message body, even if
there is only one message body part.
- If the UAC has its location by-reference URI, it MUST include this
in the Location header of the REGISTER request, unless location
by-value is included. Both MUST NOT be included in the same
message.
- A UAC requesting an emergency dialstring MUST expect to receive a
server identifier and country code in the response.
- The UAC SHOULD use S/MIME to protect the PIDF-LO for e2e
confidentiality.
- The UAC MUST use TLS or IPSec for hop-by-hop confidentiality.
- Upon reception of the emergency dialstring, it is RECOMMENDED the
UAC display this dialstring on its screen for the user to see and
read. This display may be "on" continuously, or may fade after
some preconfigured period of time.
- A UAC MAY request this emergency dialstring with every REGISTER
Request, include a refresh, to ensure it has the freshest
information.
- There may be more than one valid emergency dialstring for where
the UAC is at the moment. The UAC MUST be prepared to receive
more than one dialstring in the Emergency-dialstring header.
- Each emergency dialstring returned from the Registrar SHOULD
augment, be included, in the UAC's digit-map as recognizable as an
emergency dialstring sequence for the user to use.
For example, a UAC from somewhere in Europe that travels to
Switzerland may already know that 112 is a valid emergency
dialstring. But through this extension, the UAC may learn that 116
Polk Expires August 27th, 2006 [Page 8]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
(police) and 117 (fire) are also valid in this jurisdiction.
6.4.2 Server Behavior with Emergency-Dialstring Header Option
A Registrar server understanding the concept of emergency
dialstrings will do the following:
- The Registrar MUST understand Emergency-Dialstring header and
emergency-dialstring option-tag in a Supported or Requires header.
- If the Registrar does not understand the emergency-dialstring
option-tag in a Requires header, the Registrar MUST reject the
message with a 420 (Bad Extension) Response, including the
emergency-dialstring option-tag in an Unsupported header.
- A Registrar MUST respond to an OPTIONS request with
emergency-dialstring option-tag in a Supported header with the
emergency-dialstring option-tag in an Unsupported header.
- Having understood the request to generate an emergency-dialstring,
the Registrar MUST look for location within the Request message to
determine where the UAC is geographically, or contact another
server, perhaps using another protocol, that can do this
operation.
- The Registrar MUST look for the Location header in the Request
message to indicate a location by-reference URI, or a cid value of
where the location message body part is in the overall message
body [ID-SIP-LOC].
- The Registrar MUST understand location by-reference, per
[ID-SIP-LOC] and fetch the PIDF-LO from remote server to
determine location of the UAC.
- The Registrar MUST understand the content-type
application/pidf+xml to properly parse the PIDF-LO fetched or from
the by-value message body .
- The Registrar MUST understand all 3 parts of the emergency
dialstring header.
- the Registrar MUST allow for the request of only the ISO country
code, but MAY respond with the emergency dialstring and service
identifier in the response.
- a request for an emergency dialstring MUST include a service
identifier in the response, with the default value being 'psap'.
- If more than one emergency dialstring is used or appropriate
within the UAC's current location, more than one dialstring MUST
be returned in the Emergency-dialstring header, separated by a ','
Polk Expires August 27th, 2006 [Page 9]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
(comma), with each dialstring partnered with the respective
service identifier
- The Registrar MUST use TLS for hop-by-hop Confidentiality of these
Transactions; IPSec usage is optional.
- The Registrar MUST adhere to the location retention and
distribution rules set in the PIDF-LO [RFC4119].
6.4.3 Error Conditions with Emergency-Dialstring Header Option
6.4.3.1 UAC Error Conditions
A user agent client, having included an Emergency-Dialstring
indication in a request message, receives an error response, will do
the following:
- If the UAC receives a 420 (Bad Extension), if it placed the
emergency-dialstring option tag in a Requires header, SHOULD
resend the REGISTER request, but place the emergency-dialstring
option tag in a Supported header.
- If the UAC sent a REGISTER with an emergency-dialstring option tag
in a Requires header, and receives a 503 (Service Unavailable)
from the Registrar with an emergency-dialstring option tag in a
Supported header, it knows the Registrar understood the request,
but could not complete dialstring request. The UAC SHOULD retry
registration with the emergency-dialstring option tag in a
Supported header.
- If the UAC receives a 415 (Unsupported Media type) from a
Registrar to the content-type application/pidf+xml, the UAC SHOULD
NOT attempt to send a PIDF-LO again to the Registrar, meaning the
UAC cannot ask for its emergency-dialstring from that SIP element.
6.4.3.2 Registrar Error Conditions to Header
A Registrar server understanding the concept of emergency
dialstrings will do the following:
- If the Registrar does not understand the emergency-dialstring
option tag in a Requires header, the proper response is a 420 (Bad
Extension), including emergency-dialstring option tag in an
Unsupported header
- If the Registrar does not understand the emergency-dialstring
option tag in a Supported header, the proper response is to convey
a lack of support for the option tag by including this in the
Unsupported header in the response message
Polk Expires August 27th, 2006 [Page 10]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
- If the Registrar does not understand the content-type
application/pidf+xml, the proper error response is a 415
(Unsupported Media type)
- an Unsupported header MUST be in the 415, which includes this
option tag
- If a Registrar server understands the concept of emergency
dialstrings, and receives a request for an emergency dialstring
from a UAC during registration in a Requires header, but for
whatever reason cannot complete this part of the transaction, the
server MUST return a 503 (Service Unavailable) response to the
UAC. The Registrar MUST include the emergency-dialstring option
tag in a Supported header to indicate this part of the request was
understood, but could not be performed at this time.
7. Option #2 - SIP REGISTER with a new event package
The creation of a new SIP REGISTER event package to request and
respond for a emergency-dialstring, service identifier and/or ISO
country-code in a request or response can be accomplished ...
This section to be completed soon
[The authors did not have time prior to the submission cut-off to
complete additional options to these requirements. We are sorry!]
8. Option #3 - UA Performs a HTTP Query to a Remote Server
The creation of a new HTTP Query to request and respond for a
emergency-dialstring, service identifier and/or ISO country-code in
a request or response can be accomplished ...
This section to be completed soon
[The authors did not have time prior to the submission cut-off to
complete additional options to these requirements. We are sorry!]
9. Option #4 - SIP SUBSCRIBE With a New Event Packet
The creation of a new SIP SUBSCRIBE event package to request and
respond for a emergency-dialstring, service identifier and/or ISO
country-code in a request or response can be accomplished ...
This section to be completed soon
[The authors did not have time prior to the submission cut-off to
complete additional options to these requirements. We are sorry!]
Polk Expires August 27th, 2006 [Page 11]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
10. Examples of All Four Options
This section illustrates only one of the four options at this time.
As soon as the event packages are completed in XML, they will be
incorporated into the text here. However, if any of these options
are not considered appropriate by the community, they will be
dropped like a burning pan you didn't realize was hot before you
picked it up.
Thank you for your patience...
10.1 Example of Emergency-Dialstring Header Transaction
Here is Alice's modified registration transaction.
Alice Registrar Server
[M1] REGISTER (with PIDF-LO, and Requires
plus Emergency-Dialstring headers)
------------------------>
[M2] 200 OK (with emergency-dialstring header)
<------------------------
The following message are *not* well-formed.
[Message 1 - REGISTER from Alice to Registrar Server]
REGISTER registrar-server@example.com SIP/2.0
Via: Alice
To: Alice
From Alice
Emergency-Dialstring: <psap.psap; country-code=country>
Requires: emergency-dialstring
Location: cid <foo>
Call-ID: 1
Content-type: application/pidf+xml
Content-Length: ...
cid <foo>
[PIDF-LO message body (not shown)]
[Message 2 - 200 OK from Registrar Server to Alice]
SIP/2.0 200 OK
Via: Alice
To: Alice
From Alice
Emergency-Dialstring: <911.psap; country-code=us>
Supported: emergency-dialstring
Polk Expires August 27th, 2006 [Page 12]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
Call-ID: 1
Content-Length: 0
Location is sent to the Registrar in the form of the [RFC 4119]
PIDF-LO message body in the above example. The Registrar is the
destination UAS of this message, so it can read all that is in the
message, even if encrypted. If the PIDF-LO is in a civic format,
the Registrar can easily read the country and state/province the UA
is in, and perhaps have its own mapping application/database of
country-to-dialstring process, perhaps this is farmed out to another
server. This will likely have to be sent to a back-end server if
the location in the PIDF-LO is in a coordinate format, as the
Registrar server shouldn't get bogged down in doing a coordinate-to-
dialstring mapping function, but it is possible.
This mapping function to a backend server, from the SIP Registrar's
point of view, should be independent of the ECRIT Mapping Protocol,
since that protocol's function is to return a PSAP URI from a given
PIDF-LO, but that protocol may evolve into including this function
down the road.
Here is a series of Emergency-Dialstring examples in Requests, with
their appropriate Response headers:
#1 - UA requests emergency-dialstring and (ISO) country-code within
the US:
In the SIP Request Message
Emergency-Dialstring: <psap.psap; country-code=country>
In the SIP Response Message
Emergency-Dialstring: <911.psap; country-code=us>
#2 - UA requests (ISO) country-code only within France:
In the SIP Request Message
Emergency-Dialstring: <0.0; country-code=country>
In the SIP Response Message
Emergency-Dialstring: <0.0; country-code=fr>
#3 - UA requests only the police emergency-dialstring, service
identifier and (ISO) country-code within Switzerland:
In the SIP Request Message
Emergency-Dialstring: <psap.police; country-code=country>
In the SIP Response Message
Emergency-Dialstring: <116.police; country-code=ch>
#4 - UA requests for the police and fire emergency-dialstrings,
Polk Expires August 27th, 2006 [Page 13]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
service Identifiers and (ISO) country-code within Switzerland:
In the SIP Request Message
Emergency-Dialstring: <psap.police; country-code=country>
<psap.fire; country-code=country>
In the SIP Response Message
Emergency-Dialstring: <116.police; country-code=ch>,
<117.fire; country-code=ch>
Which can also be returned like this (to be consistent with
[RFC3261]):
Emergency-Dialstring: <116.police; country-code=ch>
Emergency-Dialstring: <117.fire; country-code=ch>
Where there is no limit to the number of headers in the response.
An advantage of using the REGISTER method to learn a dialstring is
that the Registrar server can be anywhere in the world, and can
successfully answer the request for a dialstring, as long as the
Registrar can map the location of the user agent to a country's
emergency dialstring. This can be done internally within the
Registrar server, or through the ECRIT mapping protocol. This is
all at layer 7 with no direct interaction with the underlying
infrastructure. This mechanism is also independent of which access
and internet service provider is giving the user agent its
connectivity.
Section 6 showed the creation of a new SIP header to convey
emergency dialstring to the UAC from a Registrar Server. The
authors are not picky for this string, and offers these alternatives
in their header form:
EMTEL: <911.psap; country-code=us>
or
EmTel-dialstring: <911.psap; country-code=us>
or
Emergency-dialstring: <112.psap; country-code=fr>
or
P-Emergency-dialstring: <999.psap; country-code=uk>
The header value MUST limit the string to all numeric characters, as
that is what is on a typical phone's keypad.
Whenever an emergency dialstring is learned, or updated/modified, it
may be only temporarily displayed on the phone, or could remain on
the display whenever the phone is powered up. This document makes
no distinction as to the future use of this timing.
Polk Expires August 27th, 2006 [Page 14]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
10.2 Example of SIP REGISTER Event Package Transaction
To be completed...
10.3 Example of HTTP Transaction
To be completed...
10.4 Example of SIP SUBSCRIBE Event Package Transaction
To be completed...
11. IANA Considerations
This document will make IANA Registrations when one of the four
options to these requirements has been decided upon.
12. Security Considerations
A concern with this extension (in its current form) is making sure
the header field is not changed in transit between the Registrar
server and the UAC, as this could start a chain of events to occur
that will have a user dial the wrong emergency number during an
emergency. Therefore, message integrity is necessary. Normal SIP
mechanisms, such as using TLS or IPSec for message transmissions,
should suffice.
Message body confidentiality needs to be used to protect the PIDF-LO
message body to adhere to location information retention and
distribution rules. Normal SIP mechanisms, such as using TLS or
IPSec for message transmissions, as well as S/MIME encryption of the
message body, should suffice.
Learning a country's, or UAC's pertinent emergency dialstring could
reveal which country the user is in, but this will likely only get
coarse granularity to a set of countries or a continent (112 for all
of Europe, for instance). Proper security mechanisms mentioned
above will prevent any of this from revelation during transmissions.
13. Acknowledgements
To Brian Rosen for helping scope this effort by contributing to the
Intro section. To Marc Linsner for back this effort.
Polk Expires August 27th, 2006 [Page 15]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
14. References
14.1 Normative References
[ID-SOS] H. Schulzrinne, "A Uniform Resource Name (URN) for
Services", draft-ietf-ecrit-service-urn-00, "work in
progress", January 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", draft-
ietf-sip-location-conveyance-01.txt, "work in progress",
June 2005
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
14.2 Informative References
[ID-DHC-DIAL] J. Polk, "A Dynamic Host Configuration Protocol Option
for the Locally Significant Emergency Calling Dialstring",
draft-polk-dhc-emergency-dialstring-option-00, "work in
progress", February 2006
[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002
[RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000
[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging" , RFC 3428, December 2002
Author's Address
James M. Polk
3913 Treemont Circle
Colleyville, Texas 76034
USA
Phone: +1-817-271-3552
Email: jmpolk@cisco.com
Polk Expires August 27th, 2006 [Page 16]
Internet-Draft ECRIT SIP/HTTP Dialstring Feb 27th 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Polk Expires August 27th, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 15:52:50 |