< draft-ietf-ecrit-psap-callback-11.txt		draft-ietf-ecrit-psap-callback-12.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: March 30, 2014 Nokia Solutions and Networks		Expires: March 31, 2014 Nokia Solutions and Networks
	C. Holmberg		C. Holmberg
	Ericsson		Ericsson
	M. Patel		M. Patel
	InterDigital Communications		InterDigital Communications
	September 26, 2013		September 27, 2013
	Public Safety Answering Point (PSAP) Callback		Public Safety Answering Point (PSAP) Callback
	draft-ietf-ecrit-psap-callback-11.txt		draft-ietf-ecrit-psap-callback-12.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 March 30, 2014.		This Internet-Draft will expire on March 31, 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 11, line 7 ¶		skipping to change at page 11, line 7 ¶
	The PSAP callback functionality described in this document allows		The PSAP callback functionality described in this document allows
	marked calls to bypass blacklists, ignore call forwarding procedures		marked calls to bypass blacklists, ignore call forwarding procedures
	and other similar features used to raise the attention of emergency		and other similar features used to raise the attention of emergency
	callers when attempting to contact them. In the case where the SIP		callers when attempting to contact them. In the case where the SIP
	Priority header value, 'psap-callback', is supported by the SIP UA,		Priority header value, 'psap-callback', is supported by the SIP UA,
	it would override user interface configurations, such as vibrate-only		it would override user interface configurations, such as vibrate-only
	mode, to alert the caller of the incoming call.		mode, to alert the caller of the incoming call.
	5.2. Security Requirements		5.2. Security Requirements
	The requirement is to ensure that the mechanisms described in this		The security threat discussed in Section 5.1 leads to the requirement
	document can not be used for malicious purposes, including		to ensure that the mechanisms described in this document can not be
	telemarketing.		used for malicious purposes, including telemarketing.
	Furthermore, if the newly defined extension is not recognized, not		Furthermore, if the newly defined extension is not recognized, not
	verified adequately, or not obeyed by SIP intermediaries or SIP		verified adequately, or not obeyed by SIP intermediaries or SIP
	endpoints then it must not lead to a failure of the call handling		endpoints then it must not lead to a failure of the call handling
	procedure. Such call must be treated like a call that does not have		procedure. Such call must be treated like a call that does not have
	any marking attached.		any marking attached.
	5.3. Security Solution		5.3. Security Solution
			The approach for dealing with implementing the security requirements
			described in Section 5.2 can be differentiated between the behavior
			applied by the UA and by SIP proxies. A UA that has made an
			emergency call will keep state information so that it can recognize
			and accepted a callback from the PSAP if it occurs within a
			reasonable time after an emergency call was placed, as described in
			Section 13 of [RFC6443]. Since UA considerations are described
			already in [RFC6443] as well as in [RFC6881] the rest of this section
			focuses on the behavior of SIP proxies.
	Figure 7 shows the architecture that utilizes the identity of the		Figure 7 shows the architecture that utilizes the identity of the
	PSAP to decide whether a preferential treatment of callbacks should		PSAP to decide whether a preferential treatment of callbacks should
	be provided. To make this policy decision, the identity of the PSAP		be provided. To make this policy decision, the identity of the PSAP
	is compared with a white list of valid PSAPs available to the SIP		is compared with a white list of valid PSAPs available to the SIP
	entity. The identity assurance in SIP can come in different forms,		entity. The identity assurance in SIP can come in different forms,
	such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].		such as SIP Identity [RFC4474] or with P-Asserted-Identity [RFC3325].
	The former technique relies on a cryptographic assurance and the		The former technique relies on a cryptographic assurance and the
	latter on a chain of trust. Also the usage of TLS between		latter on a chain of trust. Also the usage of TLS between
	neighboring SIP entities may provide useful identity information.		neighboring SIP entities may provide useful identity information.
End of changes. 6 change blocks.
	7 lines changed or deleted		17 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/