Non-interactive Emergency Calls
RFC 8876
Document | Type | RFC - Proposed Standard (September 2020; No errata) | |
---|---|---|---|
Authors | Brian Rosen , Henning Schulzrinne , Hannes Tschofenig , Randall Gellens | ||
Last updated | 2020-09-25 | ||
Replaces | draft-rosen-ecrit-data-only-ea | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication (wg milestone: Aug 2017 - Submit 'Common Alert... ) | |
Document shepherd | Allison Mankin | ||
Shepherd write-up | Show (last changed 2019-04-16) | ||
IESG | IESG state | RFC 8876 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Adam Roach | ||
Send notices to | "Allison Mankin" <allison.mankin@gmail.com>, <draft-ietf-ecrit-data-only-ea@ietf.org> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack | ||
IANA expert review state | Expert Reviews OK | ||
IANA expert review comments | I reviewed Section 10.2 and it meets the requirements of RFC 7852. I approve. |
Internet Engineering Task Force (IETF) B. Rosen Request for Comments: 8876 Category: Standards Track H. Schulzrinne ISSN: 2070-1721 Columbia U. H. Tschofenig R. Gellens Core Technology Consulting September 2020 Non-interactive Emergency Calls Abstract Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8876. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Terminology 3. Architectural Overview 4. Protocol Specification 4.1. CAP Transport 4.2. Profiling of the CAP Document Content 4.3. Sending a Non-interactive Emergency Call 5. Error Handling 5.1. 425 (Bad Alert Message) Response Code 5.2. The AlertMsg-Error Header Field 6. Call Backs 7. Handling Large Amounts of Data 8. Example 9. Security Considerations 10. IANA Considerations 10.1. 'application/EmergencyCallData.cap+xml' Media Type 10.2. 'cap' Additional Data Block 10.3. 425 Response Code 10.4. AlertMsg-Error Header Field 10.5. SIP AlertMsg-Error Codes 11. References 11.1. Normative References 11.2. Informative References Acknowledgments Authors' Addresses 1. Introduction [RFC6443] describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively. The exchange of multimedia traffic for emergency services involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, there is only application data to be conveyed from the end devices to a PSAP or an intermediary. Examples of such environments include sensors issuing alerts, and certain types of medical monitors. These messages may be alerts to emergency authorities and do not require establishment of a session. These types of interactions are called 'non-interactive emergency calls'. In this document, we use the term "call" so that similarities between non-interactive alerts and sessions with interactive media are more obvious. Non-interactive emergency calls are similar to regular emergency calls in the sense that they require the emergency indications, emergency call routing functionality, and location. However, the communication interaction will not lead to the exchange of interactive media, that is, Real-Time Transport Protocol [RFC3550]Show full document text