RFC 8876

Non-interactive Emergency Calls

📅 published September 2020, from ietf

RFC 8876: Non-interactive Emergency Calls 🚨✨

  • Number: RFC 8876
  • Title: Non-interactive Emergency Calls
  • Authors: B. Rosen, H. Schulzrinne (Columbia U.), H. Tschofenig, and R. Gellens (Core Technology Consulting) 💜
  • Category: Standards Track 👑
  • Date: September 2020 🍓
  • ISSN: 2070-1721
  • Obsoletes and updates: the title block doesn't list anything this document obsoletes or updates 🌸

This is an IETF doc, so it's the official "here's how it works" spec for the Internet 🦋

Abstract ✨

okay bestie, so there's already a whole framework for emergency calling over the Internet, and it's called RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia' 🎀 Usually an emergency call has two-way media like voice, video, or text. But sometimes all you need to send is application data, and no interactive media channel gets set up at all. That's what 'non-interactive emergency calls' are 🫶

This doc describes using a SIP MESSAGE transaction with a container for the data, and that container is based on the Common Alerting Protocol (CAP) 💅 The big difference is that this kind of emergency request doesn't establish a session, which is the thing SIP INVITE does 🧚 So any device that needs to ask 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 👑

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 💖 If you want more info on Internet Standards, check Section 2 of RFC 7841 ✨

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8876 🦋

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) as they stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come 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 🦋

Okay so [RFC6443] explains how devices use the Internet to place emergency calls, and how Public Safety Answering Points (PSAPs) handle Internet multimedia emergency calls natively 💅 Normally, multimedia emergency traffic starts with a SIP session establishment, beginning with a SIP INVITE that negotiates the parameters for that session ✨

But sometimes there's only application data that needs to go from the end device to a PSAP or an intermediary 🧚 Think sensors sending alerts, or certain medical monitors 🩺 These messages can be alerts to emergency authorities, and they don't need a session to be set up at all. We call these 'non-interactive emergency calls' 🌸 In this doc we say "call" anyway, so it's easier to see how non-interactive alerts are similar to sessions that have interactive media 💜

Non-interactive emergency calls are a lot like regular emergency calls, because they still need the emergency indications, the emergency call routing functionality, and location 🎀 The difference is that the communication won't lead to any interactive media, meaning no Real-Time Transport Protocol [RFC3550] packets carrying voice, video, or real-time text 🙈

The Common Alerting Protocol (CAP) [CAP] is a format for exchanging emergency alerts and public warnings 🚨 It's mostly used to send alerts and warnings from authorities to each other and from authorities to the public 🌈 The scope of this document is narrower: it's about sending CAP alerts from private devices to emergency service authorities as a call with no interactive media at all 🫶

This document describes a way to include a CAP alert in a SIP transaction by defining it as a block of "additional data," as defined in [RFC7852] 💖 The CAP alert can be included either by value, meaning it's in the body of the message and referenced with a CID, or by reference, meaning the message includes a URI that returns the CAP alert when you dereference it 🦋 The additional data mechanism is also used to send alert-specific data that goes beyond what's in the CAP alert ✨ Finally, this document describes how a SIP MESSAGE [RFC3428] transaction can be used to send a non-interactive call 👑

2. Terminology 💅

Here's the key-word bit, bestie. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 🔥

Now the vocab list 📚

  • Non-interactive emergency call: An emergency call where there is no two-way interactive media 🌸
  • SIP: Session Initiation Protocol [RFC3261] 💜
  • PIDF-LO: Presence Information Data Format Location Object, a data structure for carrying location [RFC4119] 🎀
  • LoST: Location To Service Translation protocol [RFC5222] 🧚
  • CID: Content-ID [RFC2392] 🦋
  • CAP: Common Alerting Protocol [CAP] ✨
  • PSAP: Public Safety Answering Point, the call center for emergency calls 🚨
  • ESRP: Emergency Services Routing Proxy, a type of SIP Proxy Server used in some emergency services networks 👑

3. Architectural Overview 🦋

