draft-ietf-ecrit-psap-callback-08.txt   draft-ietf-ecrit-psap-callback-09.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: August 29, 2013 Nokia Siemens Networks Expires: September 20, 2013 Nokia Siemens Networks
C. Holmberg C. Holmberg
Ericsson Ericsson
M. Patel M. Patel
InterDigital Communications InterDigital Communications
February 25, 2013 March 19, 2013
Public Safety Answering Point (PSAP) Callback Public Safety Answering Point (PSAP) Callback
draft-ietf-ecrit-psap-callback-08.txt draft-ietf-ecrit-psap-callback-09.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 August 29, 2013. This Internet-Draft will expire on September 20, 2013.
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 51 skipping to change at page 2, line 51
4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.1. General . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 13 5.1. Security Threat . . . . . . . . . . . . . . . . . . . . . 13
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 13 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 13
5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 13 5.3. Security Solution . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
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
not traditional telephones, and users are increasingly expecting them not traditional telephones, and users are increasingly expecting them
to be used to place emergency calls. to be used to place emergency calls.
An overview of the protocol interactions for emergency calling using An overview of the protocol interactions for emergency calling using
the IETF emergency services architecture are described in [RFC6444] the IETF emergency services architecture are described in [RFC6443]
and [I-D.ietf-ecrit-phonebcp] specifies the technical details. As and [RFC6881] specifies the technical details. As part of the
part of the emergency call setup procedure two important identifiers emergency call setup procedure two important identifiers are conveyed
are conveyed to the PSAP call taker's user agent, namely the Address- to the PSAP call taker's user agent, namely the Address-Of-Record
Of-Record (AoR), and, if available, the Globally Routable User Agent (AOR), and, if available, the Globally Routable User Agent (UA) URIs
(UA) URIs (GRUU). RFC 3261 [RFC3261] defines the AoR as: (GRUU). RFC 3261 [RFC3261] defines the AOR as:
'An address-of-record (AOR) is a SIP or SIPS URI that points to a "An address-of-record (AOR) is a SIP or SIPS URI that points to a
domain with a location service that can map the URI to another URI domain with a location service that can map the URI to another URI
where the user might be available. Typically, the location where the user might be available. Typically, the location
service is populated through registrations. An AOR is frequently service is populated through registrations. An AOR is frequently
thought of as the "public address" of the user.' thought of as the "public address" of the user."
In SIP systems a single user can have a number of user agents In SIP systems a single user can have a number of user agents
(handsets, softphones, voicemail accounts, etc.) which are all (handsets, softphones, voicemail accounts, etc.) which are all
referenced by the same AOR. There are a number of cases in which it referenced by the same AOR. There are a number of cases in which it
is desirable to have an identifier which addresses a single user is desirable to have an identifier which addresses a single user
agent rather than the group of user agents indicated by an AOR. The agent rather than the group of user agents indicated by an AOR. The
GRUU is such a unique user- agent identifier, which is still globally GRUU is such a unique user-agent identifier, which is still globally
routable. RFC 5627 [RFC5627] specifies how to obtain and use GRUUs. routable. RFC 5627 [RFC5627] specifies how to obtain and use GRUUs.
[I-D.ietf-ecrit-phonebcp] also makes use of the GRUU for emergency [RFC6881] also makes use of the GRUU for emergency calls.
calls.
Regulatory requirements demand that the emergency call setup Regulatory requirements demand that the emergency call setup
procedure itself provides enough information to allow the call taker procedure itself provides enough information to allow the call taker
to initiate a call back to the emergency caller. This is desirable to initiate a callback to the emergency caller. This is desirable in
in those cases where the call got dropped prematurely or when further those cases where the call got dropped prematurely or when further
communication need arises. The AoR and the GRUU serve this purpose. communication need arises. The AOR and the GRUU serve this purpose.
The communication attempt by the PSAP call taker back to the The communication attempt by the PSAP call taker back to the
emergency caller is called 'PSAP callback'. emergency caller is called 'PSAP callback'.
A PSAP callback may, however, be blocked by user configured A PSAP callback may, however, be blocked by user configured
authorization policies or may be forwarded to an answering machine authorization policies or may be forwarded to an answering machine
since SIP entities (SIP proxies as well as the SIP user equipment since SIP entities (SIP proxies as well as the SIP user equipment
itself) cannot differentiate the PSAP callback from any other SIP itself) cannot differentiate the PSAP callback from any other SIP
call. "Call barring", "do not disturb", or "call diversion"(aka call call. "Call barring", "do not disturb", or "call diversion"(aka call
forwarding) are features that prevent delivery of a call. It is forwarding) are features that prevent delivery of a call. It is
skipping to change at page 4, line 22 skipping to change at page 4, line 21
reaches the emergency caller. At the same time a design must deal reaches the emergency caller. At the same time a design must deal
with the negative side-effects of allowing certain calls to bypass with the negative side-effects of allowing certain calls to bypass
call forwarding or other authorization policies. Ideally, the PSAP call forwarding or other authorization policies. Ideally, the PSAP
callback has to relate to an earlier emergency call that was made callback has to relate to an earlier emergency call that was made
"not too long ago". An exact time interval is difficult to define in "not too long ago". An exact time interval is difficult to define in
a global IETF standard due to the variety of national regulatory a global IETF standard due to the variety of national regulatory
requirements. requirements.
To nevertheless meet the needs from the emergency services community To nevertheless meet the needs from the emergency services community
a basic mechanism for preferential treatment of PSAP callbacks was a basic mechanism for preferential treatment of PSAP callbacks was
defined in Section 13 of [RFC6444]. The specification says: defined in Section 13 of [RFC6443]. The specification says:
'A UA may be able to determine a PSAP call back by examining the "A UA may be able to determine a PSAP callback by examining the
domain of incoming calls after placing an emergency call and domain of incoming calls after placing an emergency call and
comparing that to the domain of the answering PSAP from the comparing that to the domain of the answering PSAP from the
emergency call. Any call from the same domain and directed to the emergency call. Any call from the same domain and directed to the
supplied Contact header or AoR after an emergency call should be supplied Contact header or AOR after an emergency call should be
accepted as a callback from the PSAP if it occurs within a accepted as a callback from the PSAP if it occurs within a
reasonable time after an emergency call was placed.' reasonable time after an emergency call was placed."
This approach mimics a stateful packet filtering firewall and is This approach mimics a stateful packet filtering firewall and is
indeed helpful in a number of cases. It is also relatively simple to indeed helpful in a number of cases. It is also relatively simple to
implement even though it requires state to be maintained by the user implement even though it requires call state to be maintained by the
agent as well as by SIP intermediaries. Unfortunately, the solution user agent as well as by SIP intermediaries. Unfortunately, the
does not work in all deployment scenarios. In Section 3 we describe solution does not work in all deployment scenarios. In Section 3 we
cases where the currently standardized approach is insufficient. describe cases where the currently standardized approach is
insufficient.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Emergency services related terminology is borrowed from [RFC5012]. Emergency services related terminology is borrowed from [RFC5012].
This includes terminology like emergency caller, user equipment, and This includes terminology like emergency caller, user equipment, call
call taker. taker, Emergency Service Routing Proxy (ESRP), and Public Safety
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 [I-D.ietf-ecrit-phonebcp], for specified solution, as specified in [RFC6881], for preferential
preferential treatment of callbacks fails. As explained in Section 1 treatment of callbacks fails. As explained in Section 1 a SIP entity
a SIP entity examines an incoming PSAP call back by comparing the examines an incoming PSAP callback by comparing the domain of the
domain of the PSAP with the destination domain of the emergency call. PSAP with the destination domain of the emergency call.
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. outgoing SIP messaging routed through different SIP entities.
Figure 1 shows this graphically whereby a VoIP provider uses Figure 1 shows this graphically whereby a VoIP provider uses
different SIP proxies for inbound and for outbound call handling. different SIP proxies for inbound and for outbound call handling.
Unless they two devices are state synchronized the callback hitting Unless the two devices are synchronized as to state the callback
the inbound proxy would get treated like any other call since the hitting the inbound proxy would get treated like any other call since
emergency call established state information at the outbound proxy the emergency call established state information at the outbound
only. proxy only.
,-------. ,-------.
,' `. ,' `.
,-------. / Emergency \ ,-------. / Emergency \
,' `. | Services | ,' `. | Services |
/ VoIP \ I | Network | / VoIP \ I | Network |
| Provider | n | | | Provider | n | |
| | t | | | | t | |
| | e | | | | e | |
| +-------+ | r | | | +-------+ | r | |
skipping to change at page 7, line 35 skipping to change at page 7, line 35
+--+-->|Outbound|--+---->v | | +--+---+ | +--+-->|Outbound|--+---->v | | +--+---+ |
| |Proxy | | i | | +-+ESRP | | | |Proxy | | i | | +-+ESRP | |
| +--------+ | d | | | +------+ | | +--------+ | d | | | +------+ |
| | e || | | | | e || | |
| | r |+-+ | | | r |+-+ |
\ / | | \ / | |
`. ,' \ / `. ,' \ /
'-------' `. ,' '-------' `. ,'
'-------' '-------'
Figure 1: Example for Routing Asymmetry Figure 1: Example for Routing Asymmetry.
3.2. Multi-Stage Routing 3.2. Multi-Stage Routing
Consider the following emergency call routing scenario shown in Consider the following emergency call routing scenario shown in
Figure 2 where routing towards the PSAP occurs in several stages. In Figure 2 where routing towards the PSAP occurs in several stages. In
this scenario we consider a SIP UA that uses LoST to learn the next this scenario we consider a SIP UA that uses LoST to learn the next
hop destination closer to the PSAP. This call is then sent to the hop destination closer to the PSAP. This call is then sent to the
user's VoIP provider. The user's VoIP provider receives the user's VoIP provider. The user's VoIP provider receives the
emergency call and creates state based on the destination domain, emergency call and creates state based on the destination domain,
namely state.com. It then routes it to the indicated ESRP. When the namely state.org. It then routes it to the indicated ESRP. When the
ESRP receives it it needs to decide what the next hop is to get it ESRP receives it it needs to decide what the next hop is to get it
closer to the PSAP. In our example the next hop is the PSAP with the closer to the PSAP. In our example the next hop is the PSAP with the
URI psap@town.com. URI psap@town.com.
When a callback is sent from psap@town.com towards the emergency When a callback is sent from psap@town.com towards the emergency
caller the call will get normal treatment by the VoIP providers caller the call will get normal treatment by the VoIP providers
inbound proxy since the domain of the PSAP does not match the stored inbound proxy since the domain of the PSAP does not match the stored
state information. state information.
,-------. ,-------.
skipping to change at page 8, line 18 skipping to change at page 8, line 18
| UA |--- esrp1@foobar.com / Emergency \ | UA |--- esrp1@foobar.com / Emergency \
+----+ \ | Services | +----+ \ | Services |
\ ,-------. | Network | \ ,-------. | Network |
,' `. | | ,' `. | |
/ VoIP \ | +------+ | / VoIP \ | +------+ |
( Provider ) | |PSAP | | ( Provider ) | |PSAP | |
\ / | +--+---+ | \ / | +--+---+ |
`. ,' | | `. ,' | |
'---+---' | | | '---+---' | | |
| |psap@town.com | | |psap@town.com |
esrp@state.com | | | esrp@state.org | | |
| | | | | | | |
| | | | | | | |
| | +--+---+ | | | +--+---+ |
+------------+---+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 ERSP 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 Similarly 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.
skipping to change at page 9, line 51 skipping to change at page 9, line 51
| +------+ | | Network | | `~~~~~~~~~~~~~~~ | +------+ | | Network | | `~~~~~~~~~~~~~~~
| | |medic-town.org | | | | |medic-town.org | |
| , | | | | , | | |
`~~~~~~~~~~~~~~~ | +------+ | | `~~~~~~~~~~~~~~~ | +------+ | |
| |PSAP +----+ + | |PSAP +----+ +
| +------+ | | +------+ |
| | | |
| , | ,
`~~~~~~~~~~~~~~~ `~~~~~~~~~~~~~~~
Figure 3: Example for Call Forwarding Figure 3: Example for Call Forwarding.
3.4. Network-based Service URN Resolution 3.4. Network-based Service URN Resolution
The IETF emergency services architecture also considers cases where The IETF emergency services architecture also considers cases where
the resolution from the Service URN to the PSAP URI does not only the resolution from the Service URN to the PSAP URI does not only
happen at the SIP UA itself but at intermediate SIP entities, such as happen at the SIP UA itself but at intermediate SIP entities, such as
the user's VoIP provider. the user's VoIP provider.
Figure 4 shows this message exchange of the outgoing emergency call Figure 4 shows this message exchange of the outgoing emergency call
and the incoming PSAP graphically. While the state information and the incoming PSAP graphically. While the state information
skipping to change at page 10, line 47 skipping to change at page 10, line 47
Invite| | Invite Invite| | Invite
from| | to from| | to
police.example.com| | urn:service:sos police.example.com| | urn:service:sos
V | V |
+-------+ +-------+
| 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 does leave
the same PSTN/VoIP gateway or that the same end point identifier is the same PSTN/VoIP gateway or that the same end point identifier is
used in the forward as well as in the backward direction making it used in the forward as well as in the backward direction making it
difficult to reliably detect PSAP callbacks. difficult to reliably detect PSAP callbacks.
+-----------+ +-----------+
skipping to change at page 11, line 43 skipping to change at page 11, line 43
| | | |
Invite Invite Invite Invite
| | | |
V | V |
+-------+ +-------+
| SIP | | SIP |
| UA | | UA |
| Alice | | Alice |
+-------+ +-------+
Figure 5: Example for PSTN Interworking Figure 5: Example for PSTN Interworking.
Note: This scenario is considered outside the scope of this document. Note: This scenario is considered outside the scope of this document.
The specified solution does not support this use case. The specified solution does not support this use case.
4. SIP PSAP Callback Indicator 4. SIP PSAP Callback Indicator
4.1. General 4.1. General
This section defines a new header field value, called "psap- This section defines a new header field value, called "psap-
callback", for the SIP Priority header field defined in [RFC3261]. callback", for the SIP Priority header field defined in [RFC3261].
skipping to change at page 13, line 11 skipping to change at page 13, line 11
priority-value /= "psap-callback" priority-value /= "psap-callback"
Figure 6: ABNF Figure 6: ABNF
5. Security Considerations 5. Security Considerations
5.1. Security Threat 5.1. Security Threat
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 similar features to contact emergency callers and to raise their and other similar features used to raise the attention of emergency
attention. Regarding the latter aspect a callback, if understood by callers when attempting to contact them. In the case where the SIP
the SIP UA would allow to override user interface configurations, Priority header value, 'psap-callback', is supported by the SIP UA,
such as vibrate-only mode, to alert the caller of the incoming call. it would override user interface configurations, such as vibrate-only
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 requirement is to ensure that the mechanisms described in this
document can not be used for malicious purposes, including document can not be used for malicious purposes, including
telemarketing. 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
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 whitelist 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.
+----------+ +----------+
| List of |+ | List of |+
| valid || | valid ||
| PSAPs || | PSAPs ||
+----------+| +----------+|
+----------+ +----------+
* *
* whitelist * white list
* *
V V
Incoming +----------+ Normal Incoming +----------+ Normal
SIP Msg | SIP |+ Treatment SIP Msg | SIP |+ Treatment
-------------->| Entity ||======================> -------------->| Entity ||======================>
+ Identity | ||(if not in whitelist) + Identity | ||(if not in white list)
Info +----------+| Info +----------+|
+----------+ +----------+
|| ||
|| ||
|| Preferential || Preferential
|| Treatment || Treatment
++========================> ++========================>
(if successfully verified) (if successfully verified)
Figure 7: Identity-based Authorization Figure 7: Identity-based Authorization
An important aspect from a security point of view is the relationship An important aspect from a security point of view is the relationship
between the emergency services network (containing PSAPs) and the VSP between the emergency services network (containing PSAPs) and the
(assuming that the emergency call travels via the VSP and not VoIP provider (assuming that the emergency call travels via the VoIP
directly between the SIP UA and the PSAP). provider and not directly between the SIP UA and the PSAP).
If there is some form of relationship between the emergency services If there is some form of relationship between the emergency services
operator and the VSP then the identification of a PSAP call back is operator and the VoIP provider then the identification of a PSAP
less problematic than in the case where the two entities have not callback is less problematic than in the case where the two entities
entered in some form of relationship that would allow the VSP to have not entered in some form of relationship that would allow the
verify whether the marked callback message indeed came from a VoIP provider to verify whether the marked callback message indeed
legitimate source. came from a legitimate source.
The establishment of a whitelist with PSAP identities maybe be The establishment of a whitelist with PSAP identities maybe be
operationally complex. When there is a local relationship between operationally complex. When there is a local relationship between
the VSP/ASP and the PSAP then populating the whitelist is fairly the VoIP provider and the PSAP then populating the whitelist is
simple. For SIP UAs there is no need to maintain a list of PSAPs. fairly simple. For SIP UAs there is no need to maintain a list of
Instead SIP UAs are assumed to trust the correct processing of their PSAPs. Instead SIP UAs are assumed to trust the correct processing
VSP/ASP, i.e., the VSP/ASP processes the PSAP callback marking and, of their VoIP provider, i.e., the VoIP provider processes the PSAP
if it cannot be verified, the PSAP callback marking is removed. If callback marking and, if it cannot be verified, the PSAP callback
it is left untouched then the SIP UA should assume that it has been marking is removed. If it is left untouched then the SIP UA should
verified successfully by the VSP/ASP and it should therefore be assume that it has been verified successfully by the VoIP provider
obeyed. and it should therefore be obeyed.
6. IANA Considerations 6. IANA Considerations
This document adds the "psap-callback" value to the SIP Priority This document adds the "psap-callback" value to the SIP Priority
header IANA registry allocated by [I-D.ietf-sipcore-priority]. The header IANA registry allocated by [RFC6878]. The semantic of the
semantic of the newly defined "psap-callback" value is defined in newly defined "psap-callback" value is defined in Section 4.
Section 4.
7. Acknowledgements 7. Acknowledgements
We would like to thank members from the ECRIT working group, in We would like to thank the following persons for their feedback: Paul
particular Brian Rosen, for their discussions around PSAP callbacks. Kyzivat, Martin Thomson, Robert Sparks, Keith Drage, Cullen Jennings
The working group discussed the topic of callbacks at their virtual Brian Rosen, Martin Dolly, Bernard Aboba, Andrew Allen, Atle Monrad,
interim meeting in February 2010 and the following persons provided John-Luc Bakker, John Elwell, Geoff Thompson, Dan Romascanu, James
valuable input: John Elwell, Bernard Aboba, Cullen Jennings, Keith Polk, John Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight,
Drage, Marc Linsner, Roger Marshall, Dan Romascanu, Geoff Thompson, Janet Gunn
Janet Gunn.
At IETF#81 a small group of people got to together to continue the
discussions started at the working group meeting to explore a GRUU-
based solution approach. Martin Thomson, Marc Linsner, Andrew Allen,
Brian Rosen, Martin Dolly, and Atle Monrad participated at this side-
meeting.
We would like to thank the following persons for their feedback on Finally, we would like to thank the ECRIT working group chairs, Marc
the solution discussion in 2012: Paul Kyzivat, Martin Thomson, Robert Linsner and Roger Marshall, for their support.
Sparks, Keith Drage, Brian Rosen, Roger Marshall, Martin Dolly,
Bernard Aboba, Andrew Allen, John-Luc Bakker, James Polk, John
Medland, Hadriel Kaplan, Kenneth Carlberg, Timothy Dwight, Janet Gunn
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-sipcore-priority] Roach, A., "IANA Registry for the [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Session Initiation Protocol (SIP) Requirement Levels", BCP 14, RFC 2119, March 1997.
"Priority" Header Field",
draft-ietf-sipcore-priority-00 (work in
progress), December 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
to Indicate Requirement Levels", BCP 14, A., Peterson, J., Sparks, R., Handley, M., and E.
RFC 2119, March 1997. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Camarillo, G., Johnston, A., Peterson, Extensions to the Session Initiation Protocol (SIP) for
J., Sparks, R., Handley, M., and E. Asserted Identity within Trusted Networks", RFC 3325,
Schooler, "SIP: Session Initiation November 2002.
Protocol", RFC 3261, June 2002.
[RFC3325] Jennings, C., Peterson, J., and M. [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
Watson, "Private Extensions to the RFC 3966, December 2004.
Session Initiation Protocol (SIP) for
Asserted Identity within Trusted
Networks", RFC 3325, November 2002.
[RFC3966] Schulzrinne, H., "The tel URI for [RFC3969] Camarillo, G., "The Internet Assigned Number Authority
Telephone Numbers", RFC 3966, (IANA) Uniform Resource Identifier (URI) Parameter
December 2004. Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC3969] Camarillo, G., "The Internet Assigned [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Number Authority (IANA) Uniform Resource Authenticated Identity Management in the Session
Identifier (URI) Parameter Registry for Initiation Protocol (SIP)", RFC 4474, August 2006.
the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC4474] Peterson, J. and C. Jennings, [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
"Enhancements for Authenticated Identity Agent URIs (GRUUs) in the Session Initiation Protocol
Management in the Session Initiation (SIP)", RFC 5627, October 2009.
Protocol (SIP)", RFC 4474, August 2006.
[RFC5627] Rosenberg, J., "Obtaining and Using [RFC6878] Roach, A., "IANA Registry for the Session Initiation
Globally Routable User Agent URIs Protocol (SIP) "Priority" Header Field", RFC 6878,
(GRUUs) in the Session Initiation March 2013.
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 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
Practice for Communications Services in "Trait-Based Authorization Requirements for the Session
support of Emergency Calling", Initiation Protocol (SIP)", RFC 4484, August 2006.
draft-ietf-ecrit-phonebcp-20 (work in
progress), September 2011.
[RFC4484] Peterson, J., Polk, J., Sicker, D., and [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
H. Tschofenig, "Trait-Based Emergency Context Resolution with Internet Technologies",
Authorization Requirements for the RFC 5012, January 2008.
Session Initiation Protocol (SIP)",
RFC 4484, August 2006.
[RFC5012] Schulzrinne, H. and R. Marshall, [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
"Requirements for Emergency Context Emergency and Other Well-Known Services", RFC 5031,
Resolution with Internet Technologies", January 2008.
RFC 5012, January 2008.
[RFC5031] Schulzrinne, H., "A Uniform Resource [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Name (URN) for Emergency and Other Well- Specifications: ABNF", STD 68, RFC 5234, January 2008.
Known Services", RFC 5031, January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
BNF for Syntax Specifications: ABNF", "Framework for Emergency Calling Using Internet
STD 68, RFC 5234, January 2008. Multimedia", RFC 6443, December 2011.
[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
H., Stark, B., and A. Kuett, "Location Communications Services in Support of Emergency Calling",
Hiding: Problem Statement and BCP 181, RFC 6881, March 2013.
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. 51 change blocks. 
148 lines changed or deleted 123 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/