Non-interactive Emergency Calls
RFC 8876
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