draft-ietf-ecrit-data-only-ea-19.txt   draft-ietf-ecrit-data-only-ea-20.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft Internet-Draft
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: July 31, 2020 Columbia U. Expires: August 2, 2020 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
Core Technology Consulting Core Technology Consulting
January 28, 2020 January 30, 2020
Non-Interactive Emergency Calls Non-Interactive Emergency Calls
draft-ietf-ecrit-data-only-ea-19 draft-ietf-ecrit-data-only-ea-20
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) handle Internet multimedia how Public Safety Answering Points (PSAPs) handle Internet multimedia
emergency calls natively. The exchange of multimedia traffic for emergency calls natively. The exchange of multimedia traffic for
emergency services involves a Session Initiation Protocol (SIP) emergency services involves a Session Initiation Protocol (SIP)
session establishment starting with a SIP INVITE that negotiates session establishment starting with a SIP INVITE that negotiates
various parameters for that session. These calls involve a person, various parameters for that session. These calls involve a person,
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 July 31, 2020. This Internet-Draft will expire on August 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 4, line 8 skipping to change at page 4, line 8
message is in the body of the message, using a CID) or by reference message is in the body of the message, using a CID) or by reference
(a URI is included in the message, which when dereferenced returns (a URI is included in the message, which when dereferenced returns
the CAP message). The additional data mechanism is also used to send the CAP message). The additional data mechanism is also used to send
alert specific data beyond that available in the CAP message. This alert specific data beyond that available in the CAP message. This
document also describes how a SIP MESSAGE [RFC3428] transaction can document also describes how a SIP MESSAGE [RFC3428] transaction can
be used to send a non-interactive call. be used to send a non-interactive 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
SIP is the Session Initiation Protocol [RFC3261] SIP is the Session Initiation Protocol [RFC3261]
PIDF-LO is Presence Information Data Format - Location Object, a data PIDF-LO is Presence Information Data Format - Location Object, a data
structure for carrying location [RFC4119] structure for carrying location [RFC4119]
LoST is the Location To Service Translation protocol [RFC5222] LoST is the Location To Service Translation protocol [RFC5222]
CID is Content InDirection [RFC2392] CID is Content InDirection [RFC2392]
skipping to change at page 6, line 19 skipping to change at page 6, line 19
| | | | | |
Sensors | | Sensors | |
trigger | | trigger | |
emergency | | emergency | |
alert | | alert | |
| | | | | |
| | | | | |
| SIP MESSAGE w/CAP | | | SIP MESSAGE w/CAP | |
| (including Service URN, | | (including Service URN, |
| such as urn:service:sos) | | such as urn:service:sos) |
|-------------------| | |------------------>| |
| | | | | |
| ESRP performs | | ESRP performs |
| emergency alert | | emergency alert |
| routing | | routing |
| | MESSAGE with CAP | | | MESSAGE with CAP |
| | (including identity info) | | | (including identity info) |
| |----------------------------->| | |----------------------------->|
| | | | | |
| | PSAP | | PSAP
| | processes | | processes
skipping to change at page 7, line 7 skipping to change at page 7, line 7
A CAP message may be sent in the initial message of any SIP A CAP message may be sent in the initial message of any SIP
transaction. However, this document only addresses sending a CAP transaction. However, this document only addresses sending a CAP
message in a SIP MESSAGE transaction for a one-shot, non-interactive message in a SIP MESSAGE transaction for a one-shot, non-interactive
emergency call. Behavior with other transactions is not defined. emergency call. Behavior with other transactions is not defined.
The CAP message is included in a SIP message as an additional-data The CAP message is included in a SIP message as an additional-data
block [RFC7852]. Accordingly, it is introduced to the SIP message block [RFC7852]. Accordingly, it is introduced to the SIP message
with a Call-Info header field with a purpose of with a Call-Info header field with a purpose of
"EmergencyCallData.cap". The header field may contain a URI that is "EmergencyCallData.cap". The header field may contain a URI that is
used by the recipient (or in some cases, an intermediary) to obtain used by the recipient (or in some cases, an intermediary) to obtain
the CAP message. Alternative, the Call-Info header field may contain the CAP message. Alternatively, the Call-Info header field may
a Content Indirect url [RFC2392] and the CAP message included in the contain a Content Indirect url [RFC2392] and the CAP message included
body of the message. In the latter case, the CAP message is located in the body of the message. In the latter case, the CAP message is
in a MIME block of the type 'application/emergencyCallData.cap+xml'. located in a MIME block of the type 'application/
emergencyCallData.cap+xml'.
If the SIP server does not support the functionality required to If the SIP server does not support the functionality required to
fulfill the request then a 501 Not Implemented MUST be returned as fulfill the request then a 501 Not Implemented will be returned as
specified in [RFC3261]. This is the appropriate response when a User specified in [RFC3261]. This is the appropriate response when a User
Agent Server (UAS) does not recognize the request method and is not Agent Server (UAS) does not recognize the request method and is not
capable of supporting it for any user. capable of supporting it for any user.
The 415 Unsupported Media Type error MUST be returned as specified in The 415 Unsupported Media Type error will be returned as specified in
[RFC3261] if the SIP server is refusing to service the request [RFC3261] if the SIP server is refusing to service the request
because the message body of the request is in a format not supported because the message body of the request is in a format not supported
by the server for the requested method. The server MUST return a by the server for the requested method. The server MUST return a
list of acceptable formats using the Accept, Accept-Encoding, or list of acceptable formats using the Accept, Accept-Encoding, or
Accept-Language header fields, depending on the specific problem with Accept-Language header fields, depending on the specific problem with
the content. the content.
4.2. Profiling of the CAP Document Content 4.2. Profiling of the CAP Document Content
The usage of CAP MUST conform to the specification provided with The usage of CAP MUST conform to the specification provided with
skipping to change at page 10, line 27 skipping to change at page 10, line 27
in [RFC5234]. in [RFC5234].
The AlertMsg-Error header field MUST contain only one ErrorValue to The AlertMsg-Error header field MUST contain only one ErrorValue to
indicate what was wrong with the alert payload the recipient indicate what was wrong with the alert payload the recipient
determined was bad. determined was bad.
The ErrorValue contains a 3-digit error code indicating what was The ErrorValue contains a 3-digit error code indicating what was
wrong with the alert in the request. This error code has a wrong with the alert in the request. This error code has a
corresponding quoted error text string that is human readable. The corresponding quoted error text string that is human readable. The
text string is OPTIONAL, but RECOMMENDED for human readability, text string is OPTIONAL, but RECOMMENDED for human readability,
similar to the string phrase used for SIP response codes. That said, similar to the string phrase used for SIP response codes. The
the strings are complete enough for rendering to the user, if so strings in this document are recommendations, and are not
desired. The strings in this document are recommendations, and are standardized -- meaning an operator can change the strings -- but
not standardized -- meaning an operator can change the strings -- but
MUST NOT change the meaning of the error code. Similar to how RFC MUST NOT change the meaning of the error code. Similar to how RFC
3261 specifies, there MUST NOT be more than one string per error 3261 specifies, there MUST NOT be more than one string per error
code. code.
The AlertMsg-Error header field MAY be included in any response if an The AlertMsg-Error header field MAY be included in any response if an
alert message was in the request part of the same transaction. For alert message was in the request part of the same transaction. For
example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can example, a UA includes an alert in a MESSAGE to a PSAP. The PSAP can
accept this MESSAGE, thus creating a dialog, even though its UA accept this MESSAGE, thus creating a dialog, even though its UA
determined that the alert message contained in the MESSAGE was bad. determined that the alert message contained in the MESSAGE was bad.
The PSAP merely includes an AlertMsg-Error header field value in the The PSAP merely includes an AlertMsg-Error header field value in the
skipping to change at page 21, line 15 skipping to change at page 21, line 15
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
Huitema, C., and D. Gurle, "Session Initiation Protocol Huitema, C., and D. Gurle, "Session Initiation Protocol
(SIP) Extension for Instant Messaging", RFC 3428, (SIP) Extension for Instant Messaging", RFC 3428,
DOI 10.17487/RFC3428, December 2002, DOI 10.17487/RFC3428, December 2002,
<https://www.rfc-editor.org/info/rfc3428>. <https://www.rfc-editor.org/info/rfc3428>.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, Format", RFC 4119, DOI 10.17487/RFC4119, December 2005,
<https://www.rfc-editor.org/info/rfc4119>. <https://www.rfc-editor.org/info/rfc4119>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/info/rfc5222>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, DOI 10.17487/RFC7303, July 2014,
<https://www.rfc-editor.org/info/rfc7303>. <https://www.rfc-editor.org/info/rfc7303>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
skipping to change at page 21, line 48 skipping to change at page 21, line 43
[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, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<https://www.rfc-editor.org/info/rfc6881>. <https://www.rfc-editor.org/info/rfc6881>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/info/rfc7852>. <https://www.rfc-editor.org/info/rfc7852>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
December 2014, <https://www.rfc-editor.org/info/rfc7378>. December 2014, <https://www.rfc-editor.org/info/rfc7378>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[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,
DOI 10.17487/RFC3325, November 2002, DOI 10.17487/RFC3325, November 2002,
<https://www.rfc-editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
<https://www.rfc-editor.org/info/rfc5222>.
[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, DOI 10.17487/RFC6443, December Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <https://www.rfc-editor.org/info/rfc6443>. 2011, <https://www.rfc-editor.org/info/rfc6443>.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
 End of changes. 13 change blocks. 
22 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/