draft-ietf-ecrit-data-only-ea-07.txt   draft-ietf-ecrit-data-only-ea-08.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar, Inc. Internet-Draft NeuStar, Inc.
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: August 18, 2014 Columbia U. Expires: January 25, 2015 Columbia U.
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
February 14, 2014 July 24, 2014
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-07.txt draft-ietf-ecrit-data-only-ea-08.txt
Abstract Abstract
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
describes how devices use the Internet to place emergency calls and describes how devices use the Internet to place emergency calls and
how Public Safety Answering Points (PSAPs) can handle Internet how Public Safety Answering Points (PSAPs) can handle Internet
multimedia emergency calls natively. The exchange of multimedia multimedia emergency calls natively. The exchange of multimedia
traffic typically involves a SIP session establishment starting with traffic typically involves a SIP session establishment starting with
a SIP INVITE that negotiates various parameters for that session. a SIP INVITE that negotiates various parameters for that session.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 18, 2014. This Internet-Draft will expire on January 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 44 skipping to change at page 3, line 44
citizen to authority "alerts", where the alert is sent without any citizen to authority "alerts", where the alert is sent without any
interactive media. interactive media.
This document describes a method of including a CAP message in a SIP This document describes a method of including a CAP message in a SIP
transaction, either by value (CAP message is in the body of the transaction, either by value (CAP message is in the body of the
message, using a CID) or by reference (A URI is included in the message, using a CID) or by reference (A URI is included in the
message, which when dereferenced returns the CAP message) by defining message, which when dereferenced returns the CAP message) by defining
it as a block of "additional data" as defined in it as a block of "additional data" as defined in
[I-D.ietf-ecrit-additional-data]. The additional data mechanism is [I-D.ietf-ecrit-additional-data]. The additional data mechanism is
also used to send alert specific data beyond that available in the also used to send alert specific data beyond that available in the
CAP message. CAP message. This document also describes how a SIP MESSAGE
[RFC3428] transaction can be used to send a data-only call.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Architectural Overview 3. Architectural Overview
This section illustrates two envisioned usage modes; targeted and This section illustrates two envisioned usage modes; targeted and
skipping to change at page 5, line 34 skipping to change at page 5, line 34
| | | |
Figure 1: Targeted Emergency Alert Routing Figure 1: Targeted Emergency Alert Routing
In Figure 2 a scenario is shown whereby the alert is routed using In Figure 2 a scenario is shown whereby the alert is routed using
location information and the Service URN. An emergency services location information and the Service URN. An emergency services
routing proxy (ESRP) may use LoST to determine the next hop proxy to routing proxy (ESRP) may use LoST to determine the next hop proxy to
route the alert message to. A possible receiver is a PSAP and the route the alert message to. A possible receiver is a PSAP and the
recipient of the alert may be call taker. In the generic case, there recipient of the alert may be call taker. In the generic case, there
is very likely no prior relationship between the originator and the is very likely no prior relationship between the originator and the
receiver, e.g. PSAP. A PSAP, for example, is likely to receive and receiver, e.g. PSAP. A PSAP, for example, is likely to receive and
accept alerts from entities it cannot authorize. This scenario accept alerts from entities it cannot authorize. This scenario
corresponds more to the classical emergency services use case and the corresponds more to the classical emergency services use case and the
description in [RFC6881] is applicable. In this use case, the only description in [RFC6881] is applicable. In this use case, the only
difference between an emergency call, and an emergency data-only call difference between an emergency call, and an emergency data-only call
is that the former uses INVITE and creates a session and negotiates is that the former uses INVITE, creates a session and negotiates one
one or more media streams, and the latter uses MESSAGE, does not or more media streams, while the latter uses MESSAGE, does not create
create a session and does not have media. a session and does not have media.
+-----------+ +----------+ +-----------+ +----------+
+--------+ | ESRP | | PSAP | +--------+ | ESRP | | PSAP |
| Sensor | | | | | | Sensor | | | | |
+---+----+ +---+-------+ +---+------+ +---+----+ +---+-------+ +---+------+
| | | | | |
Sensors | | Sensors | |
trigger | | trigger | |
emergency | | emergency | |
alert | | alert | |
skipping to change at page 6, line 48 skipping to change at page 6, line 48
| | | | | |
Figure 2: Location-Based Emergency Alert Routing Figure 2: Location-Based Emergency Alert Routing
4. Protocol Specification 4. Protocol Specification
4.1. CAP Transport 4.1. CAP Transport
A CAP message may be sent on the initial message of any SIP A CAP message may be sent on the initial message of any SIP
transaction. However, this document only describes specific behavior transaction. However, this document only describes specific behavior
when used with a SIP MESSAGE transaction for a one-shot, data-only when used with a SIP INVITE that would accompany a normal emergency
call and a SIP MESSAGE transaction for a one-shot, data-only
emergency call. Behavior with other transactions is not defined. emergency call. Behavior with other transactions is not defined.
The CAP message included in a SIP message as an additional-data block The CAP message included in a SIP message as an additional-data block
[I-D.ietf-ecrit-additional-data]. Accordingly, it is introduced to [I-D.ietf-ecrit-additional-data]. Accordingly, it is introduced to
the SIP message with a Call-Info header with a purpose of the SIP message with a Call-Info header with a purpose of
"emergencyCall.cap". The header may contain a URI that is used by "emergencyCall.cap". The header may contain a URI that is used by
the recipient (or in some cases, an intermediary) to obtain the CAP the recipient (or in some cases, an intermediary) to obtain the CAP
message. Alternative, the Call-Info header may contain a Content message. Alternative, the Call-Info header may contain a Content
Indirect url [RFC2392] and the CAP message included in the body of Indirect url [RFC2392] and the CAP message included in the body of
the message. In either case, the CAP message is located in a MIME the message. In either case, the CAP message is located in a MIME
skipping to change at page 21, line 5 skipping to change at page 21, line 5
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
for Event State Publication", RFC 3903, October 2004.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, December for the Session Initiation Protocol", RFC 6442, December
2011. 2011.
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665,
July 2012.
[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.
[I-D.ietf-ecrit-additional-data] [I-D.ietf-ecrit-additional-data]
Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J. Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J.
Winterbottom, "Additional Data related to an Emergency Winterbottom, "Additional Data related to an Emergency
Call", draft-ietf-ecrit-additional-data-20 (work in Call", draft-ietf-ecrit-additional-data-22 (work in
progress), February 2014. progress), April 2014.
[I-D.rosen-ecrit-addldata-subnot] [I-D.rosen-ecrit-addldata-subnot]
Rosen, B., "Updating Additional Data related to an Rosen, B., "Updating Additional Data related to an
Emergency Call using Subscribe/ Notify", draft-rosen- Emergency Call using Subscribe/ Notify", draft-rosen-
ecrit-addldata-subnot-01 (work in progress), November ecrit-addldata-subnot-01 (work in progress), November
2013. 2013.
13.2. Informative References 13.2. Informative References
[I-D.ietf-ecrit-trustworthy-location] [I-D.ietf-ecrit-trustworthy-location]
Tschofenig, H., Schulzrinne, H., and B. Aboba, Tschofenig, H., Schulzrinne, H., and B. Aboba,
"Trustworthy Location", draft-ietf-ecrit-trustworthy- "Trustworthy Location", draft-ietf-ecrit-trustworthy-
location-08 (work in progress), January 2014. location-13 (work in progress), June 2014.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
 End of changes. 12 change blocks. 
19 lines changed or deleted 15 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/