draft-ietf-ecrit-psap-callback-06.txt   draft-ietf-ecrit-psap-callback-07.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 25, 2013 Nokia Siemens Networks Expires: June 21, 2013 Nokia Siemens Networks
C. Holmberg C. Holmberg
Ericsson Ericsson
M. Patel M. Patel
InterDigital Communications InterDigital Communications
October 22, 2012 December 18, 2012
Public Safety Answering Point (PSAP) Callback Public Safety Answering Point (PSAP) Callback
draft-ietf-ecrit-psap-callback-06.txt draft-ietf-ecrit-psap-callback-07.txt
Abstract Abstract
After an emergency call is completed (either prematurely terminated After an emergency call is completed (either prematurely terminated
by the emergency caller or normally by the call taker) it is possible by the emergency caller or normally by the call taker) it is possible
that the call taker feels the need for further communication. For that the call taker feels the need for further communication. For
example, the call may have been dropped by accident without the call example, the call may have been dropped by accident without the call
taker having sufficient information about the current situation of a taker having sufficient information about the current situation of a
wounded person. A call taker may trigger a callback towards the wounded person. A call taker may trigger a callback towards the
emergency caller using the contact information provided with the emergency caller using the contact information provided with the
skipping to change at page 2, line 11 skipping to change at page 2, line 11
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on June 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 29 skipping to change at page 3, line 29
4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 14 5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 14
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 14 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 14
5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 14 5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Summoning police, the fire department or an ambulance in emergencies Summoning police, the fire department or an ambulance in emergencies
is one of the fundamental and most-valued functions of the telephone. is one of the fundamental and most-valued functions of the telephone.
As telephone functionality moves from circuit-switched telephony to As telephone functionality moves from circuit-switched telephony to
Internet telephony, its users rightfully expect that this core Internet telephony, its users rightfully expect that this core
functionality will continue to work at least as well as it has for functionality will continue to work at least as well as it has for
the legacy technology. New devices and services are being made the legacy technology. New devices and services are being made
available that could be used to make a request for help, which are available that could be used to make a request for help, which are
skipping to change at page 16, line 7 skipping to change at page 16, line 7
simple. For SIP UAs there is no need to maintain a list of PSAPs. simple. For SIP UAs there is no need to maintain a list of PSAPs.
Instead SIP UAs are assumed to trust the correct processing of their Instead SIP UAs are assumed to trust the correct processing of their
VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and, VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and,
if it cannot be verified, the PSAP callback marking is removed. If if it cannot be verified, the PSAP callback marking is removed. If
it is left untouched then the SIP UA should assume that it has been it is left untouched then the SIP UA should assume that it has been
verified successfully by the VSP/ASP and it should therefore be verified successfully by the VSP/ASP and it should therefore be
obeyed. obeyed.
6. IANA Considerations 6. IANA Considerations
[Editor's Note: There is currently no registry available for the SIP This document adds the "psap-callback" value to the SIP Priority
Priority header. A registry needs to be created and the value header IANA registry allocated by [I-D.ietf-sipcore-priority]. The
defined in this document needs to be added.] semantic of the newly defined "psap-callback" value is defined in
Section 4.
7. Acknowledgements 7. Acknowledgements
We would like to thank members from the ECRIT working group, in We would like to thank members from the ECRIT working group, in
particular Brian Rosen, for their discussions around PSAP callbacks. particular Brian Rosen, for their discussions around PSAP callbacks.
The working group discussed the topic of callbacks at their virtual The working group discussed the topic of callbacks at their virtual
interim meeting in February 2010 and the following persons provided interim meeting in February 2010 and the following persons provided
valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith
Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson,
Janet Gunn. Janet Gunn.
skipping to change at page 18, line 9 skipping to change at page 18, line 9
We would like to thank the following persons for their feedback on We would like to thank the following persons for their feedback on
the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert
Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly, Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly,
Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John
Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to [I-D.ietf-sipcore-priority] Roach, A., "IANA Registry for the
Indicate Requirement Levels", BCP 14, Session Initiation Protocol (SIP)
RFC 2119, March 1997. "Priority" Header Field",
draft-ietf-sipcore-priority-00 (work in
progress), December 2012.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, [RFC2119] Bradner, S., "Key words for use in RFCs
G., Johnston, A., Peterson, J., Sparks, to Indicate Requirement Levels", BCP 14,
R., Handley, M., and E. Schooler, "SIP: RFC 2119, March 1997.
Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, [RFC3261] Rosenberg, J., Schulzrinne, H.,
"Private Extensions to the Session Camarillo, G., Johnston, A., Peterson,
Initiation Protocol (SIP) for Asserted J., Sparks, R., Handley, M., and E.
Identity within Trusted Networks", Schooler, "SIP: Session Initiation
RFC 3325, November 2002. Protocol", RFC 3261, June 2002.
[RFC3966] Schulzrinne, H., "The tel URI for [RFC3325] Jennings, C., Peterson, J., and M.
Telephone Numbers", RFC 3966, Watson, "Private Extensions to the
December 2004. Session Initiation Protocol (SIP) for
Asserted Identity within Trusted
Networks", RFC 3325, November 2002.
[RFC3969] Camarillo, G., "The Internet Assigned [RFC3966] Schulzrinne, H., "The tel URI for
Number Authority (IANA) Uniform Resource Telephone Numbers", RFC 3966,
Identifier (URI) Parameter Registry for December 2004.
the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC4474] Peterson, J. and C. Jennings, [RFC3969] Camarillo, G., "The Internet Assigned
"Enhancements for Authenticated Identity Number Authority (IANA) Uniform Resource
Management in the Session Initiation Identifier (URI) Parameter Registry for
Protocol (SIP)", RFC 4474, August 2006. the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC5627] Rosenberg, J., "Obtaining and Using [RFC4474] Peterson, J. and C. Jennings,
Globally Routable User Agent URIs (GRUUs) "Enhancements for Authenticated Identity
in the Session Initiation Protocol (SIP)", Management in the Session Initiation
RFC 5627, October 2009. Protocol (SIP)", RFC 4474, August 2006.
[RFC5627] Rosenberg, J., "Obtaining and Using
Globally Routable User Agent URIs
(GRUUs) in the Session Initiation
Protocol (SIP)", RFC 5627, October 2009.
8.2. Informative References 8.2. Informative References
[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best Current
Practice for Communications Services in Practice for Communications Services in
support of Emergency Calling", support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in draft-ietf-ecrit-phonebcp-20 (work in
progress), September 2011. progress), September 2011.
[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. [RFC4484] Peterson, J., Polk, J., Sicker, D., and
Tschofenig, "Trait-Based Authorization H. Tschofenig, "Trait-Based
Requirements for the Session Initiation Authorization Requirements for the
Protocol (SIP)", RFC 4484, August 2006. Session Initiation Protocol (SIP)",
RFC 4484, August 2006.
[RFC5012] Schulzrinne, H. and R. Marshall, [RFC5012] Schulzrinne, H. and R. Marshall,
"Requirements for Emergency Context "Requirements for Emergency Context
Resolution with Internet Technologies", Resolution with Internet Technologies",
RFC 5012, January 2008. RFC 5012, January 2008.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name [RFC5031] Schulzrinne, H., "A Uniform Resource
(URN) for Emergency and Other Well-Known Name (URN) for Emergency and Other Well-
Services", RFC 5031, January 2008. Known Services", RFC 5031, January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF [RFC5234] Crocker, D. and P. Overell, "Augmented
for Syntax Specifications: ABNF", STD 68, BNF for Syntax Specifications: ABNF",
RFC 5234, January 2008. STD 68, RFC 5234, January 2008.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, [RFC6444] Schulzrinne, H., Liess, L., Tschofenig,
H., Stark, B., and A. Kuett, "Location H., Stark, B., and A. Kuett, "Location
Hiding: Problem Statement and Hiding: Problem Statement and
Requirements", RFC 6444, January 2012. Requirements", RFC 6444, January 2012.
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
 End of changes. 19 change blocks. 
60 lines changed or deleted 68 lines changed or added

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