< draft-ietf-ecrit-psap-callback-03.txt   draft-ietf-ecrit-psap-callback-04.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 29, 2012 Nokia Siemens Networks Expires: September 12, 2012 Nokia Siemens Networks
C. Holmberg C. Holmberg
Ericsson Ericsson
M. Patel M. Patel
InterDigital Communications InterDigital Communications
October 27, 2011 March 11, 2012
Public Safety Answering Point (PSAP) Callback Public Safety Answering Point (PSAP) Callback
draft-ietf-ecrit-psap-callback-03.txt draft-ietf-ecrit-psap-callback-04.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
initial emergency call. This callback could, under certain initial emergency call. This callback could, under certain
circumstances, be treated like any other call and as a consequence it circumstances, be treated like any other call and as a consequence it
may get blocked by authorization policies or may get forwarded to an may get blocked by authorization policies or may get forwarded to an
answering machine. answering machine.
The IETF emergency services architecture offers capabilities to allow The IETF emergency services architecture specification already offers
callbask to bypass authorization policies to reach the caller without a solution approach for allowing PSAP callbacks to bypass
unnecessary delays. However, the mechanism specified prior to this authorization policies to reach the caller without unnecessary
document supports only limited scenarios. This document discusses delays. Unfortunately, the specified mechanism only supports limited
some shortcomings, presents additional scenarios where better-than- scenarios. This document discusses shortcomings of the current
normal call treatment behavior would be desirable, and specifies a mechanisms and illustrates additional scenarios where better-than-
protocol solution. normal call treatment behavior would be desirable.
Note that this version of the document does not yet specify a
solution due to the lack of the working group participants agreeing
on the requirements.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 29, 2012. This Internet-Draft will expire on September 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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 the IETF emergency services architecture are described in [RFC6444]
[I-D.ietf-ecrit-framework] and [I-D.ietf-ecrit-phonebcp] specifies and [I-D.ietf-ecrit-phonebcp] specifies the technical details. As
the technical details. As part of the emergency call setup procedure part of the emergency call setup procedure two important identifiers
two important identifiers are conveyed to the PSAP call-taker's user are conveyed to the PSAP call taker's user agent, namely the Address-
agent, namely the Address-Of-Record (AoR), and the Globally Routable Of-Record (AoR), and, if available, the Globally Routable User Agent
User Agent (UA) URIs (GRUU). RFC 3261 [RFC3261] defines the AoR as: (UA) URIs (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. [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
calls.
Regulatory requirements demand that the emergency call itself Regulatory requirements demand that the emergency call setup
provides enough information to allow the call-taker to initiate a procedure itself provides enough information to allow the call taker
call back to the emergency caller in case the call dropped or to to initiate a call back to the emergency caller. This is desirable
interact with the emergency caller in case of further questions. The in those cases where the call got dropped prematurely or when further
AoR and the GRUU serve this purpose. The communication attempt by communication need arises. The AoR and the GRUU serve this purpose.
the PSAP call-taker back to the emergency caller is called 'PSAP
callback'.
A PSAP callback may, however, be blocked by user configured whitelis The communication attempt by the PSAP call taker back to the
or may be forwarded to an answering machine as SIP entities (SIP emergency caller is called 'PSAP callback'.
proxies as well as the SIP UA itself) cannot differentiate the
callback from any other SIP call establishing attempt from the SIP
signaling message.
While there are no regulatory requirements at the time of writing of A PSAP callback may, however, be blocked by user configured
this specification there is the believe that PSAP callbacks have to authorization policies or may be forwarded to an answering machine
be treated in such a way that they reach the emergency caller. For since SIP entities (SIP proxies as well as the SIP user equipment
this purpose guidance for PSAP callback handling has been provided in itself) cannot differentiate the PSAP callback from any other SIP
Section 13 of [I-D.ietf-ecrit-framework]: call. "Call barring", "do not disturb", or "call diversion"(aka call
forwarding) are features that prevent delivery of a call. It is
important to note that these features may be implemented by SIP
intermediaries as well as by the user agent.
A UA may be able to determine a PSAP call back by examining the Among the emergency services community there is the desire to offer
PSAP callbacks a treatment such that chances are increased that it
reaches the emergency caller. At the same time a design must deal
with the negative side-effects of allowing certain calls to bypass
call forwarding or other authorization policies. Ideally, the PSAP
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
a global IETF standard due to the variety of national regulatory
requirements.
To nevertheless meet the needs from the emergency services community
a basic mechanism for preferential treatment of PSAP callbacks was
defined in Section 13 of [RFC6444]. The specification says:
'A UA may be able to determine a PSAP call back 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. Unfortunately, it does not work in all SIP deployment implement even though it requires state to be maintained by the user
scenarios. In Section 3 we describe scenarios where the currently agent as well as by SIP intermediaries. Unfortunately, the solution
standardized approach is insufficient. In Section 4 a solution is does not work in all deployment scenarios. In Section 3 we describe
described. 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
call taker.
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 [I-D.ietf-ecrit-phonebcp], for
preferential treatment of callbacks fails. As explained in Section 1 preferential treatment of callbacks fails. As explained in Section 1
a SIP entity examines an incoming PSAP call back by comparing the a SIP entity examines an incoming PSAP call back by comparing the
domain of the PSAP with the destination domain of the emergency call. domain of the PSAP with the destination domain of the emergency call.
3.1. Routing Asymmetry 3.1. Routing Asymmetry
skipping to change at page 8, line 37 skipping to change at page 8, line 37
'-------' '-------'
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 ERSP 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 the police, fire and ambulance networks are part of apply when the police, fire and ambulance networks are part of the
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.
,-------. ,-------.
,' `. ,' `.
/ Emergency \ / Emergency \
skipping to change at page 10, line 9 skipping to change at page 10, line 9
| | | |
| , | ,
`~~~~~~~~~~~~~~~ `~~~~~~~~~~~~~~~
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 intermedidate SIP entities, such happen at the SIP UA itself but at intermediate SIP entities, such as
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
stored at the VoIP provider is correct the state allocated at the SIP stored at the VoIP provider is correct the state allocated at the SIP
UA is not. UA is not.
,-------. ,-------.
,' `. ,' `.
/ Emergency \ / Emergency \
| Services | | Services |
skipping to change at page 12, line 7 skipping to change at page 12, line 7
| 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. Specification 4. Specification
[Editor's Note: The solution approach described in [Editor's Note: The specification for a solution that meets the
[I-D.holmberg-emergency-callback-id] will be discussed at the IETF#82 requirements will be placed in here.]
ECRIT meeting and at the ECRIT mailing list and will be incorporated
here if agreed by the working group.]
5. Security Considerations 5. Security Considerations
[Editor's Note: Instead of an abstract security description text will [Editor's Note: Instead of an abstract security description text will
be provided with the solution description.] be provided with the solution description.]
6. IANA Considerations 6. IANA Considerations
[Editor's Note: IANA consideration text will be added once an [Editor's Note: IANA consideration text will be added once an
agreement on the solution has been reached. agreement on the solution has been reached.
skipping to change at page 17, line 22 skipping to change at page 17, line 22
8.2. Informative References 8.2. Informative References
[I-D.holmberg-emergency-callback-id] Holmberg, C., "Session [I-D.holmberg-emergency-callback-id] Holmberg, C., "Session
Initiation Protocol (SIP) Initiation Protocol (SIP)
emergency call back emergency call back
identification", draft- identification", draft-
holmberg-emergency-callback-id- holmberg-emergency-callback-id-
00 (work in progress), 00 (work in progress),
October 2011. October 2011.
[I-D.ietf-ecrit-framework] Rosen, B., Schulzrinne, H.,
Polk, J., and A. Newton,
"Framework for Emergency
Calling using Internet
Multimedia",
draft-ietf-ecrit-framework-13
(work in progress),
September 2011.
[I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best [I-D.ietf-ecrit-phonebcp] Rosen, B. and J. Polk, "Best
Current Practice for Current Practice for
Communications Services in Communications Services in
support of Emergency Calling", support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 draft-ietf-ecrit-phonebcp-20
(work in progress), (work in progress),
September 2011. September 2011.
[I-D.ietf-sip-saml] Tschofenig, H., Hodges, J., [I-D.ietf-sip-saml] Tschofenig, H., Hodges, J.,
Peterson, J., Polk, J., and D. Peterson, J., Polk, J., and D.
skipping to change at page 19, line 5 skipping to change at page 18, line 13
Resource Name (URN) for Resource Name (URN) for
Emergency and Other Well-Known Emergency and Other Well-Known
Services", RFC 5031, Services", RFC 5031,
January 2008. January 2008.
[RFC5234] Crocker, D. and P. Overell, [RFC5234] Crocker, D. and P. Overell,
"Augmented BNF for Syntax "Augmented BNF for Syntax
Specifications: ABNF", STD 68, Specifications: ABNF", STD 68,
RFC 5234, January 2008. RFC 5234, January 2008.
[RFC6444] Schulzrinne, H., Liess, L.,
Tschofenig, H., Stark, B., and
A. Kuett, "Location Hiding:
Problem Statement and
Requirements", RFC 6444,
January 2012.
Appendix A. Alternative Solutions Considered Appendix A. Alternative Solutions Considered
In an attempt to describe the problem and to explore solution In an attempt to describe the problem and to explore solution
approaches the working group had also investigated alternative approaches the working group had also investigated alternative
approaches. We document them here for completeness. The solutions approaches. We document them here for completeness. The solutions
fall into three categories: (1) Identity-based authorization, (2) fall into three categories: (1) Identity-based authorization, (2)
Trait-based authorization, and (3) Call Marking. Even though these Trait-based authorization, and (3) Call Marking. Even though these
solutions are not mutually exclusive we describe them in separate solutions are not mutually exclusive we describe them in separate
sub-sections. sub-sections.
 End of changes. 24 change blocks. 
65 lines changed or deleted 81 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/