okay bestie, this section shows off the two usage modes they had in mind: targeted and location-based emergency alert routing 🧚

  1. Emergency alerts containing only data are targeted to an intermediary recipient responsible for evaluating the next steps. These steps could include:
    • a. Sending a non-interactive call containing only data towards a Public Safety Answering Point (PSAP);
    • b. Establishing a third-party-initiated emergency call towards a PSAP that could include audio, video, and data.
  2. Emergency alerts may be targeted to a service URN [RFC5031] used for IP-based emergency calls where the recipient is not known to the originator. In this scenario, the alert may contain only data (e.g., a SIP MESSAGE with CAP content, a Geolocation header field, and one or more Call-Info header fields containing additional data [RFC7852]).

Figure 1 is a deployment variant where a sensor is pre-configured (using techniques outside the scope of this document) to issue an alert to an aggregator. The aggregator processes these messages and does whatever is needed to react to the alert appropriately. For example, a security firm might use different sensor inputs to dispatch their security staff to a building they protect or to start a third-party emergency call 👮‍♀️🚨

    +------------+              +------------+
    | Sensor     |              | Aggregator |
    |            |              |            |
    +---+--------+              +------+-----+
        |                              |
     Sensors                           |
     trigger                           |
     emergency                         |
     alert                             |
        |    SIP MESSAGE with CAP      |
        |----------------------------->|
        |                              |
        |                           Aggregator
        |                           processes
        |                           emergency
        |                           alert
        |      SIP 200 (OK)            |
        |<-----------------------------|
        |                              |
        |                              |

                 Figure 1: Targeted Emergency Alert Routing

In Figure 2, the alert is routed using location information and a service URN. An emergency services routing proxy (ESRP) may use LoST (a protocol defined by [RFC5222], which translates a location to a URI used to route an emergency call) to determine the next-hop proxy to route the alert message to. A possible receiver is a PSAP, and the recipient of the alert may be a call taker. In the generic case, there is very likely no prior relationship between the originator and the receiver, e.g., a PSAP. For example, a PSAP is likely to receive and accept alerts from entities it has no previous relationship with. This scenario is similar to a classic voice emergency services call, and the description in [RFC6881] is applicable. In this use case, the only difference between an emergency call and an emergency non-interactive call is that the former uses INVITE, creates a session, and negotiates one or more media streams, while the latter uses MESSAGE, does not create a session, and does not have interactive media. 📞✨

      +----------+         +----------+                  +-----------+
      |Sensor or |         |  ESRP    |                  |   PSAP    |
      |Aggregator|         |          |                  |           |
      +----+-----+         +---+------+                  +----+------+
           |                   |                              |
        Sensors                |                              |
        trigger                |                              |
        emergency              |                              |
        alert                  |                              |
           |                   |                              |
           |                   |                              |
           | SIP MESSAGE w/CAP |                              |
           | (including service URN,                          |
           | such as urn:service:sos)                         |
           |------------------>|                              |
           |                   |                              |
           |              ESRP performs                       |
           |              emergency alert                     |
           |              routing                             |
           |                   |  MESSAGE with CAP            |
           |                   |  (including identity info)   |
           |                   |----------------------------->|
           |                   |                              |
           |                   |                           PSAP
           |                   |                           processes
           |                   |                           emergency
           |                   |                           alert
           |                   |      SIP 200 (OK)            |
           |                   |<-----------------------------|
           |                   |                              |
           |  SIP 200 (OK)     |                              |
           |<------------------|                              |
           |                   |                              |
           |                   |                              |

              Figure 2: Location-Based Emergency Alert Routing

4. Protocol Specification 💖

4.1. CAP Transport 🎀

This document addresses sending a CAP alert in a SIP MESSAGE transaction for a non-interactive emergency call. Behavior with other transactions is not defined.

The CAP alert is included in a SIP message as an additional data block [RFC7852]. So it gets conveyed in the SIP message with a Call-Info header field whose purpose is "EmergencyCallData.cap". The header field may contain a URI that the recipient (or, in some cases, an intermediary) uses to grab the CAP alert. Alternatively, the Call-Info header field may contain a Content-ID URL [RFC2392] and the CAP alert included in the body of the message. In the latter case, the CAP alert lives in a MIME block of the type 'application/emergencyCallData.cap+xml'. 📦

