< draft-ietf-ecrit-psap-callback-10.txt		draft-ietf-ecrit-psap-callback-11.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: January 14, 2014 Nokia Siemens Networks		Expires: March 30, 2014 Nokia Solutions and Networks
	C. Holmberg		C. Holmberg
	Ericsson		Ericsson
	M. Patel		M. Patel
	InterDigital Communications		InterDigital Communications
	July 13, 2013		September 26, 2013
	Public Safety Answering Point (PSAP) Callback		Public Safety Answering Point (PSAP) Callback
	draft-ietf-ecrit-psap-callback-10.txt		draft-ietf-ecrit-psap-callback-11.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 10 ¶		skipping to change at page 2, line 10 ¶
	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 January 14, 2014.		This Internet-Draft will expire on March 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . 4		3. Callback Scenarios . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 5		3.1. Routing Asymmetry . . . . . . . . . . . . . . . . . . . . 5
	3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 6		3.2. Multi-Stage Routing . . . . . . . . . . . . . . . . . . . 6
	3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 7		3.3. Call Forwarding . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Network-based Service URN Resolution . . . . . . . . . . 8		3.4. Network-based Service URN Resolution . . . . . . . . . . 8
	3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 9		3.5. PSTN Interworking . . . . . . . . . . . . . . . . . . . . 9
	4. SIP PSAP Callback Indicator . . . . . . . . . . . . . . . . . 10		4. SIP PSAP Callback Indicator . . . . . . . . . . . . . . . . . 10
	4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 11		4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 11		4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 11		5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 10
	5.2. Security Requirements . . . . . . . . . . . . . . . . . . 11		5.2. Security Requirements . . . . . . . . . . . . . . . . . . 11
	5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 12		5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	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 5, line 4 ¶		skipping to change at page 4, line 47 ¶
	insufficient.		insufficient.
	2. Terminology		2. Terminology
	Emergency services related terminology is borrowed from [RFC5012].		Emergency services related terminology is borrowed from [RFC5012].
	This includes terminology like emergency caller, user equipment, call		This includes terminology like emergency caller, user equipment, call
	taker, Emergency Service Routing Proxy (ESRP), and Public Safety		taker, Emergency Service Routing Proxy (ESRP), and Public Safety
	Answering Point (PSAP).		Answering Point (PSAP).
	3. Callback Scenarios		3. Callback Scenarios
	This section illustrates a number of scenarios where the currently		This section illustrates a number of scenarios where the currently
	specified solution, as specified in [RFC6881], for preferential		specified solution, as specified in [RFC6881], for preferential
	treatment of callbacks fails. As explained in Section 1 a SIP entity		treatment of callbacks fails. As explained in Section 1 a SIP entity
	examines an incoming PSAP callback by comparing the domain of the		examines an incoming PSAP callback by comparing the domain of the
	PSAP with the destination domain of the emergency call.		PSAP with the destination domain of the outbound emergency call
			placed earlier.
	NOTE: All FQDNs used in the subsections below are used for		NOTE: All FQDNs used in the subsections below are used for
	illustrative purposes. They are examples to demonstrate the		illustrative purposes. They are examples to demonstrate the
	limitations of the technical solution outlined in RFC 6881.		limitations of the technical solution outlined in RFC 6881.
	3.1. Routing Asymmetry		3.1. Routing Asymmetry
	In some deployment environments it is common to have incoming and		In some deployment environments it is common to have incoming and
	outgoing SIP messaging routed through different SIP entities. Figure		outgoing SIP messaging routed through different SIP entities. Figure
	1 shows this graphically whereby a VoIP provider uses different SIP		1 shows this graphically whereby a VoIP provider uses different SIP
	proxies for inbound and for outbound call handling. Unless the two		proxies for inbound and for outbound call handling. Unless the two
	devices are synchronized as to state the callback hitting the inbound		devices are synchronized, the callback hitting the inbound proxy
	proxy would get treated like any other call since the emergency call		would get treated like any other call since the emergency call
	established state information at the outbound proxy only.		established state information at the outbound proxy only.
	,-------.		,-------.
	,' `.		,' `.
	,-------. / Emergency \		,-------. / Emergency \
	,' `. | Services |		,' `. | Services |
	/ VoIP \ I | Network |		/ VoIP \ I | Network |
	| Provider | n | |		| Provider | n | |
	| | t | |		| | t | |
	| | e | |		| | e | |
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 4 ¶
	+------------+---+ESRP | |		+------------+---+ESRP | |
	| +------+ |		| +------+ |
	| |		| |
	\ /		\ /
	`. ,'		`. ,'
	'-------'		'-------'
	Figure 2: Example for Multi-Stage Routing.		Figure 2: Example for Multi-Stage Routing.
	3.3. Call Forwarding		3.3. Call Forwarding
	Imagine the following case where an emergency call enters an		Imagine the following case where an emergency call enters an
	emergency network (state.org) via an ESRP but then gets forwarded to		emergency network (state.org) via an ESRP but then gets forwarded to
	a different emergency services network (in our example to police-		a different emergency services network (in our example to police-
	town.org, fire-town.org or medic-town.org). The same considerations		town.org, fire-town.org or medic-town.org). The same considerations
	apply when the police, fire and ambulance networks are part of the		apply when the police, fire and ambulance networks are part of the
	state.org sub-domains (e.g., police.state.org).		state.org sub-domains (e.g., police.state.org).
	Similarly to the previous scenario the problem here is with the wrong		Similar to the previous scenario the problem here is with the wrong
	state information being established during the emergency call setup		state information being established during the emergency call setup
	procedure. A callback would originate in the police-town.org, fire-		procedure. A callback would originate in the police-town.org, fire-
	town.org or medic-town.org domain whereas the emergency caller's SIP		town.org or medic-town.org domain whereas the emergency caller's SIP
	UA or the VoIP outbound proxy has stored state.org.		UA or the VoIP outbound proxy has stored state.org.
	,-------.		,-------.
	,' `.		,' `.
	/ Emergency \		/ Emergency \
	| Services |		| Services |
	| Network |		| Network |
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 16 ¶
	| SIP |		| SIP |
	| UA |		| UA |
	| Alice |		| Alice |
	+-------+		+-------+
	Figure 4: Example for Network-based Service URN Resolution.		Figure 4: Example for Network-based Service URN Resolution.
	3.5. PSTN Interworking		3.5. PSTN Interworking
	In case an emergency call enters the PSTN, as shown in Figure 5,		In case an emergency call enters the PSTN, as shown in Figure 5,
	there is no guarantee that the callback some time later does leave		there is no guarantee that the callback some time later leaves the
	the same PSTN/VoIP gateway or that the same end point identifier is		same PSTN/VoIP gateway or that the same end point identifier is used
	used in the forward as well as in the backward direction making it		in the forward as well as in the backward direction making it
	difficult to reliably detect PSAP callbacks.		difficult to reliably detect PSAP callbacks.
	+-----------+		+-----------+
	| PSTN |-------------+		| PSTN |-------------+
	| Calltaker | |		| Calltaker | |
	| Bob |<--------+ |		| Bob |<--------+ |
	+-----------+ | v		+-----------+ | v
	-------------------		-------------------
	//// \\\\ +------------+		//// \\\\ +------------+
	| | |PSTN / VoIP |		| | |PSTN / VoIP |
	skipping to change at page 13, line 31 ¶		skipping to change at page 12, line 43 ¶
	7. Acknowledgements		7. Acknowledgements
	We would like to thank the following persons for their feedback: Paul		We would like to thank the following persons for their feedback: Paul
	Kyzivat, Martin Thomson, Robert Sparks, Keith Drage, Cullen Jennings		Kyzivat, Martin Thomson, Robert Sparks, Keith Drage, Cullen Jennings
	Brian Rosen, Martin Dolly, Bernard Aboba, Andrew Allen, Atle Monrad,		Brian Rosen, Martin Dolly, Bernard Aboba, Andrew Allen, Atle Monrad,
	John-Luc Bakker, John Elwell, Geoff Thompson, Dan Romascanu, James		John-Luc Bakker, John Elwell, Geoff Thompson, Dan Romascanu, James
	Polk, John Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight,		Polk, John Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight,
	Janet Gunn		Janet Gunn
	Finally, we would like to thank the ECRIT working group chairs, Marc		We would like to thank the ECRIT working group chairs, Marc Linsner
	Linsner and Roger Marshall, for their support. Roger Marshall was		and Roger Marshall, for their support. Roger Marshall was the
	the document shepherd for this document.		document shepherd for this document. Vijay Gurbani provided the
			general area review.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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.
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 4 ¶
	[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,		[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
	"Framework for Emergency Calling Using Internet		"Framework for Emergency Calling Using Internet
	Multimedia", RFC 6443, December 2011.		Multimedia", RFC 6443, December 2011.
	[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for		[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
	Communications Services in Support of Emergency Calling",		Communications Services in Support of Emergency Calling",
	BCP 181, RFC 6881, March 2013.		BCP 181, RFC 6881, March 2013.
	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
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	EMail: hgs+ecrit@cs.columbia.edu		EMail: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Solutions and Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	EMail: Hannes.Tschofenig@gmx.net		EMail: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Christer Holmberg		Christer Holmberg
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	EMail: christer.holmberg@ericsson.com		EMail: christer.holmberg@ericsson.com
	Milan Patel		Milan Patel
	InterDigital Communications		InterDigital Communications
End of changes. 18 change blocks.
	27 lines changed or deleted		29 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/