ECRIT Working Group                                             M. Patel
Internet-Draft                                                    Nortel
Intended status: Standards Track                       December 16, 2008
Expires: June 19, 2009


 SOS Uniform Resource Identifier (URI) Parameter for Marking of Session
    Initiation Protocol (SIP) Requests related to Emergency Services
                 draft-patel-ecrit-sos-parameter-02.txt

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 June 19, 2009.

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 usage of
   this new URI parameter complements the usage of the Service Uniform
   Resource Name (URN) and is not intended to replace it.









Patel                     Expires June 19, 2009                 [Page 1]


Internet-Draft     SOS URI Parameter for SIP Emergency     December 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The "sos" URI Parameter . . . . . . . . . . . . . . . . . . . . 3
     3.1.  REGISTER Request  . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  2xx Reponse to REGISTER Request . . . . . . . . . . . . . . 4
   4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7



































Patel                     Expires June 19, 2009                 [Page 2]


Internet-Draft     SOS URI Parameter for SIP Emergency     December 2008


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 required are listed below:

   - the UE is not registered with its home network

   - is currently registered but roaming

   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 can not be fulfilled by the use of the Service
   URN.

   When a UE issues an emergency marked REGISTER request it informs the
   registrar that the contact address and the address-of-record being
   registered is to be used for emergency calls, and roaming and barring
   restrictions should not be applied for the registered address-of-
   record.  A call back from a PSAP would be routed to the registered
   contact address.

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


2.  Terminology

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


3.  The "sos" 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 "sos" is defined in this document.  The "sos"



Patel                     Expires June 19, 2009                 [Page 3]


Internet-Draft     SOS URI Parameter for SIP Emergency     December 2008


   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
   "sos" URI parameter MUST NOT be considered as a replacement for the
   Service URN for emergency calls originated by a UA.

3.1.  REGISTER Request

   When the UA sends a REGISTER request for emergency registration, the
   "sos" URI parameter 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;sos> ;q=0.7; expires=3600

3.2.  2xx Reponse to REGISTER Request

   The "sos" URI parameter MUST be present in the Contact header in the
   200 (OK) response sent by the registrar upon successful registration.
   The "sos" URI parameter is appended to the URI included in the
   Contact header, thus indicating to the UA that this contact address
   will be included in the Contact header of an INVITE for emergency
   call intiation.


4.  Formal Syntax

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

   uri-parameter = *(";"value)

   value = sos


5.  IANA Considerations

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

   Parameter Name: sos

   Predefined Values: none

   Reference: [RFCXXXX]



Patel                     Expires June 19, 2009                 [Page 4]


Internet-Draft     SOS URI Parameter for SIP Emergency     December 2008


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


6.  Security Considerations

   As an identifier, the "sos" parameter itself does not raise any
   particular security issues.  The semantic described by the "sos"
   parameter are meant to be well-known so privacy considerations do not
   apply to the URN.  The main possibility of attack involves use of the
   "sos" 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 message 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 "sos" URI parameter,
   for example by including it in a request or response not related to
   an emergency calls.


7.  Acknowledgements

   The author would like to thank Keith Drage, Milo Orsic, 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 for the discussions and contributions that lead to this work.


8.  References

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

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Uniform Resource Identifier (URI) Parameter



Patel                     Expires June 19, 2009                 [Page 5]


Internet-Draft     SOS URI Parameter for SIP Emergency     December 2008


              Registry for the Session Initiation Protocol (SIP)",
              BCP 99, RFC 3969, December 2004.

8.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-06 (work in progress),
              November 2008.

   [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 7.10.0, September 2008.


Author's Address

   Milan Patel
   Nortel
   Maidenhead Office Park, Westacott Way
   Maidenhead, Berkshire, UK

   Email: milanpa@nortel.com























Patel                     Expires June 19, 2009                 [Page 6]


Internet-Draft     SOS URI Parameter for SIP Emergency     December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.











Patel                     Expires June 19, 2009                 [Page 7]