If the SIP server doesn't support the functionality needed to fulfill the request, then a 501 Not Implemented will be returned as specified in [RFC3261]. This is the right response when a User Agent Server (UAS) doesn't recognize the request method and isn't able to support it for any user. 🙅‍♀️

The 415 Unsupported Media Type error will be returned as specified in [RFC3261] if the SIP server is refusing to service the request because the message body of the request is in a format the server doesn't support for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header fields, depending on the specific problem with the content. 🌈

4.2. Profiling of the CAP Document Content 💅

The usage of CAP MUST conform to the specification provided with [CAP]. For usage with SIP, the following additional requirements are imposed (where "sender" and "author" are as defined in CAP and "originator" is the entity sending the CAP alert, which may be different from the entity sending the SIP MESSAGE):

sender: Here's the lowdown on setting the value of the <sender> element:

  • Originator is a SIP entity, Author indication irrelevant: When the alert was created by a SIP-based originator and it is not useful to be explicit about the author of the alert, then the <sender> element MUST be populated with the SIP URI of the user agent.
  • Originator is a non-SIP entity, Author indication irrelevant: When the alert was created by a non-SIP-based entity and the identity of this original sender is to be preserved, then this identity MUST be placed into the <sender> element. In this situation, it is not useful to be explicit about the author of the alert. The specific type of identity being used will depend on the technology used by the originator.
  • Author indication relevant: When the author is different from the originator of the message and this distinction should be preserved, then the <sender> element MUST NOT contain the SIP URI of the user agent.

incidents: The <incidents> element MUST be present. This incident identifier MUST be chosen in such a way that it is unique for a given <sender, expires, incidents> combination. Note that the <expires> element is OPTIONAL and might not be present. 🔍

scope: The value of the <scope> element MAY be set to "Private" if the alert is not meant for public consumption. The <addresses> element is, however, not used by this specification, since message routing is performed by SIP and the respective address information is already available in other SIP header fields. Populating information twice into different parts of the message may lead to inconsistency. 🙈

parameter: The <parameter> element MAY contain additional information specific to the sender, conforming to the CAP alert syntax. ✨

area: It is RECOMMENDED to omit this element when constructing a message. If the CAP alert is given to the SIP entity to transport and it already contains an <area> element, then the specified location information SHOULD be copied into a PIDF-LO structure (the data format for location used by emergency calls on the Internet) referenced by the SIP Geolocation header field. If the CAP alert is being created by the SIP entity using a PIDF-LO structure referenced by geolocation to construct <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 polygons with similar coverage, and 3D locations SHOULD be converted to 2D forms with similar coverage. 🗺️

4.3. Sending a Non-interactive Emergency Call 📨

A non-interactive emergency call is sent using a SIP MESSAGE transaction with a CAP URI or body part as described above. It works similarly to how an emergency call with interactive media is sent, as described in [RFC6881]. The MESSAGE transaction does not create a session nor establish interactive media streams, but otherwise, the header content of the transaction, routing, and processing of non-interactive calls are the same as those of other emergency calls. 🎉

5. Error Handling 🚨

This section defines a new error response code and a header field for additional information. 🦋

5.1. 425 (Bad Alert Message) Response Code ✨

Okay so this SIP extension creates a brand new response code, and it's giving main character energy 🦋

425 (Bad Alert Message)

425 is a rejection of the request 🚫 It gets sent when the request is so malformed that nobody can work out a reasonable emergency response to the alert. Honestly that's a lot of drama for one status code 💀

A SIP intermediary can also use this code to reject an alert it gets from a User Agent (UA), but only when it spots that the alert is malformed 🔍

Here's the tea: the [Section 5.2] header field, AlertMsg-Error, explains what was wrong with the alert in the request, and it MUST be included in the 425 response 📝 No skipping it, periodt 💅

