One document matched: draft-patel-ecrit-sos-parameter-01.txt
Differences from draft-patel-ecrit-sos-parameter-00.txt
ECRIT Working Group M. Patel
Internet-Draft Nortel
Intended status: Standards Track November 3, 2008
Expires: May 7, 2009
SOS Uniform Resource Identifier (URI) parameter for marking of Session
Initiation Protocol (SIP) requests related to emergency services
draft-patel-ecrit-sos-parameter-01.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 May 7, 2009.
Abstract
This memo describes requirements and protocol conventions for a new
SIP (Session Initiation Protocol) URI parameter intended for marking
SIP requests and responses related to emergency services. This
proposal addresses issues that exist in the current 3rd Generation
Partnership Project IP Multimedia Subsystem (IMS) Emergency services
solution, but is not precluded from being used by other SIP-based
emergency services solutions. It is not intended as a replacement
for the service URN.
Patel Expires May 7, 2009 [Page 1]
Internet-Draft SOS URI Parameter for SIP Emergency November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Requirements for additional emergency indication . . . . . 3
4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Proposed URI parameter . . . . . . . . . . . . . . . . . . 5
4.3. Proposed use of "sos" parameter . . . . . . . . . . . . . . 5
4.3.1. REGISTER request . . . . . . . . . . . . . . . . . . . 5
4.3.2. Requests for emergency call initiation . . . . . . . . 5
4.3.3. Call back from PSAP . . . . . . . . . . . . . . . . . . 6
4.3.4. SIP responses . . . . . . . . . . . . . . . . . . . . . 6
5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Patel Expires May 7, 2009 [Page 2]
Internet-Draft SOS URI Parameter for SIP Emergency November 2008
1. Introduction
This document describes a number of requirements addressing issues
that exist in the 3GPP IMS emergency services solution, and a
proposed solution for marking SIP requests related to emergency
services. SIP-based emergency calls can be distinguished by the
presence of the Service URN as defined in I-D-ietf-ecrit-phonebcp
[I-D.ietf-ecrit-phonebcp] and RFC 5031 [RFC5031]. The emergency
services solution in the 3GPP IP Multimedia Subsystem (IMS), as
described 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 which can be useful in specific
scenarios such as roaming. Marking of the emergency registration is
a requirement described in this document that can not be fulfilled by
the use of Service URN. A further requirement for proposing a new
method for marking requests related to emergency calls is to identify
the call back from a PSAP. Identification of the call back can aid
in suppressing network-based and UA-based services. A further
requirement for proposing a new method for marking responses is the
case where a UE did not recognize the request as an emergency service
request. Identification of the session as a emergency service
session can aid in suppressing UA-based services or preventing
transmission of a BYE request as required in some jurisdictions. The
requirements for marking emergency call related messages are explored
in this document and a new URI parameter is proposed to fulfill these
requirements.
2. Conventions
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. Requirements
3.1. General
This section defines the requirements for introducing a new URI
parameter to be used for marking emergency call related SIP requests.
3.2. Requirements for additional emergency indication
[REQ 1] Indication in REGISTER request:
3GPP requires that a UE performs emergency registration under
Patel Expires May 7, 2009 [Page 3]
Internet-Draft SOS URI Parameter for SIP Emergency November 2008
specific circumstances, such as roaming, as described in 3GPP TS
23.167 [3GPP.23.167]. Marking the REGISTER request to indicate an
emergency registration is necessary to inform the registrar that the
contact address and AOR being registered is to be used for emergency
calls, and roaming and barring restrictions should not be applied for
the registered AOR. A call back from a PSAP would be routed to the
registered contact address. Further requirements for the emergency
registration are specified in 3GPP TS 23.167 [3GPP.23.167].
[REQ 2] Indication of IMS Emergency call origination:
The Service URN in the Request URI is considered to be the primary
method for marking the INVITE request for emergency call initiation.
However, it is considered necessary to add another marking to the
emergency request, particularly if the Service URN in the Request-URI
is replaced by a network entity (in the case of 3GPP, such actions
are performed at the Emergency Call Session Control Function
(E-CSCF)). This can result in inappropriate handling at SIP entities
prior to interworking the SIP request to ISUP at a PSTN gateway UA at
the edge of the SIP network for routing towards the PSAP in the PSTN.
[REQ 3] Indicating to the UA that an emergency call has been
initiated:
In the case that the UA is not emergency aware or no service URN for
the requested emergency type is known, it will not populate the
emergency INVITE with the service URN. Upon the network identifying
the Request URI as an emergency number, the Request URI can be
replaced with the Service URN. The UA is still unaware that an
emergency call was initiated. A backwards indication to the UA from
the network can ensure proper handling of the emergency call at the
UA, i.e. no services such as call hold are applied to the emergency
call.
[REQ 4] Marking the PSAP call back:
Identifying a call back from a PSAP can allow the network to apply
special handling of the call back. Network-based services can be
suppressed and the call can be routed to the contact address from
which the emergency call was initiated. Additionally, special
handling of the call back can occur at the UA.
PhoneBCP [I-D.ietf-ecrit-phonebcp]suggests one possible method by
which a call back can be identified, based upon the domain of the
PSAP which answers the outgoing emergency call. This is possible if
the PSAP is located in an IP network and is capable of communicating
using SIP signaling. However, if the PSAP is located in the PSTN,
attempting to identify the call back based upon the PSAP domain name
Patel Expires May 7, 2009 [Page 4]
Internet-Draft SOS URI Parameter for SIP Emergency November 2008
is not possible.
4. Proposed solution
4.1. General
This section provides an overview of the proposed new URI parameter
to be used for marking requests related to emergency services.
4.2. Proposed URI parameter
A new URI parameter "sos" is defined in this document. The "sos"
parameter is appended to an AOR consistent with RFC 3261 [RFC3261].
It is proposed that use of this URI parameter is restricted to the
Contact header for request and responses 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.
4.3. Proposed use of "sos" parameter
4.3.1. REGISTER request
It is proposed that when the UA sends a REGISTER request for
emergency registration, the "sos" URI parameter SHALL be appended to
the AOR in the Contact header. This serves as an indication to the
registrar that the request is for emergency registration.
The "sos" URI parameter SHALL be present in the Contact header in the
200 (OK) response sent upon successful registration, thus indicating
to the UA that this contact address will be included in the Contact
header of an INVITE for emergency call initiation.
4.3.2. Requests for emergency call initiation
When an emergency aware UA initiates an emergency call, the UA SHOULD
include the "sos" URI parameter, appended to the contact address, in
the Contact header in the INVITE request.
An entity in the network that handles emergency calls (in the case of
3GPP the P-CSCF is aware of the local emergency numbers and can
detect that a request is for an emergency call), SHOULD append the
"sos" URI parameter to the contact address in the Contact header in
the event that the "sos" URI parameter is not present in the Contact
header.
This serves as an indication that this is an emergency call even in
Patel Expires May 7, 2009 [Page 5]
Internet-Draft SOS URI Parameter for SIP Emergency November 2008
the case when the Service URN is removed by a network entity.
4.3.3. Call back from PSAP
The call back from the PSAP SHOULD include the "sos" URI parameter in
the Contact header of the INVITE request. If the PSAP is SIP
capable, then the "sos" URI parameter SHOULD be included by the PSAP.
If the PSAP is located in the PSTN, the PSTN gateway UA at the edge
of the SIP network SHOULD append the "sos" parameter to the contact
address in the Contact header of the generated INVITE request that is
routed back to the emergency caller. This serves as an indication to
network entities and to the UE to apply special call handling such as
to suppress services that would normally be applied to a terminating
call.
4.3.4. SIP responses
The "sos" URI parameter MAY be included in provisional responses and
2xx responses to initial INVITE request for emergency call. This can
serve as an indication to a UA that is not "emergency aware" that an
emergency call has been initiated, thus allowing the UA to provide
special handling of such a call. Suppressing call hold or multi-
party call initiation during the emergency call to the PSAP are
examples of special handling. It is RECOMMENDED that in such a
response, the "sos" URI parameter is included in the Contact header,
appended to contact address.
5. Formal syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC 2234 [RFC2234]
uri-parameter = *(";"value)
value = sos
6. 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 May 7, 2009 [Page 6]
Internet-Draft SOS URI Parameter for SIP Emergency November 2008
[NOTE TO IANA: Please replace XXXX with the RFC number of this
specification.]
7. Security Considerations
The "sos" URI parameter does not appear to raise any particular
security issue. Misuse of the "sos" URI parameter, by including it
in a request or response not related to an emergency call SHOULD be
monitored by a network entity.
8. 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.
9. Normative 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-05 (work in progress),
July 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.
[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.
Patel Expires May 7, 2009 [Page 7]
Internet-Draft SOS URI Parameter for SIP Emergency November 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.
Author's Address
Milan Patel
Nortel
Maidenhead Office Park, Westacott Way
Maidenhead, Berkshire, UK
Email: milanpa@nortel.com
Patel Expires May 7, 2009 [Page 8]
Internet-Draft SOS URI Parameter for SIP Emergency November 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 May 7, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 22:13:03 |