< draft-winterbottom-ecrit-direct-00.txt   draft-winterbottom-ecrit-direct-01.txt >
ECRIT J. Winterbottom ECRIT J. Winterbottom
Internet-Draft M. Thomson Internet-Draft M. Thomson
Intended status: BCP Andrew Corporation Intended status: BCP Andrew Corporation
Expires: April 22, 2010 H. Tschofenig Expires: April 29, 2010 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
October 19, 2009 October 26, 2009
ECRIT Direct Emergency Calling ECRIT Direct Emergency Calling
draft-winterbottom-ecrit-direct-00.txt draft-winterbottom-ecrit-direct-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 22, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes a generic emergency calling client. The specified IETF emergency services architecture puts a strong
emphasis on emergency call and emergency messaging via the Voice
Service Provider (VSP) / Application Service Provider (ASP). There
are two reasons for this design decision: The call routing via the
VSP/ASP is more natural as it follows the standard communication
pattern and transition deployments assume non-updated end hosts.
As the deployment of the Location-to-Service Translation protocol
progresses there are possibilities for upgraded end devices to
directly communicate with the IP-based emergency services network
without the need to interact with a VSP/ASP, which simplifies the
task of regulators as the involved parties are within the same
jurisdiction.
This memo describes the procedures and operations of a generic
emergency calling client utilizing the available building blocks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The Jurisdictional Problem . . . . . . . . . . . . . . . . . . 5 3. The Jurisdictional Problem . . . . . . . . . . . . . . . . . . 7
4. Network Reference model . . . . . . . . . . . . . . . . . . . 6 4. ESRP Route Determination . . . . . . . . . . . . . . . . . . . 8
5. ESRP Route Determination . . . . . . . . . . . . . . . . . . . 7 5. Emergency Client Registration . . . . . . . . . . . . . . . . 9
6. Emergency Client Registration . . . . . . . . . . . . . . . . 8 6. Emergency Client Call Intitiation . . . . . . . . . . . . . . 13
7. Emergency Client Call Intitiation . . . . . . . . . . . . . . 12 7. Call Termination Control . . . . . . . . . . . . . . . . . . . 14
8. Call Termination Control . . . . . . . . . . . . . . . . . . . 13 8. SIP Feature Restrictions . . . . . . . . . . . . . . . . . . . 15
9. SIP Feature Restrictions . . . . . . . . . . . . . . . . . . . 14 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Test Registration . . . . . . . . . . . . . . . . . . . . 16
10.1. Test Registration . . . . . . . . . . . . . . . . . . . . 15 9.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . . . 17
11. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
15.1. Normative References . . . . . . . . . . . . . . . . . . 20 14.2. Informative References . . . . . . . . . . . . . . . . . . 22
15.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The current IETF ECRIT architecture, as described in The description of the IETF emergency services architecture, found in
[I-D.ietf-ecrit-phonebcp] and in [I-D.ietf-ecrit-framework], focuses [I-D.ietf-ecrit-phonebcp] and in [I-D.ietf-ecrit-framework], focuses
on devices where emergency calls are routed primarily through the on devices where emergency calls are routed primarily through the
subscriber's home VSP and the direct signaling communication between subscriber's home VSP and the direct signaling communication between
the end host and the PSAP that contains the IP-based PSAP is only an the end host and the Public Safety Answering Point (PSAP) that
exception. This is a convenient assumption if one considers the contains the IP-based PSAP is only an exception. This is a
regular communication patterns of the device and the potential convenient assumption if one considers the regular communication
proprietary protocol implementations used between the end host and patterns of the device and the potential proprietary protocol
the VSP and the ability to move the interoperability challenges away implementations used between the end host and the VSP and the ability
from the end device and closer to VSPs. There are, however, to move the interoperability challenges away from the end device and
challenges for regulators to enforce emergency services functionality closer to VSPs. There are, however, challenges for regulators to
when the VSP is located in a different jurisdiction with the current enforce emergency services functionality when the VSP is located in a
model. Inclusion of a VSP introduces unnecessary elements into the different jurisdiction. Inclusion of a VSP introduces unnecessary
emergency call path making the overall solution more cumbersome. elements into the emergency call path making the overall solution
more cumbersome.
This document describes the regulatory challenge and illustrates a With the help of the Location-to-Service Translation protocol a PSAP
model for direct communication between the end host and the PSAP that URI is discovered that allows the end device to directly send SIP
is supported by the basic SIP communication patterns. With the help
of the Location-to-Service Translation protocol a PSAP URI is
discovered that allows the end device to directly send SIP
communication requests towards the PSAP. communication requests towards the PSAP.
Note that the information returned by LoST may not necessarily be the Note that the information returned by LoST may not necessarily be the
address of the PSAP itself but might rather be an entity that gets address of the PSAP itself but might rather be an entity that gets
the emergency call closer to the PSAP by returning the address of an the emergency call closer to the PSAP by returning the address of an
Emergency Services Routing Proxy (ESRP). Emergency Services Routing Proxy (ESRP).
This memo attempts to address the issues raised above and describe The intent of this client is that it will be able to use the
the requirements, procedures and operations necessary for a generic available ECRIT building blocks to allow any IP enabled device with
IP emergency calling client. The intent of this client is that it access to the Internet to make an emergency call without requiring
will be able to use the available ECRIT building blocks to allow any the signaling interaction with the VSP. In fact, there is no
IP enabled device with access to the Internet to make an emergency assumption or requirement for a VSP subscription to exist. The
call without requiring a voice service subscription. Further more, a interacting entities are shown in Figure 1.
means for call-back in the event of a dropped call is also described.
.... ....
,' ',' ',
; ;
+--------+ ; ; +------+
| Device |--->: ISP :----->| ESRP |
+--------+ ; ; +------+
`, ,', ,'
, , , ,
```` ````
Figure 1: Network Configuration
Furthermore, a means for call-back in the event of a dropped call is
also described.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. The Jurisdictional Problem 3. The Jurisdictional Problem
The jurisdictional problem is illustrated with Figure 1 that The jurisdictional problem is illustrated with Figure 2 that
highlights that providing the data in the Location Information Server highlights that provided the data in the Location Information Server
(LIS) and the LoST server are correct, that the caller and the PSAP (LIS) and the LoST server are correct, that the caller and the PSAP
are assured of being in the same regulatory jurisdiction. This is are assured of being in the same regulatory jurisdiction. This is
important, because it shows that it is the access component of the important, because it shows that it is the access component of the
network and not the service component against which reguatory network and not the service component against which reguatory
obligations can be imposed with any hope of enforcement. Regulation obligations can be imposed with any hope of enforcement. Regulation
without the possibility of enforcement is challenging as there is without the possibility of enforcement is challenging as there is
very little coordination between regulators world wide in this area, very little coordination between regulators world wide in this area,
consequently any emergency calling procedure should ensure that all consequently any emergency calling procedure should ensure that all
nodes against which the procedures apply fall within the same nodes against which the procedures apply fall within the same
regulatory boundary. regulatory boundary.
+-----+ +-----+
| VSP | | VSP |
| # | | # |
+-----+ +-----+
o-------------o----------------------o-------------o o-------------o----------------------o-------------o
/ \ / \
/ +---------+ +--------+ \ / +---------+ +--------+ \
/ | Access \ ASSURED / ESINet \ \ / | Access \ / ESINet \ \
o | Network \ / \ o o | Network \ / \ o
| + + COMMON + O + | | + + + O + |
| / O | / <P\ | | | / O | / <P\ | |
| + <C\ o REGULATORY + /'\ + | | + <C\ o REGULATORY + /'\ + |
| | /'\ / | PSAP / o | | /'\ / | PSAP / o
o + Caller + JURISDICTION + +-------+ + / o + Caller + JURISDICTION + +-------+ + /
\ \ __________| \ / \/ / \ \ __________| \ / \/ /
\ / \ /
o--------------o----------------------o---------------o o--------------o----------------------o---------------o
Figure 1: Jurisdictional Boundaries in Internet Emergency Calling Figure 2: Jurisdictional Boundaries in Internet Emergency Calling
4. Network Reference model
In many deployments today the emergency calling device is located
behind a NAT or a firewall, and there is no assumption or requirement
for a VSP subscription to exist. Figure 2 illustrates such a typical
scenario. Indeed any subscription of this nature is immaterial to
the operation described in this memo.
.... ....
,' ',' ',
+----------+ ; ;
+--------+ | Firewall | ; ; +------+
| Device |--->| NAT | --->: ISP :----->| ESRP |
+--------+ +----------+ ; ; +------+
`, ,', ,'
{ } { }
```` ````
Figure 2: Network Configuration
5. ESRP Route Determination 4. ESRP Route Determination
The ESRP is discovered by the emergency client obtaing its location The ESRP is discovered by the emergency client obtaing its location
from a LIS, for example, using HELD, and then using LoST to resolve from a LIS, for example, using HELD, and then using LoST to resolve
the location and 'urn:services.sos' Service URN to the ESRP URI. the location and 'urn:services.sos' Service URN to the ESRP URI.
When the emergency client is started the device needs to perform LIS When the emergency client is started the device needs to perform LIS
and LoST server discovery, as described in Section 7 of and LoST server discovery, as described in Section 7 of
[I-D.ietf-ecrit-phonebcp]. [I-D.ietf-ecrit-phonebcp].
The emergency client MUST support location acquisition and the LCPs The emergency client MUST support location acquisition and the LCPs
skipping to change at page 8, line 5 skipping to change at page 9, line 5
serviceListBoundary extension defined in serviceListBoundary extension defined in
[I-D.ietf-ecrit-lost-servicelistboundary]). The service options may [I-D.ietf-ecrit-lost-servicelistboundary]). The service options may
be presented to the emergency caller in a graphical fashion and once be presented to the emergency caller in a graphical fashion and once
a specific service is selected a LoST query would be initiated a specific service is selected a LoST query would be initiated
(unless a cached mapping is available that makes this request (unless a cached mapping is available that makes this request
obsolete). The LoST <findService> query to obtain the ESRP URI for obsolete). The LoST <findService> query to obtain the ESRP URI for
the selected service is in this example initiated at the time the the selected service is in this example initiated at the time the
emergency call setup is performed. It is recommended that ESRP emergency call setup is performed. It is recommended that ESRP
discovery occurs at call time. discovery occurs at call time.
6. Emergency Client Registration 5. Emergency Client Registration
Emergency registration is only necessary when an emergency call Emergency registration is only necessary when an emergency call
procedure is initiated. Immediately prior to making an emergency procedure is initiated. Immediately prior to making an emergency
call, the emergency client performs a SIP emergency registration with call, the emergency client performs a SIP emergency registration with
the registrar in the ESRP, the ESRP-registrar. The emergency the registrar in the ESRP, the ESRP-registrar. The emergency
registration is a SIP registration with specific options and headers registration is a SIP registration with specific options and headers
which are required in order to guard the emergency network and ensure which are required in order to guard the emergency network and ensure
callback should it be required. callback should it be required.
Each emergency client MUST provide an instance-id, as defined in Each emergency client MUST provide an instance-id, as defined in
[I-D.ietf-sip-outbound], this allows the ESRP-registrar to generate a [I-D.ietf-sip-outbound], this allows the ESRP-registrar to generate a
GRUU [I-D.ietf-sip-gruu] that can be used as a callback identifier. GRUU [RFC5627] that can be used as a callback identifier. A GRUU is
A GRUU is necessary as the callback identifier because the emergency necessary as the callback identifier because the emergency client
client does not provide a longer-term contact address to the ESRP- does not provide a longer-term contact address to the ESRP-registrar
registrar prior to registration, and the GRUU provides a handle by prior to registration, and the GRUU provides a handle by which the
which the PSAP can identify the calling emergency client. To PSAP can identify the calling emergency client. To simplify the
simplify the emergency client and ESRP-registrar implementations, emergency client and ESRP-registrar implementations, only public
only public GRUUs are provided by the ESRP-registrar. The public GRUUs are provided by the ESRP-registrar. The public GRUU is
GRUU is guaranteed to be the same for a device regardless of re- guaranteed to be the same for a device regardless of re-registration
registration with a different call-id, which may occur if the device with a different call-id, which may occur if the device unexpectedly
unexpectedly reboots. This is not true for temporary GRUUs, which reboots. This is not true for temporary GRUUs, which makes temporary
makes temporary GRUUs undesriable in the scope of this application GRUUs undesriable in the scope of this application space.
space.
The PSAP is able to define and mandate the time over which callback The PSAP is able to define and mandate the time over which callback
is possible. This needs to be a reasonable period of time, nominally is possible. This needs to be a reasonable period of time, nominally
10s of minutes, as the device may well be transient with regards to 10s of minutes, as the device may well be transient with regards to
network attachment. The ESRP-registrar reflects the regulatory network attachment. The ESRP-registrar reflects the regulatory
callback period in the expiry value of emergency registration callback period in the expiry value of emergency registration
responses. Emergency clients claiming compliance to this responses. Emergency clients claiming compliance to this
specification MUST honour the value in the registration response from specification MUST honour the value in the registration response from
the ESRP-registrar, up to a maximum of 60 minutes. An emergency the ESRP-registrar, up to a maximum of 60 minutes. An emergency
client SHOULD respect a registration expiry of longer than 60 client SHOULD respect a registration expiry of longer than 60
minutes, but MAY terminate its registration with and ESRP-registrar minutes, but MAY terminate its registration with and ESRP-registrar
at 60 minutes if the expiry value provided by the ESRP-registrar was at 60 minutes if the expiry value provided by the ESRP-registrar was
longer. longer.
In the event that a registration is lost by the emergency client In the event that a registration is lost by the emergency client
prior to reaching registration expiry then the emergency client MUST prior to reaching registration expiry then the emergency client MUST
re-register with the ESRP-registrar and SHOULD use the same call-id. re-register with the ESRP-registrar and SHOULD use the same call-id.
In this circumstance the ESRP-registrar SHOULD match the instance-id In this circumstance the ESRP-registrar SHOULD match the instance-id
and the call-id to recognize that it is a re-registration for a and the call-id to recognize that it is a re-registration for a
dropped connection, and expiry time in the registration response dropped connection, and expiry time in the registration response
SHOULD be set to the time remaining from the original registration SHOULD be set to the time remaining when the original registration
occurred. occurred.
[I-D.ietf-sip-outbound] requires a device to support at least 2 [I-D.ietf-sip-outbound] requires a device to support at least 2
registrations to different proxies. The emergency client registrations to different proxies. The emergency client
requirements in this memo relax this requirement down to one requirements in this memo relax this requirement down to one
registration, but more than one is allowed. There are several registration, but more than one is allowed. There are several
reasons for relaxing the connection redundancy requirement. Firstly, reasons for relaxing the connection redundancy requirement. Firstly,
ESRPs are expected to have inbuilt redundancy, so if a connection is ESRPs are expected to have inbuilt redundancy, so if a connection is
dropped due to a failed proxy in the ESRP, then a new connection or dropped due to a failed proxy in the ESRP, then a new connection or
registration will automatically be directed to an active proxy in the registration will automatically be directed to an active proxy in the
skipping to change at page 10, line 5 skipping to change at page 11, line 5
the LIS address using the mechanism described in the LIS address using the mechanism described in
[I-D.thomson-geopriv-res-gw-lis-discovery]. The ESRP-registrar [I-D.thomson-geopriv-res-gw-lis-discovery]. The ESRP-registrar
MAY use other methods for LIS determination where available. MAY use other methods for LIS determination where available.
2. If the REGISTER message contains a location URI then the ESRP- 2. If the REGISTER message contains a location URI then the ESRP-
registrar MUST dereference it so that it has a location available registrar MUST dereference it so that it has a location available
to route the impending emergency call. The ESRP-registrar MAY to route the impending emergency call. The ESRP-registrar MAY
validate the LIS address in the location URI with that of the LIS validate the LIS address in the location URI with that of the LIS
serving the network from which the REGISTER message originated. serving the network from which the REGISTER message originated.
LIS determination MAY be performed using the methods described in
[I-D.thomson-geopriv-res-gw-lis-discovery].
3. The REGISTER message contains location information by value. Any 3. The REGISTER message contains location information by value. Any
actions performed by the ESRP-registrar to valid this information actions performed by the ESRP-registrar to valid this information
are specific to the jurisdiction in which the ESRP operates and are specific to the jurisdiction in which the ESRP operates and
are out of the scope of this document. are out of the scope of this document.
Where location conveyance is used confidentiality protection SHOULD Where location conveyance is used confidentiality protection SHOULD
be provided using Transport Layer Security (TLS). be provided using Transport Layer Security (TLS).
Figure 3 show the registration message exchange graphically. Figure 3 show the registration message exchange graphically.
skipping to change at page 10, line 41 skipping to change at page 11, line 38
| | | | | | | |
+------------------------REGISTER------------------------>+ +------------------------REGISTER------------------------>+
| | | | | | | |
| +<------locationRequest-----------+ | +<------locationRequest-----------+
| | | | | | | |
| +-------locationResponse--------->+ | +-------locationResponse--------->+
| | | | | | | |
+<-------------------------200 OK ------------------------+ +<-------------------------200 OK ------------------------+
| | | | | | | |
Figure 3: Registration message flow Figure 3: Example Registration Message Flow
REGISTER sip:sos.example.com SIP/2.0 REGISTER sip:sos.example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70 Max-Forwards: 70
From: anon <sip:anon@sos.example.com>;tag=7F94778B653B From: anon <sip:anon@sos.example.com>;tag=7F94778B653B
To: anon <sip:anon@sos.example.com> To: anon <sip:anon@sos.example.com>
Call-ID: 16CB75F21C70 Call-ID: 16CB75F21C70
CSeq: 1 REGISTER CSeq: 1 REGISTER
Geolocation: <https://lis.access.example.com:9192/suXweu838737d72> Geolocation: <https://lis.access.example.com:9192/suXweu838737d72>
;inserted-by="anon@192.0.2.2" ;inserted-by="anon@192.0.2.2"
skipping to change at page 11, line 27 skipping to change at page 12, line 27
;routing-allowed=no ;routing-allowed=no
Require: gruu, geolocation Require: gruu, geolocation
Supported: outbound, gruu Supported: outbound, gruu
Contact: <sip:anon@192.0.2.2;transport=tcp> Contact: <sip:anon@192.0.2.2;transport=tcp>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
Figure 4: Sample REGISTER message Figure 4: Sample REGISTER message
Since the emergency client does not have a nominal domain, it MUST Since the emergency client does not have a domain, it MUST register
register in the same domain as the ESRP. This is illustrated in the in the same domain as the ESRP. This is illustrated in the example
example REGISTER message show in Figure 4. REGISTER message show in Figure 4.
7. Emergency Client Call Intitiation 6. Emergency Client Call Intitiation
Immediately subsequent to the registration a SIP INVITE request is Immediately subsequent to the registration a SIP INVITE request is
sent to the ESRP in the following form: sent to the ESRP in the following form:
1. The Request URI MUST be the service URN [RFC5031] in the "sos" 1. The Request URI MUST be the service URN [RFC5031] in the "sos"
tree. tree.
2. The To header MUST be a service URN in the "sos" tree. 2. The To header MUST be a service URN in the "sos" tree.
3. The From header MUST be present and MUST be the public GRUU 3. The From header MUST be present and MUST be the public GRUU
returned from the registration with the ESRP-registrar. returned from the registration with the ESRP-registrar.
4. A Route header MUST be present with an ESRP URI, obtained from 4. A Route header MUST be present with an ESRP URI, obtained from
LoST. LoST.
5. A Contact header MUST be present and contain the public GRUU 5. A Contact header MUST be present and contain the public GRUU
[I-D.ietf-sip-gruu], and be valid for several minutes following [RFC5627], and be valid for several minutes following the
the termination of the call, provided that the UAC remains termination of the call, provided that the UAC remains registered
registered with the same registrar, to permit an immediate call- with the same registrar, to permit an immediate call-back to the
back to the specific device which placed the emergency call. specific device which placed the emergency call.
6. A SDP offer MUST be included in the INVITE. If voice is 6. A SDP offer MUST be included in the INVITE. If voice is
supported the offer MUST include the G.711 codec, see Section 14 supported the offer MUST include the G.711 codec, see Section 14
of [I-D.ietf-ecrit-phonebcp]. of [I-D.ietf-ecrit-phonebcp].
7. SIP Caller Preferences [RFC3841] SHOULD be used to signal how the 7. SIP Caller Preferences [RFC3841] SHOULD be used to signal how the
PSAP should handle the call. For example, a language preference PSAP should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint to expressed in an Accept-Language header may be used as a hint to
cause the PSAP to route the call to a call taker who speaks the cause the PSAP to route the call to a call taker who speaks the
requested language. SIP Caller Preferences may also be used to requested language. SIP Caller Preferences may also be used to
indicate a need to invoke a relay service for communication with indicate a need to invoke a relay service for communication with
people with disabilities in the call. people with disabilities in the call.
8. Call Termination Control 7. Call Termination Control
The description in [I-D.rosen-ecrit-premature-disconnect-rqmts] is The description in [I-D.rosen-ecrit-premature-disconnect-rqmts] is
relevant for this document. relevant for this document.
9. SIP Feature Restrictions 8. SIP Feature Restrictions
The functionality defined in Section 9.3 in [I-D.ietf-ecrit-phonebcp] The functionality defined in Section 9.3 in [I-D.ietf-ecrit-phonebcp]
regarding disabling of certain features is relevant for this document regarding disabling of certain features is relevant for this document
and an emergency client MUST NOT implement the the features listed in and an emergency client MUST NOT implement the the features listed in
ED-70, and ED-71. ED-70, and ED-71.
10. Testing 9. Testing
The description in Section 15 of [I-D.ietf-ecrit-phonebcp] regarding The description in Section 15 of [I-D.ietf-ecrit-phonebcp] regarding
emergency call testing is used by this specification. Since this emergency call testing is used by this specification. Since this
specification mandates a registration with the ESRP-registrar a specification mandates a registration with the ESRP-registrar a
similar tagging URI to that described in similar tagging URI to that described in
[I-D.patel-ecrit-sos-parameter] is used to indicate a test [I-D.patel-ecrit-sos-parameter] is used to indicate a test
registration. registration.
Test registrations SHALL be of short durations, but MUST be long Test registrations SHALL be of short durations, but MUST be long
enough to allow completion of a "test call" as described in enough to allow completion of a "test call" as described in
[I-D.ietf-ecrit-phonebcp]. [I-D.ietf-ecrit-phonebcp].
10.1. Test Registration 9.1. Test Registration
When the emergency client sends a REGISTER request for emergency test When the emergency client sends a REGISTER request for emergency test
registration, the "sos.test" URI parameter MUST be appended to the registration, the "sos.test" URI parameter MUST be appended to the
URI in the Contact header. This indicates to the ESRP-registrar that URI in the Contact header. This indicates to the ESRP-registrar that
the request is for emergency test registration. the request is for emergency test registration.
... ...
Contact: <sip:anon@192.0.2.2;transport=tcp;sos.test> Contact: <sip:anon@192.0.2.2;transport=tcp;sos.test>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>" ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
Figure 5: Test REGISTER Message Fragment Figure 5: Test REGISTER Message Fragment
Only one Contact header field SHOULD be included in the emergency Only one Contact header field SHOULD be included in the emergency
REGISTER test request. If more than one Contact header is included REGISTER test request. If more than one Contact header is included
then the presence of the "sos.test" URI in any of the Contact fields then the presence of the "sos.test" URI in any of the Contact fields
SHALL result in the ESRP-registrar treating the registration as a SHALL result in the ESRP-registrar treating the registration as a
test registration. test registration.
10.2. Format 9.2. Format
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in [RFC5234]. Form (BNF) as described in [RFC5234].
The "sos.test" URI parameter is a "uri-parameter", as defined by The "sos.test" URI parameter is a "uri-parameter", as defined by
[RFC3261]. [RFC3261].
uri-parameter =/ sos-param-test uri-parameter =/ sos-param-test
sos-param-test = "sos.test" sos-param-test = "sos.test"
11. PSAP Callback 10. PSAP Callback
PSAP callback occurs as described in PSAP callback occurs as described in
[I-D.schulzrinne-ecrit-psap-callback]. [I-D.schulzrinne-ecrit-psap-callback].
12. Security Considerations 11. Security Considerations
TBD TBD
13. IANA Considerations 12. IANA Considerations
This specification defines one new SIP URI parameter, as per the This specification defines one new SIP URI parameter, as per the
registry created by [RFC3969]. registry created by [RFC3969].
Parameter Name: sos.test Parameter Name: sos.test
Predefined Values: none Predefined Values: none
Reference: [RFCXXXX] Reference: [RFCXXXX]
[NOTE TO IANA: Please replace XXXX with the RFC number of this [NOTE TO IANA: Please replace XXXX with the RFC number of this
specification.] specification.]
14. Acknowledgements 13. Acknowledgements
Thanks to Elaine Quah for being a sounding board. Thanks to Elaine Quah for being a sounding board.
15. References 14. References
15.1. Normative References 14.1. Normative References
[I-D.ietf-ecrit-phonebcp] [I-D.ietf-ecrit-phonebcp]
Rosen, B. and J. Polk, "Best Current Practice for Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-13 (work in progress), draft-ietf-ecrit-phonebcp-13 (work in progress),
July 2009. July 2009.
[I-D.ietf-geopriv-held-identity-extensions] [I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R. Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", Delivery (HELD)",
draft-ietf-geopriv-held-identity-extensions-01 (work in draft-ietf-geopriv-held-identity-extensions-01 (work in
progress), October 2009. progress), October 2009.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C., "Managing Client Initiated Connections in Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 2009. draft-ietf-sip-outbound-20 (work in progress), June 2009.
[I-D.ietf-sipcore-location-conveyance] [I-D.ietf-sipcore-location-conveyance]
Polk, J. and B. Rosen, "Location Conveyance for the Polk, J. and B. Rosen, "Location Conveyance for the
Session Initiation Protocol", Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-01 (work in draft-ietf-sipcore-location-conveyance-01 (work in
progress), July 2009. progress), July 2009.
[I-D.schulzrinne-ecrit-psap-callback] [I-D.schulzrinne-ecrit-psap-callback]
Schulzrinne, H. and H. Tschofenig, "Marking of Calls Schulzrinne, H., Tschofenig, H., and M. Patel, "Public
initiated by Public Safety Answering Points (PSAPs)", Safety Answering Point (PSAP) Callbacks",
draft-schulzrinne-ecrit-psap-callback-00 (work in draft-schulzrinne-ecrit-psap-callback-01 (work in
progress), March 2009. progress), October 2009.
[I-D.thomson-geopriv-res-gw-lis-discovery] [I-D.thomson-geopriv-res-gw-lis-discovery]
Thomson, M. and R. Bellis, "Location Information Server Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery From Behind Residential Gateways", (LIS) Discovery From Behind Residential Gateways",
draft-thomson-geopriv-res-gw-lis-discovery-02 (work in draft-thomson-geopriv-res-gw-lis-discovery-02 (work in
progress), July 2009. progress), July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 21, line 30 skipping to change at page 22, line 25
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
15.2. Informative References [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009.
14.2. Informative References
[I-D.ietf-ecrit-framework] [I-D.ietf-ecrit-framework]
Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling using Internet "Framework for Emergency Calling using Internet
Multimedia", draft-ietf-ecrit-framework-10 (work in Multimedia", draft-ietf-ecrit-framework-10 (work in
progress), July 2009. progress), July 2009.
[I-D.ietf-ecrit-lost-servicelistboundary] [I-D.ietf-ecrit-lost-servicelistboundary]
Wolf, K., "Location-to-Service Translation Protocol (LoST) Wolf, K., "Location-to-Service Translation Protocol (LoST)
Extension: ServiceListBoundary", Extension: ServiceListBoundary",
 End of changes. 38 change blocks. 
123 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/