Emergency calls are usually NOT rejected if there's any useful info that can be acted on 🫶 So a 425 only makes sense when the responding entity has no other usable information in the request. Like, it's the last resort, not the first move 🌸

A 425 response code MUST NOT be sent in response to a request that lacks an alert message (i.e., CAP data) 🙅‍♀️ Why? Because the user agent in that case may not support this extension, and that's just not fair to them 🥺

A 425 response is a final response within a transaction, and it MUST NOT terminate an existing dialog 🧚 It closes out the transaction, but the dialog stays alive, iykyk ✨

5.2. The AlertMsg-Error Header Field 🎀

The AlertMsg-Error header field gives extra detail about what was wrong with the original request 🔎 Sometimes that info is for debugging, so it's super useful for the devs 🛠️

The AlertMsg-Error header field has the following ABNF [RFC5234]:

   message-header   =/ AlertMsg-Error
                           ; (message-header from RFC 3261)
   AlertMsg-Error   = "AlertMsg-Error" HCOLON
                           ErrorValue
   ErrorValue       =  error-code
                            *(SEMI error-params)
   error-code       = 3DIGIT
   error-params     = error-code-text
                            / generic-param ; from RFC 3261
   error-code-text  = "message" EQUAL quoted-string ; from RFC 3261

HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined in [RFC5234].

The AlertMsg-Error header field MUST contain only one ErrorValue to say what was wrong with the alert payload the recipient decided was bad 🎯 One is the magic number, no more 🔥

The ErrorValue has a 3-digit error code saying what went wrong with the alert in the request 🔢 Each code comes with a human-readable quoted error text string 📖 That string is OPTIONAL, but RECOMMENDED for human readability, kind of like the phrase that goes with SIP response codes 💜 The strings in this document are recommendations and are not standardized, which means an operator can change the strings but MUST NOT change the meaning of the error code 🙅 The code space for ErrorValue is separate from SIP Status Codes, so don't mix them up 🧃

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 example, say a UA puts an alert in a MESSAGE to a PSAP 📱 The PSAP can accept that MESSAGE even though the UA decided the alert inside was bad. The PSAP just adds an AlertMsg-Error header field value to the 200 OK to the MESSAGE, which tells the UA "got your message, but the alert was bad" 💌

But if the PSAP can't accept the transaction without a suitable alert message, then a 425 response gets sent 💀

A SIP intermediary that needs the UA's alert message to process the transaction properly may also send a 425 response with an AlertMsg-Error code 🧚‍♀️

This document defines an initial list of AlertMsg-Error values for any SIP response, including provisional responses (other than 100 Trying) and the new 425 response 📋 There MUST NOT be more than one AlertMsg-Error code in a SIP response 🚫 AlertMsg-Error values sent in provisional responses MUST be sent using the mechanism defined in [RFC3262]. If that mechanism isn't negotiated, they MUST be repeated in the final response to the transaction 🔁

AlertMsg-Error: 100 ; message="Cannot process the alert payload"

AlertMsg-Error: 101 ; message="Alert payload was not present or could
not be found"

AlertMsg-Error: 102 ; message="Not enough information to determine
the purpose of the alert"

AlertMsg-Error: 103 ; message="Alert payload was corrupted"

Also, if an entity can't or chooses not to process the alert message from a SIP request, a 500 (Server Internal Error) SHOULD be used, with or without a configurable Retry-After header field 🌈 Bestie, that's the whole list of options 💅

6. Call Backs 📞

This document doesn't describe any way for the recipient to call back the sender of a non-interactive call 🙈 Usually these alerts are sent by automata, which don't have a way to receive calls of any kind 🤖 The identifier in the 'From' header field might help you find more info, but any such mechanism is NOT defined in this document 🔍 The CAP alert may include related contact information for the sender 📇

7. Handling Large Amounts of Data 📦

Sensors can have big piles of data they want to send 🧺 Putting large amounts (tens of kilobytes) into a MESSAGE is not advisable, because SIP entities usually aren't equipped to handle very large messages 😭 So in those cases the sender SHOULD use the by-reference mechanisms defined in [RFC7852] 🔗 That means making the data available over HTTPS [RFC2818] (either at the originator or at another entity), putting a URI to the data in the 'Call-Info' header field, and having the recipient use HTTPS to fetch it ✨ The CAP alert itself can be sent by reference this way, and so can any or all of the additional data blocks that hold sensor-specific data 🧚

