< draft-patel-ecrit-sos-parameter-07.txt   draft-patel-ecrit-sos-parameter-08.txt >
ECRIT Working Group M. Patel ECRIT Working Group M. Patel
Internet-Draft Nortel Internet-Draft InterDigital Communications
Intended status: Standards Track October 26, 2009 Intended status: Standards Track February 15, 2010
Expires: April 29, 2010 Expires: August 19, 2010
SOS Uniform Resource Identifier (URI) Parameter for Marking of Session SOS Uniform Resource Identifier (URI) Parameter for Marking of Session
Initiation Protocol (SIP) Requests related to Emergency Services Initiation Protocol (SIP) Requests related to Emergency Services
draft-patel-ecrit-sos-parameter-07.txt draft-patel-ecrit-sos-parameter-08.txt
Abstract
This document defines a new Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI) parameter intended for marking SIP
registration requests related to emergency services. The URI
parameter is extensible to allow future values to be defined if
required by other use cases that require specific SIP registrations
to be distinctly identified. The usage of this new URI parameter
complements the usage of the Service Uniform Resource Name (URN) and
is not intended to replace it.
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 33 skipping to change at page 1, line 44
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 29, 2010. This Internet-Draft will expire on August 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document defines a new Session Initiation Protocol (SIP) Uniform described in the BSD License.
Resource Identifier (URI) parameter intended for marking SIP
registration requests related to emergency services. The URI
parameter is extensible to allow future values to be defined if
required by other use cases that require specific SIP registrations
to be distinctly identified. The usage of this new URI parameter
complements the usage of the Service Uniform Resource Name (URN) and
is not intended to replace it.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The "reg-type" URI Parameter . . . . . . . . . . . . . . . . . 4 4. The "reg-type" URI Parameter . . . . . . . . . . . . . . . . . 4
4.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 4 4.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 5
4.2. 2xx Response to REGISTER Request . . . . . . . . . . . . . 5 4.2. 2xx Response to REGISTER Request . . . . . . . . . . . . . 5
4.3. Backwards compatibility issues . . . . . . . . . . . . . . 5 4.3. Backwards compatibility issues . . . . . . . . . . . . . . 5
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
One way to differentiate a SIP-based emergency call from an ordinary One way to differentiate a SIP-based emergency call from an ordinary
call is by the presence of the Service URN as defined in RFC 5031 call is by the presence of the Service URN as defined in RFC 5031
[RFC5031] (and used in the IETF emergency services architecture [RFC5031] (and used in the IETF emergency services architecture
described in PhoneBCP[I-D.ietf-ecrit-phonebcp]). The 3GPP IP described in PhoneBCP[I-D.ietf-ecrit-phonebcp]). The 3GPP IP
Multimedia Subsystem (IMS) emergency services architecture, Multimedia Subsystem (IMS) emergency services architecture,
illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User
Equipment (UE) performs emergency registration prior to or during the Equipment (UE) performs emergency registration prior to or during the
skipping to change at page 3, line 26 skipping to change at page 3, line 26
- the UE is not registered with its home network; - the UE is not registered with its home network;
- the UE is currently registered but roaming (to ensure that the - the UE is currently registered but roaming (to ensure that the
emergency call is handled in the visited network, as required by some emergency call is handled in the visited network, as required by some
jurisdictions). jurisdictions).
Emergency registration is possible only when the UE has sufficient Emergency registration is possible only when the UE has sufficient
credentials to register with its home network and can detect that an credentials to register with its home network and can detect that an
emergency session is initiated. Unfortunately, marking of the emergency session is initiated. Unfortunately, marking of the
emergency registration can not be fulfilled by the use of the Service emergency registration cannot be fulfilled by the use of the Service
URN. URN.
In some countries, it is a regulatory requirement that devices be In some countries, it is a regulatory requirement that devices be
able to place emegency calls in circumstances where other calls may able to place emergency calls in circumstances where other calls may
not be permitted. When a UAC issues an emergency marked REGISTER not be permitted. When a UAC issues an emergency marked REGISTER
request it informs the registrar that the contact address and the request it informs the registrar that the contact address and the
address-of-record being registered are to be used for emergency address-of-record being registered are to be used for emergency
calls, and roaming and barring restrictions should not be applied for calls, and roaming and barring restrictions should not be applied for
the registered address-of-record. the registered address-of-record.
Furthermore, distinguishing emergency registration from non-emergency
registration allows the registrar to ensure that the contact address
associated with previous registration of the address-of-record
included in the emergency REGISTER request is not replaced. For
incoming calls, for example, a PSAP call back to a previously made
emergency call, addressed to the emergency registered address-of-
record can be correctly routed to the contact address and UA from
which the original emergency call was placed. In addition, any
network based services or UA endpoint based services which may
prevent the emergency call or PSAP call back from being successful
can be disabled if it can be distinguished that the registered
contact address and address-of-record pertain to emergency calls.
This document concentrates on a use case defined by 3GPP as described This document concentrates on a use case defined by 3GPP as described
above. However, the solution proposed does not preclude other above. However, the solution proposed does not preclude other
systems that require emergency registration to occur prior to placing systems that require emergency registration to occur prior to placing
an emergency call. an emergency call.
This document proposes a way to mark a REGISTER request as an This document proposes a way to mark a REGISTER request as an
emergency registration. emergency registration.
2. Terminology 2. Terminology
skipping to change at page 5, line 4 skipping to change at page 5, line 17
In networks where the UA sends a REGISTER request for emergency In networks where the UA sends a REGISTER request for emergency
registration prior to placing an emergency call, the "reg-type" URI registration prior to placing an emergency call, the "reg-type" URI
parameter with value "sos" MUST be appended to the URI in the Contact parameter with value "sos" MUST be appended to the URI in the Contact
header. This serves as an indication to the registrar that the header. This serves as an indication to the registrar that the
request is for emergency registration. request is for emergency registration.
Example: Example:
Contact: "Alice" <sip:alice@example.com;reg-type=sos> ;q=0.7; Contact: "Alice" <sip:alice@example.com;reg-type=sos> ;q=0.7;
expires=3600 expires=3600
In the event that more than one Contact header field is included in In the event that more than one Contact header field is included in
the REGISTER request, only the contact addresses that include the the REGISTER request, only the contact addresses that include the
"reg-type" URI parameter with value "sos" shall be considered as "reg-type" URI parameter with value "sos" shall be considered as
emergency registered contact addresses. emergency registered contact addresses.
The "reg-type" URI parameter with value "sos" MUST NOT be included in The "reg-type" URI parameter with value "sos" MUST NOT be included in
non-REGISTER requests, and MUST NOT be included in REGISTER requests non-REGISTER requests, and MUST NOT be included in REGISTER requests
that do not pertain to emergency calls. that do not pertain to emergency calls.
4.2. 2xx Response to REGISTER Request 4.2. 2xx Response to REGISTER Request
If the registrar receives a REGISTER request that includes the "reg- If the registrar receives a REGISTER request that includes the "reg-
type" URI parameter with value "sos" in the Contact heade field, the type" URI parameter with value "sos" in the Contact heade field, the
registrar MUST include the "reg-type" URI parameter with value "sos" registrar MUST include the "reg-type" URI parameter with value "sos"
in the Contact header field in the 200 (OK) response sent by the in the Contact header field in the 200 (OK) response sent by the
registrar upon successful registration. The "reg-type" URI parameter registrar upon successful registration. The "reg-type" URI parameter
with value "sos" is appended to the URI included in the Contact with value "sos" is appended to the URI included in the Contact
header, thus indicating to the UA that it needs to include this header, thus indicating to the UA that it needs to include this
contact address in the Contact header of an INVITE for emergency call contact address in the Contact header of an INVITE request for
initiation. emergency call initiation.
4.3. Backwards compatibility issues 4.3. Backwards compatibility issues
The backwards compatibility scenario considered in this document is The backwards compatibility scenario considered in this document is
where a legacy registrar does not support the "reg-type" URI where a legacy registrar does not support the "reg-type" URI
parameter with value "sos". In this case, if the registrar receives parameter with value "sos". In this case, if the registrar receives
a REGISTER request that includes the "reg-type" URI parameter with a REGISTER request that includes the "reg-type" URI parameter with
value "sos" in the Contact header field, the registrar proceeds with value "sos" in the Contact header field, the registrar proceeds with
registration procedures and silently ignores the URI-parameter in registration procedures and silently ignores the URI-parameter in
accordance with RFC 3261[RFC3261]. This ensures the user is accordance with RFC 3261[RFC3261]. This ensures the user is
registered and thus can successfully initiate an emergency call. registered and thus can successfully initiate an emergency call.
The drawback of proceeding with registration is if the address-of- The drawback of proceeding with registration is if the address-of-
record is for example barred or has roaming restrictions applied, record is for example barred or has roaming restrictions applied,
then these restrictions will not be lifted and thus registration will then these restrictions will not be lifted and thus registration will
be unsuccessful. This can limit the UAC's ability to successfully be unsuccessful. This can limit the UAC's ability to successfully
place an emergency call. place an emergency call.
If registration is successful, the 200 (OK) response from a legacy If registration is successful, the 200 (OK) response from a legacy
registrar is unlikely to include the "reg-type" URI parameter in the registrar includes the "reg-type" URI parameter with value "sos" in
Contact header field since this registration is treated as a non- the Contact header field. Thus the UA is unaware that the registrar
emergency registration. does not support the "reg-type" URI parameter with value "sos".
Providing the registration was successful, the UA's ability to place
an emergency call is not compromised. The UA need not know that the
registrar does not support the URI parameter.
The consequence of the registrar not supporting the "reg-type" URI
parameter with value "sos", in addition to the drawback pertaining to
restrictions applied to the address-of-record, are as follows:
- the risk of the registrar overwriting previous registrations of the
registered address-of-record, and thus disrupting any on-going non-
emergency sessions associated with the UA, its address-of-record and
previously registered contact address.
- incoming calls, such as a PSAP call back (to a previously made
emergency call) to the registered address-of-record might not be
routed correctly to the UA that placed the emergency call, due to not
suppressing any network based services such as call forwarding, or UA
based services which can divert the call elsewhere, or if the
address-of-record is associated to more than one contact address.
5. Formal Syntax 5. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 5234 [RFC5234]. Form (BNF) as described in RFC 5234 [RFC5234].
The "reg-type" URI parameter is a "uri-parameter", as defined by RFC The "reg-type" URI parameter is a "uri-parameter", as defined by RFC
3261[RFC3261]. 3261[RFC3261].
uri-parameter =/ reg-type-param uri-parameter =/ reg-type-param
skipping to change at page 7, line 18 skipping to change at page 8, line 4
9. References 9. References
9.1. Normative References 9.1. Normative References
[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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[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.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter (IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)", Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004. BCP 99, RFC 3969, December 2004.
9.2. Informative References 9.2. Informative 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-14 (work in progress),
July 2009. January 2010.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[3GPP.23.167] [3GPP.23.167]
3GPP, "IP Multimedia Subsystem (IMS) emergency sessions", 3GPP, "IP Multimedia Subsystem (IMS) emergency sessions",
3GPP TS 23.167 7.11.0, December 2008. 3GPP TS 23.167 7.12.0, December 2009.
Author's Address Author's Address
Milan Patel Milan Patel
Nortel InterDigital Communications
Maidenhead Office Park, Westacott Way
Maidenhead, Berkshire, UK
Email: milanpa@nortel.com Email: Milan.Patel@interdigital.com
 End of changes. 21 change blocks. 
42 lines changed or deleted 78 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/