[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11

ECRIT Working Group                                             M. Patel
Internet-Draft                               InterDigital Communications
Intended status: Standards Track                           July 28, 2010
Expires: January 29, 2011


 SOS Uniform Resource Identifier (URI) Parameter for Marking of Session
    Initiation Protocol (SIP) Requests related to Emergency Services
                 draft-patel-ecrit-sos-parameter-09.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

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 29, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Patel                   Expires January 29, 2011                [Page 1]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  The "reg-type" URI Parameter  . . . . . . . . . . . . . . . . . 4
     4.1.  REGISTER Request  . . . . . . . . . . . . . . . . . . . . . 5
     4.2.  2xx Response to REGISTER Request  . . . . . . . . . . . . . 5
     4.3.  Backwards compatibility issues  . . . . . . . . . . . . . . 5
   5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8




























Patel                   Expires January 29, 2011                [Page 2]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


1.  Introduction

   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
   [RFC5031] (and used in the IETF emergency services architecture
   described in PhoneBCP[I-D.ietf-ecrit-phonebcp]).  The 3GPP IP
   Multimedia Subsystem (IMS) emergency services architecture,
   illustrated in 3GPP TS 23.167 [3GPP.23.167], specifies that the User
   Equipment (UE) performs emergency registration prior to or during the
   initiation of an emergency call.  The circumstances where such an
   emergency registration is beneficial are listed below:

   - the UE is not registered with its home network;

   - the UE is currently registered but roaming (to ensure that the
   emergency call is handled in the visited network, as required by some
   jurisdictions).

   Emergency registration is possible only when the UE has sufficient
   credentials to register with its home network and can detect that an
   emergency session is initiated.  Unfortunately, marking of the
   emergency registration cannot be fulfilled by the use of the Service
   URN.

   In some countries, it is a regulatory requirement that devices be
   able to place emergency calls in circumstances where other calls may
   not be permitted.  When a UAC issues an emergency marked REGISTER
   request it indicates to the registrar that roaming and barring
   restrictions should not be applied for the registered address-of-
   record in order to successfully initiate an emergency session.

   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
   above.  However, the solution proposed does not preclude other
   systems that require emergency registration to occur prior to placing
   an emergency call.



Patel                   Expires January 29, 2011                [Page 3]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


   This document proposes a way to mark a REGISTER request as an
   emergency registration.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119]


3.  Requirements

   Req: Where emergency registration is required prior to placing an
   emergency call, it shall be possible to distinguish emergency
   registration from non-emergency registration.


4.  The "reg-type" URI Parameter

   This section provides an overview of the proposed new URI parameter
   to be used for marking REGISTER requests related to emergency
   services.

   A new URI parameter "reg-type" is defined in this document.  The
   "reg-type" parameter is appended to a URI consistent with RFC 3261
   [RFC3261].  It is proposed that use of this URI parameter is
   restricted to the Contact header included in the REGISTER request
   (and the 2xx response to the REGISTER request) related to an
   emergency call only.

   The "reg-type" URI parameter SHALL take a value of "sos" to indicate
   that the REGISTER request pertains to emergency registration.  The
   "reg-type" URI parameter with value "sos" MUST NOT be considered as a
   replacement for the Service URN for emergency calls originated by a
   UA.

   Other use cases where specific instances of SIP registration need to
   be identified are also possible.  One such case may be by an end-user
   registering their address-of-record with the specific purpose of
   making "test" calls within a network.  Such cases not specific to the
   use case identified in this draft for identifying emergency
   registration are not dealt with in this document.  However the "reg-
   type" URI parameter is extensible to allow other "reg-type" values to
   be defined in the future.






Patel                   Expires January 29, 2011                [Page 4]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


4.1.  REGISTER Request

   In networks where the UA sends a REGISTER request for emergency
   registration prior to placing an emergency call, the "reg-type" URI
   parameter with value "sos" MUST be appended to the URI in the Contact
   header.  This serves as an indication to the registrar that the
   request is for emergency registration.

   Example:

   Contact: "Alice" <sip:alice@example.com;reg-type=sos> ;q=0.7;
   expires=3600

   In the event that more than one Contact header field is included in
   the REGISTER request, only the contact addresses that include the
   "reg-type" URI parameter with value "sos" shall be considered as
   emergency registered contact addresses.

   The "reg-type" URI parameter with value "sos" MUST NOT be included in
   non-REGISTER requests, and MUST NOT be included in REGISTER requests
   that do not pertain to emergency calls.