There are no rate-limiting mechanisms for any SIP transactions that are standardized, although implementations often include such functions 🚦 Non-interactive emergency calls are typically handled the same as any emergency call, which means a human call-taker is involved 🧑‍💻 Implementations should take note of this limitation, especially when calls are placed automatically without human initiation 🫶 Lowkey, this one matters a LOT 😭

8. Example ✨

okay so this one is the good stuff 🎀 we've got a CAP doc flagging a BURGLARY alert from a sensor called 'sensor1@example.com' 🚨. Where the sensor is? You can find that in the location info attached through the 'Geolocation' header field inside the SIP MESSAGE 📍. Bonus drama: the sensor also sent some data along with the alert, using proprietary info elements that only the receiver is supposed to process, and that receiver is a SIP entity acting as an aggregator 🧚

      MESSAGE sip:aggregator@example.com SIP/2.0
      Via: SIP/2.0/TCP sensor1.example.com;branch=z9hG4bK776sgdkse
      Max-Forwards: 70
      From: sip:sensor1@example.com;tag=49583
      To: sip:aggregator@example.com
      Call-ID: asd88asd77a@2001:db8::ff
      Geolocation: <cid:abcdef@example.com>
        ;routing-allowed=yes
      Supported: geolocation
      CSeq: 1 MESSAGE
      Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
      Content-Type: multipart/mixed; boundary=boundary1
      Content-Length: ...

      --boundary1
      Content-Type: application/EmergencyCallData.cap+xml
      Content-ID: <abcdef2@example.com>
      Content-Disposition: by-reference;handling=optional

      <?xml version="1.0" encoding="UTF-8"?>

      <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
       <identifier>S-1</identifier>
       <sender>sip:sensor1@example.com</sender>
       <sent>2020-01-04T20:57:35Z</sent>
       <status>Actual</status>
       <msgType>Alert</msgType>
       <scope>Private</scope>
       <incidents>abc1234</incidents>
       <info>
           <category>Security</category>
           <event>BURGLARY</event>
           <urgency>Expected</urgency>
           <certainty>Likely</certainty>
           <severity>Moderate</severity>
           <senderName>SENSOR 1</senderName>
           <parameter>
             <valueName>SENSOR-DATA-NAMESPACE1</valueName>
             <value>123</value>
           </parameter>
           <parameter>
             <valueName>SENSOR-DATA-NAMESPACE2</valueName>
             <value>TRUE</value>
           </parameter>
       </info>
     </alert>

      --boundary1
      Content-Type: application/pidf+xml
      Content-ID: <abcdef2@example.com>

      <?xml version="1.0" encoding="UTF-8"?>
          <presence
             xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gbp=
                    "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
             xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
             xmlns:gml="http://www.opengis.net/gml"
             xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
             entity="pres:alice@atlanta.example.com">
           <dm:device id="sensor">
             <gp:geopriv>
               <gp:location-info>
                 <gml:location>
                   <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                     <gml:pos>44.85249659 -93.238665712</gml:pos>
                   </gml:Point>
                </gml:location>
               </gp:location-info>
               <gp:usage-rules>
                 <gbp:retransmission-allowed>false
                 </gbp:retransmission-allowed>
                 <gbp:retention-expiry>2020-02-04T20:57:29Z
                 </gbp:retention-expiry>
               </gp:usage-rules>
               <gp:method>802.11</gp:method>
             </gp:geopriv>
             <dm:timestamp>2020-01-04T20:57:29Z</dm:timestamp>
           </dm:device>
         </presence>
      --boundary1--

Figure 3: Example Message Conveying an Alert to an Aggregator

