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
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
Consensus Boilerplate Yes
Telechat date
Responsible AD Adam Roach
Send notices to "Allison Mankin" <>, <>
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


   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

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
   ( 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
   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

   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