4.2.  2xx Response to REGISTER Request

   If the registrar receives a REGISTER request that includes the "reg-
   type" URI parameter with value "sos" in the Contact header field, the
   registrar MUST include the "reg-type" URI parameter with value "sos"
   in the Contact header field in the 200 (OK) response sent by the
   registrar upon successful registration.  The "reg-type" URI parameter
   with value "sos" is appended to the URI included in the Contact
   header.

4.3.  Backwards compatibility issues

   The backwards compatibility scenario considered in this document is
   where a legacy registrar does not support the "reg-type" URI
   parameter with value "sos".  In this case, if the registrar receives
   a REGISTER request that includes the "reg-type" URI parameter with
   value "sos" in the Contact header field, the registrar proceeds with
   registration procedures and silently ignores the URI-parameter in
   accordance with RFC 3261[RFC3261].  This ensures the user is
   registered and thus can successfully initiate an emergency call.

   The drawback of proceeding with registration is if the address-of-
   record is for example barred or has roaming restrictions applied,
   then these restrictions will not be lifted and thus registration will
   be unsuccessful.  This can limit the UAC's ability to successfully
   place an emergency call.



Patel                   Expires January 29, 2011                [Page 5]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


   If registration is successful, the 200 (OK) response from a legacy
   registrar includes the "reg-type" URI parameter with value "sos" in
   the Contact header field.  Thus the UA is unaware that the registrar
   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

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC 5234 [RFC5234].

   The "reg-type" URI parameter is a "uri-parameter", as defined by RFC
   3261[RFC3261].

   uri-parameter =/ reg-type-param

   reg-type-param = "reg-type=" ("sos" / genvalue)

   genvalue = 1*(alphanum / "-" / "." )


6.  IANA Considerations

   This specification defines one new SIP URI parameter, as per the
   registry created by RFC 3969 [RFC3969]

   Parameter Name: reg-type

   Predefined Values: sos



Patel                   Expires January 29, 2011                [Page 6]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


   Reference: [RFCXXXX]

   [NOTE TO IANA: Please replace XXXX with the RFC number of this
   specification.]


7.  Security Considerations

   As an identifier, the "reg-type" parameter itself does not raise any
   particular security issues.  The semantic described by the "reg-type"
   parameter are meant to be well-known so privacy considerations do not
   apply to the URI parameter.  The main possibility of attack involves
   use of the "reg-type" parameter to bypass the normal procedures in
   order to achieve fraudulent use of services or to bypass security
   procedures.  The usage of this parameter as described in this
   document is purely for the purpose of the REGISTER request and hence
   in presence of user authentication it is ensured that the respective
   user can be held accountable.

   It is RECOMMENDED to log events of misuse of the "reg-type" URI
   parameter with value "sos", for example by including it in a request
   or response not related to an emergency call.


8.  Acknowledgements

   The author would like to thank Keith Drage, Milo Orsic, Deb Barclay,
   John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter
   Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura
   Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and
   Sandeep Sharma, Brian Rosen, Hannes Tschofenig, Christer Holmberg and
   Henning Schulzrinne for the discussions and contributions that led to
   this work.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax



Patel                   Expires January 29, 2011                [Page 7]


Internet-Draft     SOS URI Parameter for SIP Emergency         July 2010


              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Uniform Resource Identifier (URI) Parameter
              Registry for the Session Initiation Protocol (SIP)",
              BCP 99, RFC 3969, December 2004.

9.2.  Informative References

   [I-D.ietf-ecrit-phonebcp]
              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency Calling",
              draft-ietf-ecrit-phonebcp-15 (work in progress),
              July 2010.

   [RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", RFC 5031,
              January 2008.

   [3GPP.23.167]
              3GPP, "IP Multimedia Subsystem (IMS) emergency sessions",
              3GPP TS 23.167 10.0.0, June 2010.


Author's Address

   Milan Patel
   InterDigital Communications

   Email: Milan.Patel@interdigital.com





















Patel                   Expires January 29, 2011                [Page 8]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/