And then the SAME CAP doc gets sent as a non-interactive emergency call toward a PSAP 📞✨ it's giving consistency, bestie 🫶

      MESSAGE urn:service:sos SIP/2.0
      Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa
      Max-Forwards: 70
      From: sip:aggregator@example.com;tag=32336
      To: 112
      Call-ID: asdf33443a@example.com
      Route: sip:psap1.example.gov
      Geolocation: <cid:abcdef@example.com>
        ;routing-allowed=yes
      Supported: geolocation
      Call-info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap
      CSeq: 1 MESSAGE
      Content-Type: multipart/mixed; boundary=boundary1
      Content-Length: ...

      --boundary1

      Content-Type: application/EmergencyCallData.cap+xml
      Content-ID: <abcdef2@example.com>
     <?xml version="1.0" encoding="UTF-8"?>

     <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
       <identifier>S-1</identifier>
       <sender>sip:sensor1@example.com</sender>
       <sent>2020-01-04T20:57:35Z</sent>
       <status>Actual</status>
       <msgType>Alert</msgType>
       <scope>Private</scope>
       <incidents>abc1234</incidents>
       <info>
           <category>Security</category>
           <event>BURGLARY</event>
           <urgency>Expected</urgency>
           <certainty>Likely</certainty>
           <severity>Moderate</severity>
           <senderName>SENSOR 1</senderName>
           <parameter>
             <valueName>SENSOR-DATA-NAMESPACE1</valueName>
             <value>123</value>
           </parameter>
           <parameter>
             <valueName>SENSOR-DATA-NAMESPACE2</valueName>
             <value>TRUE</value>
           </parameter>
       </info>
      </alert>

      --boundary1

      Content-Type: application/pidf+xml
      Content-ID: <abcdef2@example.com>
      <?xml version="1.0" encoding="UTF-8"?>
          <presence
             xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gbp=
                    "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
             xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
             xmlns:gml="http://www.opengis.net/gml"
             xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
             entity="pres:alice@atlanta.example.com">
           <dm:device id="sensor">
             <gp:geopriv>
               <gp:location-info>
                 <gml:location>
                   <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                     <gml:pos>44.85249659 -93.2386657124</gml:pos>
                   </gml:Point>
                </gml:location>
               </gp:location-info>
               <gp:usage-rules>
                 <gbp:retransmission-allowed>false
                 </gbp:retransmission-allowed>
                 <gbp:retention-expiry>2020-02-04T20:57:25Z
                 </gbp:retention-expiry>
               </gp:usage-rules>
               <gp:method>802.11</gp:method>
             </gp:geopriv>
             <dm:timestamp>2020-01-04T20:57:25Z</dm:timestamp>
           </dm:device>
         </presence>
      --boundary1--

Figure 4: Example Message Conveying an Alert to a PSAP

9. Security Considerations 🔐✨

Okay bestie, this is the serious part, so let's get into it 🫶 This section is about the security stuff when SIP user agents send emergency alerts using MESSAGE and CAP. Location-specific threats aren't unique to this doc, so go check [RFC7378] and [RFC6442] for those 🌸

The ECRIT emergency services architecture [RFC6443] is all about classic individual-to-authority emergency calling, where the caller's identity doesn't matter when the call gets set up. Like, the response to an emergency call doesn't depend on who the caller is 💁‍♀️ But sensor alerts are a different vibe. Their processing might be different so there are fewer falsely generated alerts 🚨 A sensor can trigger off input that has nothing to do with a real alert-relevant event. For example, a sensor might just be malfunctioning 🙃 So not every alert goes straight to a PSAP. Some get pre-processed by a separate entity, possibly with a human supervising, to filter alerts and maybe connect them with others to see the bigger picture of what's going on 🧩

For alerts from sensors, identity can seriously matter when deciding whether to accept or ignore an incoming alert message 👀 With the scenario in Figure 1, it's very likely that only authenticated sensor input gets processed. So it needs to be possible to refuse alert messages from unknown origins 🙅‍♀️ Two types of information elements can help with that:

  1. SIP itself has security mechanisms that let you verify the originator's identity, like P-Asserted-Identity [RFC3325] or SIP Identity [RFC8224]. The latter gives you cryptographic assurance, while the former relies on a chain-of-trust model. These mechanisms can be reused 🔁
  2. CAP has its own extra security mechanisms and can carry more info about the sender's identity. Section 3.3.4.1 of [CAP] specifies the signing algorithms of CAP documents 🖊️

