< draft-ietf-ecrit-data-only-ea-16.txt   draft-ietf-ecrit-data-only-ea-17.txt >
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft Internet-Draft
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: April 26, 2019 Columbia U. Expires: September 12, 2019 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
Core Technology Consulting Core Technology Consulting
October 23, 2018 March 11, 2019
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-16 draft-ietf-ecrit-data-only-ea-17
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. various parameters for that session.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 April 26, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
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 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 4
4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 6
4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 6 4.1. CAP Transport . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Profiling of the CAP Document Content . . . . . . . . . . 7 4.2. Profiling of the CAP Document Content . . . . . . . . . . 7
4.3. Sending a Data-Only Emergency Call . . . . . . . . . . . 8 4.3. Sending a Data-Only Emergency Call . . . . . . . . . . . 8
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 8 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 9 5.1. 425 (Bad Alert Message) Response Code . . . . . . . . . . 9
5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 9 5.2. The AlertMsg-Error Header Field . . . . . . . . . . . . . 9
6. Call Backs . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Call Backs . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Handling Large Amounts of Data . . . . . . . . . . . . . . . 11 7. Handling Large Amounts of Data . . . . . . . . . . . . . . . 11
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Registration of the 10.1. Registration of the
'application/EmergencyCallData.cap+xml' MIME type . . . 17 'application/EmergencyCallData.cap+xml' MIME type . . . 17
10.2. IANA Registration of 'cap' Additional Data Block . . . . 18 10.2. IANA Registration of 'cap' Additional Data Block . . . . 18
10.3. IANA Registration for 425 Response Code . . . . . . . . 18 10.3. IANA Registration for 425 Response Code . . . . . . . . 18
10.4. IANA Registration of New AlertMsg-Error Header Field . . 19 10.4. IANA Registration of New AlertMsg-Error Header Field . . 19
10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19 10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 21
skipping to change at page 8, line 28 skipping to change at page 8, line 28
message routing is performed by SIP and the respective address message routing is performed by SIP and the respective address
information is already available in other SIP header fields. information is already available in other SIP header fields.
Populating information twice into different parts of the message Populating information twice into different parts of the message
may lead to inconsistency. may lead to inconsistency.
parameter: The <parameter> element MAY contain additional parameter: The <parameter> element MAY contain additional
information specific to the sender. information specific to the sender.
area: It is RECOMMENDED to omit this element when constructing a area: It is RECOMMENDED to omit this element when constructing a
message. If the CAP message already contains an <area> element, message. If the CAP message already contains an <area> element,
then the specified location information SHOULD be copied into the then the specified location information SHOULD be copied into a
PIDF-LO structure referenced by the 'geolocation' header field. PIDF-LO structure referenced by the 'geolocation' header field.
If there is a need to copy the PIDF-LO structure referenced by
'geolocation' to <area>, implementers must be aware that <area> is
limited to a circle or polygon, and conversion of other shapes
will be required. Points SHOULD be converted to a circle with a
radius equal to the uncertainty of the point. Arc-bands and
ellipses SHOULD be converted to an equivalent polygon. 3D
locations SHOULD be converted to their equivalent 2D forms.
4.3. Sending a Data-Only Emergency Call 4.3. Sending a Data-Only Emergency Call
A data-only emergency call is sent using a SIP MESSAGE transaction A data-only emergency call is sent using a SIP MESSAGE transaction
with a CAP URI or body part as described above in a manner similar to with a CAP URI or body part as described above in a manner similar to
how an emergency call with interactive media is sent, as described in how an emergency call with interactive media is sent, as described in
[RFC6881]. The MESSAGE transaction does not create a session nor [RFC6881]. The MESSAGE transaction does not create a session nor
establish interactive media streams, but otherwise, the header establish interactive media streams, but otherwise, the header
content of the transaction, routing, and processing of data-only content of the transaction, routing, and processing of data-only
calls are the same as those of other emergency calls. calls are the same as those of other emergency calls.
 End of changes. 9 change blocks. 
8 lines changed or deleted 15 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/