The specific policy and mechanisms used in a given deployment are out of scope for this document. That's a whole other lore 📜

Rate limiting is a big deal here. SIP has no rate limiting mechanisms, so every kind of emergency call, including the ones in this doc, could be abused by malicious actors or misbehaving devices to pull off a denial-of-service attack on the emergency services 😭 This mechanism doesn't introduce any new considerations, though devices that place non-interactive emergency calls without a human starting them may be more likely to cause trouble than devices that need a user to start them 💀

Implementors, listen up: automated emergency calls may be prohibited or regulated in some jurisdictions, and there may be penalties for "false positive" calls 🚫

This document describes potential retrieval of information by dereferencing URIs found in a Call Info header of a SIP MESSAGE 🔗 That can include a CAP alert as well as other additional data [RFC7852] blocks. The domain of the device sending the SIP MESSAGE, the domain of the server holding the CAP alert (if it's sent by reference), and the domain of other additional data blocks (if they're sent by reference) might all be different. No assumptions can be made that there are trust relationships between these entities 🫣 Recipients MUST take precautions in retrieving any additional data blocks passed by reference, including the CAP alert, because the URI may point to a malicious actor or to an entity that isn't expecting to be referred to for this purpose 🚨 The considerations in handling URIs in [RFC3986] apply too.

Timestamps are used to prevent replay, but that only works if everyone has accurate time 🕰️ Emergency event notification through this mechanism is relatively low frequency and generally involves human interaction. So implementations may wish to treat messages with times within a small number of seconds of each other as effectively simultaneous when detecting replay ⏱️ Implementations may also want to keep in mind that most deployed time distribution protocols likely to be used by these systems are not presently secure. Yikes 😬

Besides wanting identity-based access control, the classic communication security threats need to be considered too, including integrity protection to prevent forgery or replay of alert messages in transit 🛡️ To deal with replay of alerts, a CAP document contains the mandatory <identifier>, <sender>, and <sent> elements and an optional <expire> element. Together, these elements make the CAP document unique for a specific sender and provide time restrictions ⏳ An entity that has already received a CAP alert within the indicated timeframe can detect a replayed message. And if the content of that message is unchanged, then no additional security vulnerability is created 💅

Also, it is RECOMMENDED to make use of SIP security mechanisms, such as the SIP Identity PASSporT [RFC8225], to tie the CAP alert to the SIP message 🎀 To protect the entire SIP message exchange between neighboring SIP entities, the usage of TLS is RECOMMENDED 🔒 [RFC6443] discusses the issues of using TLS with emergency calls, and those are equally applicable to non-interactive emergency calls.

Note that none of the security mechanisms in this document protect against a compromised sensor sending crafted alerts. 🌈 Confidentiality provided for any emergency calls, including non-interactive messages, is subject to local regulations 🌍 Privacy issues are discussed in [RFC7852] and are applicable here too 🙈

10. IANA Considerations 📋

10.1. 'application/EmergencyCallData.cap+xml' Media Type

  • Type name: application
  • Subtype name: EmergencyCallData.cap+xml
  • Required parameters: N/A
  • Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8 [RFC3629].
  • Encoding considerations: 7bit, 8bit, or binary. See Section 3.2 of [RFC7303].
  • Security considerations: This content type is designed to carry payloads of the Common Alerting Protocol (CAP). RFC 8876 discusses security considerations for this.
  • Interoperability considerations: This content type provides a way to convey CAP payloads.
  • Published specification: RFC 8876
  • Applications that use this media type: Applications that convey alerts and warnings according to the CAP standard.
  • Fragment identifier considerations: N/A
  • Additional information: OASIS has published the Common Alerting Protocol at https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf
  • Person and email address to contact for further information: Hannes Tschofenig <hannes.tschofenig@gmx.net>
  • Intended usage: Limited use
  • Author/Change controller: The IESG
  • Other information: This media type is a specialization of 'application/xml' [RFC7303], and many of the considerations described there also apply to application/EmergencyCallData.cap+xml.

10.2. 'cap' Additional Data Block

IANA has registered a new block type for this document 🧾 It lives in the "Emergency Call Data Types" subregistry of the "Emergency Call Additional Data" registry defined in [RFC7852]. The token is cap, the Data About is The Call, and the reference is this document.

10.3. 425 Response Code

In the SIP "Response Codes" registry, the following has been added under Request Failure 4xx 💌

+===============+===================+===========+
| Response Code | Description       | Reference |
+===============+===================+===========+
| 425           | Bad Alert Message | RFC 8876  |
+---------------+-------------------+-----------+

    Table 1: Response Codes Registry Addition

This SIP Response code is defined in Section 5 ✨

10.4. AlertMsg-Error Header Field

The SIP AlertMsg-Error header field is created by this document, and its definition and rules are in Section 5 💖 The IANA "Session Initiation Protocol (SIP) Parameters" registry has been updated as follows:

  1. In the "Header Fields" subregistry, the following has been added:
+================+=========+===========+
| Head Name      | compact | Reference |
+================+=========+===========+
| AlertMsg-Error |         | RFC 8876  |
+----------------+---------+-----------+

Table 2: Header Fields Registry Addition
  1. In the "Header Field Parameters and Parameter Values" subregistry, the following has been added:
+================+================+============+===========+
| Header Field   | Parameter Name | Predefined | Reference |
|                |                | Values     |           |
+================+================+============+===========+
| AlertMsg-Error | code           | no         | RFC 8876  |
+----------------+----------------+------------+-----------+

   Table 3: Header Field Parameters and Parameter Values
                     Registry Addition

10.5. SIP AlertMsg-Error Codes

This document creates a new registry called "SIP AlertMsg-Error Codes" 🗂️ AlertMsg-Error codes give reasons for an error discovered by a recipient, categorized by the action the error recipient should take. The initial values for this registry are shown below. The registration procedure is Specification Required [RFC8126].

+======+=====================================+===========+
| Code | Default Reason Phrase               | Reference |
+======+=====================================+===========+
| 100  | "Cannot process the alert payload"  | RFC 8876  |
+------+-------------------------------------+-----------+
| 101  | "Alert payload was not present or   | RFC 8876  |
|      | could not be found"                 |           |
+------+-------------------------------------+-----------+
| 102  | "Not enough information to          | RFC 8876  |
|      | determine the purpose of the alert" |           |
+------+-------------------------------------+-----------+
| 103  | "Alert payload was corrupted"       | RFC 8876  |
+------+-------------------------------------+-----------+

   Table 4: SIP AlertMsg-Error Codes Registry Creation

Details of these error codes are in Section 5 🌸

11. References 📚

11.1. Normative References ✨

These are the must-reads, the foundation the whole spec stands on 📚 Every one of them is cited exactly as written:

11.2. Informative References 🌸

These ones are the helpful background reads. They're not required to build the thing, but they're super worth a look 🧚

Acknowledgments 💜

The authors want to give a huge shoutout to everyone who joined the Early Warning ad hoc meeting at IETF 69 for their feedback 🫶 They also thanked the members of the NENA Long Term Direction Working Group for their feedback, which was so iconic of them.

They also gave a big thank-you to Martin Thomson, James Winterbottom, Shida Schubert, Bernard Aboba, Marc Linsner, Christer Holmberg, and Ivo Sedlacek for their review comments. Literally the best review crew 👑

Authors' Addresses 🎀

Brian Rosen
470 Conrad Dr
Mars, PA 16046
United States of America

Email: br@brianrosen.net


Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
United States of America

Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI:   https://www.cs.columbia.edu


Hannes Tschofenig
Austria

Email: Hannes.Tschofenig@gmx.net
URI:   https://www.tschofenig.priv.at


Randall Gellens
Core Technology Consulting

Email: rg+ietf@coretechnologyconsulting.com
URI:   http://www.coretechnologyconsulting.com
📦 where this page comes from