Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7852

Additional Data Related to an Emergency Call

Pages: 113
Proposed Standard
Errata
Updates:  64436881
Part 2 of 5 – Pages 22 to 40
First   Prev   Next

Top   ToC   RFC7852 - Page 22   prevText

4.3. Device Information

This block provides information about the device used to place the call. It SHOULD be provided by any service provider that knows what device is being used and by the device itself. The MIME media type is 'application/EmergencyCallData.DeviceInfo+xml'.

4.3.1. Device Classification

Data Element: Device Classification Use: Optional XML Element: <DeviceClassification> Description: This data element defines the kind of device making the emergency call. If the device provides the data structure, the device information SHOULD be provided. If the service provider provides the structure and it knows what the device is, the service provider SHOULD provide the device information. Often the carrier does not know what the device is. It is possible to receive two Device Information blocks: one provided by the device and one from the service provider. This information describes the device, not how it is being used. This data element defines the kind of device making the emergency call. A registry is created in Section 11.1.6 with the initial set of values as shown in Figure 8. Reason for Need: The device classification implies the capability of the calling device and assists in identifying the meaning of the emergency call location information that is being presented. For example, does the device require human intervention to initiate a call, or is this call the result of programmed instructions? Does the calling device have the ability to update location or
Top   ToC   RFC7852 - Page 23
      condition changes?  Is this device interactive or a one-way
      reporting device?

   How Used by Call Taker:  Can provide the call taker context regarding
      the caller, the capabilities of the calling device, or the
      environment in which the device is being used and can assist in
      understanding the location information and capabilities of the
      calling device.  For example, a cordless handset might be outside
      or next door.

      +---------------+----------------------------------------+
      | Token         |  Description                           |
      +---------------+----------------------------------------+
      |cordless       | Cordless handset                       |
      |fixed          | Fixed phone                            |
      |satellite      | Satellite phone                        |
      |sensor-fixed   | Fixed (non-mobile) sensor/alarm device |
      |desktop        | Soft client on desktop PC              |
      |laptop         | Soft client on laptop-type device      |
      |tablet         | Soft client on tablet-type device      |
      |alarm-monitored| Alarm system                           |
      |sensor-mobile  | Mobile sensor device                   |
      |aircraft       | Aircraft telematics device             |
      |automobile     | Automobile/cycle/off-road telematics   |
      |truck          | Truck/construction telematics          |
      |farm           | Farm equipment telematics              |
      |marine         | Marine telematics                      |
      |personal       | Personal telematics device             |
      |feature-phone  | Cellular feature phone (not smartphone)|
      |smart-phone    | Cellular smartphone (native)           |
      |smart-phone-app| Soft client app on smartphone          |
      |unknown-device | Soft client on unknown device type     |
      |game           | Gaming console                         |
      |text-only      | Other text device                      |
      |NA             | Not Available                          |
      +---------------+----------------------------------------+

          Figure 8: Device Classification Registry Initial Values

4.3.2. Device Manufacturer

Data Element: Device Manufacturer Use: Optional XML Element: <DeviceMfgr>
Top   ToC   RFC7852 - Page 24
   Description:  The plain language name of the manufacturer of the
      device.

   Reason for Need:  Used by PSAP management for post-mortem
      investigation/resolution.

   How Used by Call Taker:  Probably not used by the call taker but by
      PSAP management.

4.3.3. Device Model Number

Data Element: Device Model Number Use: Optional XML Element: <DeviceModelNr> Description: Model number of the device. Reason for Need: Used by PSAP management for after-action investigation/resolution. How Used by Call Taker: Probably not used by the call taker but by PSAP management.

4.3.4. Unique Device Identifier

Data Element: Unique Device Identifier Use: Optional XML Element: <UniqueDeviceID> XML Attribute: <TypeOfDeviceID> Description: A string that identifies the specific device (or the device's current Subscriber Identification Module (SIM)) making the call or creating an event. Note that more than one <UniqueDeviceID> can be present to supply more than one of the identifying values. The <TypeOfDeviceID> attribute identifies the type of device identifier. A registry is created in Section 11.1.7 with an initial set of values shown in Figure 9.
Top   ToC   RFC7852 - Page 25
   Reason for Need:  Uniquely identifies the device (or, in the case of
      International Mobile Subscriber Identity (IMSI), a SIM),
      independent of any signaling identifiers present in the call
      signaling stream.

   How Used by Call Taker:  Probably not used by the call taker; might
      be used by PSAP management during an investigation.  (For example,
      if a PSAP experiences repeated false/accidental calls and there is
      no callback number or it isn't usable, the PSAP might need to try
      to track down the device using various means, e.g., contacting
      service providers in the area.)  In the case of handsets without
      current service, it might be possible to determine who last had
      service.  Another example might be a disconnected call where the
      call taker believes there is a need for assistance but was not
      able to obtain a location or other information.

   Example:  <UniqueDeviceID TypeOfDeviceID="SN">12345</UniqueDeviceID>

      +--------+------------------------------------------+
      | Token  | Description                              |
      +--------+------------------------------------------+
      | MEID   | Mobile Equipment Identifier  (CDMA)      |
      | ESN    | Electronic Serial Number (GSM)           |
      | MAC    | Media Access Control Address (IEEE)      |
      | WiMAX  | Device Certificate Unique ID             |
      | IMEI   | International Mobile Equipment ID (GSM)  |
      | IMSI   | International Mobile Subscriber ID (GSM) |
      | UDI    | Unique Device Identifier                 |
      | RFID   | Radio Frequency Identification           |
      | SN     | Manufacturer Serial Number               |
      +--------+------------------------------------------+

               Figure 9: Registry of Device Identifier Types

4.3.5. Device/Service-Specific Additional Data Structure

Data Element: Device/service-specific additional data structure Use: Optional XML Element: <DeviceSpecificData> Description: A URI representing additional data whose schema is specific to the device or service that created it. (For example, a medical device or medical device monitoring service might have a defined set of medical data.) The URI, when dereferenced, MUST yield a data structure defined by the device/service-specific
Top   ToC   RFC7852 - Page 26
      additional data type value.  Different data can be created by each
      classification, e.g., a data set created by a medical device.

   Reason for Need:  Provides device/service-specific data that can be
      used by the call taker and/or responders.

   How Used by Call Taker:  Provide information to guide call takers to
      select appropriate responders, give appropriate pre-arrival
      instructions to callers, and advise responders of what to be
      prepared for.  May be used by responders to guide assistance
      provided.

4.3.6. Device/Service-Specific Additional Data Structure Type

Data Element: Type of device/service-specific additional data structure Use: Conditional. MUST be provided when a device/service-specific additional data URI is provided. XML Element: <DeviceSpecificType> Description: A value from the registry defined in Section 11.1.8 to describe the type of data located at the device/service-specific additional data structure. The initial values shown in Figure 10 currently only include IEEE 1512, which is the United States Department of Transportation (USDoT) model for traffic incidents. Reason for Need: This data element allows identification of externally defined schemas, which might have additional data that can assist in emergency response. How Used by Call Taker: This data element allows the end user (call taker or first responder) to know what type of additional data is available to aid in providing the needed emergency services. Note: This mechanism is not appropriate for information specific to a location or a caller (person). +---------+---------------------------+--------------------------+ | Token | Description | Specification | +---------+---------------------------+--------------------------+ |IEEE1512 |Common Incident Management | IEEE 1512-2006 | | | Message Set (USDoT model | | | | for traffic incidents) | | +---------+---------------------------+--------------------------+ Figure 10: Device/Service Data Type Registry
Top   ToC   RFC7852 - Page 27
   The IEEE 1512-2006 specifications can be found at [IEEE-1512-2006].

4.3.7. EmergencyCallData.DeviceInfo Example

<?xml version="1.0" encoding="UTF-8"?> <dev:EmergencyCallData.DeviceInfo xmlns:dev="urn:ietf:params:xml:ns:EmergencyCallData:DeviceInfo"> <dev:DataProviderReference>d4b3072df.201409182208075@example.org </dev:DataProviderReference> <dev:DeviceClassification>fixed</dev:DeviceClassification> <dev:DeviceMfgr>Nokia</dev:DeviceMfgr> <dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr> <dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104 </dev:UniqueDeviceID> </dev:EmergencyCallData.DeviceInfo> Figure 11: EmergencyCallData.DeviceInfo Example

4.4. Owner/Subscriber Information

This block describes the owner of the device (if provided by the device) or the subscriber information (if provided by a service provider). The contact location is not necessarily the location of the caller or incident but is rather the nominal contact address. The MIME media type is 'application/ EmergencyCallData.SubscriberInfo+xml'. In some jurisdictions, some or all parts of the subscriber-specific information are subject to privacy constraints. These constraints vary but dictate which information can be displayed and logged. A general privacy indicator expressing a desire for privacy by the subscriber is provided. The interpretation of how this is applied is left to the receiving jurisdiction as the custodians of the local regulatory requirements. This matches an equivalent privacy flag provided in some legacy emergency call systems.

4.4.1. Subscriber Data Privacy Indicator

Attribute: 'privacyRequested', Boolean. Use: Conditional. This attribute MUST be provided if the owner/ subscriber information block is not empty. Description: The subscriber data privacy indicator specifically expresses the subscriber's desire for privacy. In some jurisdictions, subscriber services can have a specific "Type of Service" that prohibits information, such as the name of the subscriber, from being displayed. This attribute is provided to
Top   ToC   RFC7852 - Page 28
      explicitly indicate whether the subscriber service includes such
      constraints.  The interpretation of this indicator is left to each
      jurisdiction (in keeping with the semantics of the privacy
      indicator provided in some legacy emergency call systems).
      Because the interpretation of this indicator varies based on local
      regulations, this document cannot describe the exact semantics nor
      indicate which fields are affected (the application of this
      indicator might affect the display of data contained in any of the
      blocks).

   Reason for Need:  Some jurisdictions require subscriber privacy to be
      observed when processing emergency calls.

   How Used by Call Taker:  Where privacy is indicated, the call taker
      might not have access to some aspects of the subscriber
      information.

4.4.2. xCard for Subscriber's Data

Data Element: xCard for Subscriber's Data Use: Conditional. Subscriber data MUST be provided unless it is not available. Some services, such as prepaid phones, non-initialized phones, etc., do not have information about the subscriber. XML Element: <SubscriberData> Description: Information known by the service provider or device about the subscriber, e.g., Name, Address, Individual Telephone Number, Main Telephone Number, and any other data. <n>, <org> (if appropriate), <adr>, <tel>, and <email> are suggested at a minimum. If more than one <tel> property is provided, a parameter from the "vCard Property Values" registry MUST be specified on each <tel>. While some data (such as <anniversary>) might not seem obviously relevant for emergency services, any data is potentially useful in some emergency circumstances. Reason for Need: When the caller is unable to provide information, this data can be used to obtain it. How Used by Call Taker: Obtaining critical information about the caller and possibly the location when it is not able to be obtained otherwise. While the location here is not necessarily that of a caller, in some circumstances it can be helpful in locating the caller when other means have failed.
Top   ToC   RFC7852 - Page 29

4.4.3. EmergencyCallData.SubscriberInfo Example

<?xml version="1.0" encoding="UTF-8"?> <sub:EmergencyCallData.SubscriberInfo xmlns:sub= "urn:ietf:params:xml:ns:EmergencyCallData:SubscriberInfo" privacyRequested="false"> <sub:DataProviderReference>FEABFECD901@example.org </sub:DataProviderReference> <sub:SubscriberData xmlns="urn:ietf:params:xml:ns:vcard-4.0"> <vcard> <fn><text>Simon Perreault</text></fn> <n> <surname>Perreault</surname> <given>Simon</given> <additional/> <prefix/> <suffix>ing. jr</suffix> <suffix>M.Sc.</suffix> </n> <bday><date>--0203</date></bday> <anniversary> <date-time>20090808T1430-0500</date-time> </anniversary> <gender><sex>M</sex></gender> <lang> <parameters><pref><integer>1</integer></pref> </parameters> <language-tag>fr</language-tag> </lang> <lang> <parameters><pref><integer>2</integer></pref> </parameters> <language-tag>en</language-tag> </lang> <org> <parameters><type><text>work</text></type> </parameters> <text>Viagenie</text> </org> <adr> <parameters> <type><text>work</text></type> <label><text>Simon Perreault 2875 boul. Laurier, suite D2-630 Quebec, QC, Canada G1V 2M2</text></label> </parameters>
Top   ToC   RFC7852 - Page 30
                       <pobox/>
                       <ext/>
                       <street>2875 boul. Laurier,
                               suite D2-630</street>
                       <locality>Quebec</locality>
                       <region>QC</region>
                       <code>G1V 2M2</code>
                       <country>Canada</country>
                   </adr>
                   <tel>
                       <parameters>
                           <type>
                               <text>work</text>
                               <text>voice</text>
                           </type>
                       </parameters>
                       <uri>tel:+1-418-656-9254;ext=102</uri>
                   </tel>
                   <tel>
                       <parameters>
                           <type>
                               <text>work</text>
                               <text>voice</text>
                               <text>main-number</text>
                           </type>
                       </parameters>
                       <uri>tel:+1-418-555-0000</uri>
                   </tel>
                   <tel>
                       <parameters>
                           <type>
                               <text>work</text>
                               <text>text</text>
                               <text>voice</text>
                               <text>cell</text>
                               <text>video</text>
                           </type>
                       </parameters>
                       <uri>tel:+1-418-262-6501</uri>
                   </tel>
                   <email>
                       <parameters><type><text>work</text></type>
                       </parameters>
                       <text>simon.perreault@viagenie.ca</text>
                   </email>
                   <geo>
                       <parameters><type><text>work</text></type>
                       </parameters>
Top   ToC   RFC7852 - Page 31
                       <uri>geo:46.766336,-71.28955</uri>
                   </geo>
                   <key>
                       <parameters><type><text>work</text></type>
                       </parameters>
                       <uri>
                       http://www.viagenie.ca/simon.perreault/simon.asc
                       </uri>
                   </key>
                   <tz><text>America/Montreal</text></tz>
                   <url>
                       <parameters><type><text>home</text></type>
                       </parameters>
                       <uri>http://nomis80.org</uri>
                   </url>
           </vcard>
       </sub:SubscriberData>
   </sub:EmergencyCallData.SubscriberInfo>

            Figure 12: EmergencyCallData.SubscriberInfo Example

4.5. Comment

This block provides a mechanism for the data provider to supply extra, human-readable information to the PSAP. It is not intended for a general purpose extension mechanism nor does it aim to provide machine-readable content. The MIME media type is 'application/ EmergencyCallData.Comment+xml'.

4.5.1. Comment

Data Element: EmergencyCallData.Comment Use: Optional XML Element: <Comment> Description: Human-readable text providing additional information to the PSAP staff. Reason for Need: Explanatory information for values in the data structure. How Used by Call Taker: To interpret the data provided.
Top   ToC   RFC7852 - Page 32

4.5.2. EmergencyCallData.Comment Example

<?xml version="1.0" encoding="UTF-8"?> <com:EmergencyCallData.Comment xmlns:com="urn:ietf:params:xml:ns:EmergencyCallData:Comment"> <com:DataProviderReference>string0987654321@example.org </com:DataProviderReference> <com:Comment xml:lang="en">This is an example text.</com:Comment> </com:EmergencyCallData.Comment> Figure 13: EmergencyCallData.Comment Example

5. Issues with Getting New Types of Data into Use

This document describes two mechanisms that allow extension of the kind of data provided with an emergency call: define a new block or define a new device/service-specific additional data URL for the DeviceInfo block (Section 4.3.5). While defining new data types and getting a new device or application to send the new data might be easy, getting PSAPs and responders to actually retrieve the data and use it will be difficult. New mechanism providers should understand that acquiring and using new forms of data usually require software upgrades at the PSAP and/or responders, as well as training of call takers and responders in how to interpret and use the information. Legal and operational review might also be needed. Overwhelming a call taker or responder with too much information is highly discouraged. Thus, the barrier to supporting new data is quite high. The mechanisms this document describes are meant to encourage development of widely supported, common data formats for classes of devices. If all manufacturers of a class of device use the same format, and the data can be shown to improve outcomes, then PSAPs and responders can be encouraged to upgrade their systems and train their staff to use the data. Variations, however well intentioned, are unlikely to be supported. Implementors should consider that data from sensor-based devices in some cases might not be useful to call takers or PSAPs (and privacy, liability, or other considerations might preclude the PSAP from accessing or handling the data) but might be of use to responders. Each data item provided with the call in conformance with this document can be accessed by responders or other entities in the emergency services, whether or not the data is accessed by the PSAP.
Top   ToC   RFC7852 - Page 33

5.1. Choosing between Defining a New Type of Block or a New Type of Device/Service-Specific Additional Data

For devices that have device- or service-specific data, there are two choices to carry it. A new block can be defined, or the device/ service-specific additional data URL in the DeviceInfo block can be used and a new type defined for it. The data passed would likely be the same in either case. Considerations for choosing the mechanism under which to register include: Applicability: Information that will be supported by many kinds of devices or services are more appropriately defined as separate blocks. Privacy: Information sent as a device/service-specific additional data URL in the DeviceInfo block is by reference (not by value), which inherently provides some additional privacy protection (since the requester needs to supply a certificate which is verified by the supplier). Size: Information that can be very large might be better sent in the DeviceInfo block, rather than in a new block, so that implementations are unable to send the data by value. Conversely, data that is small might best be sent in a separate block so that it can be sent by value. Availability of a server: Providing the data via the DeviceInfo block requires that a server be available from which to retrieve the data. Providing the data via a new block allows it to be sent by value.

6. Data Transport Mechanisms

This section defines how to convey additional data to an emergency service provider. Two different means are specified: the first uses call signaling; the second uses the <provided-by> element of a PIDF- LO [RFC4119]. 1. First, the ability to embed a Uniform Resource Identifier (URI) in an existing SIP header field, the Call-Info header field, is defined. The URI points to the additional data structure. The Call-Info header field is specified in Section 20.9 of [RFC3261]. This document adds a new compound token starting with the value 'EmergencyCallData' for the Call-Info 'purpose' parameter. If the 'purpose' parameter is set to a value starting with 'EmergencyCallData', then the Call-Info header field contains either an HTTPS URL pointing to an external resource or a Content
Top   ToC   RFC7852 - Page 34
       Indirection (CID) URI that allows the data structure to be placed
       in the body of the SIP message.  The 'purpose' parameter also
       indicates the kind of data (by its MIME media subtype) that is
       available at the URI.

       As the data is conveyed using a URI in the SIP signaling, the
       data itself can reside on an external resource or can be
       contained within the body of the SIP message.  When the URI
       refers to data at an external resource, the data is said to be
       passed by reference.  When the URI refers to data contained
       within the body of the SIP message, the data is said to be passed
       by value.  A PSAP or emergency responder is able to examine the
       type of data provided and selectively access the data it is
       interested in, while forwarding all of it (the values or
       references) to downstream entities.

       To be conveyed in a SIP body, additional data about a call is
       defined as a series of MIME objects (also referred to as a
       "block" of data).  Each block defined in this document is an XML
       data structure identified by its MIME media type.  (Blocks
       defined by others can be encoded in XML or not, as identified by
       their MIME registration.)  As usual, whenever more than one MIME
       part is included in the body of a message, MIME multipart (i.e.,
       'multipart/mixed') encloses them all.

       This document defines a set of XML schemas and MIME media types
       used for each block defined here.  When additional data is passed
       by value in the SIP signaling, each CID URL points to one block
       in the body.  Multiple URIs are used within a Call-Info header
       field (or multiple Call-Info header fields) to point to multiple
       blocks.  When additional data is provided by reference (in SIP
       signaling or the <provided-by> element of a PIDF-LO), each HTTPS
       URL references one block; the data is retrieved with an HTTPS GET
       operation, which returns the block as an object (the blocks
       defined here are returned as XML objects).

   2.  Second, the ability to embed additional data structures in the
       <provided-by> element of a PIDF-LO [RFC4119] is defined.

       In addition to service providers in the call path, the access
       network provider generally has similar information that can be
       valuable to the PSAP.  When the access network provider and
       service provider are separate entities, the access network does
       not participate in the application-layer signaling (and hence
       cannot add a Call-Info header field to the SIP message) but can
       provide location information in a PIDF-LO.  When the access
       network provider supplies location information in the form of a
       PIDF-LO from a location server via a location configuration
Top   ToC   RFC7852 - Page 35
       protocol, it has the ability to add the data structures defined
       in this document (or references to them) within the PIDF-LO.

       The data in these data structures is not specific to the location
       itself, but rather provides descriptive information having to do
       with the immediate circumstances about the provider's provision
       of the location (e.g., the identity of the access network
       provider, how to contact that entity, what kind of service the
       access network provides, subscriber information, etc.).  This
       data is similar in nearly every respect to the data known by
       service providers in the path of the call.  The <provided-by>
       element of the PIDF-LO is a mechanism for the access network
       provider to supply the information.  This document describes a
       namespace per [RFC4119] for inclusion in the <provided-by>
       element of a PIDF-LO for adding information known to the access
       network provider.  The access network provider SHOULD provide
       additional data within a <provided-by> element of a PIDF-LO it
       returns for emergency use (e.g., if requested with an HTTP-
       Enabled Location Delivery (HELD) 'responseTime' attribute of
       'emergencyRouting' or 'emergencyDispatch' [RFC5985]).

   One or more blocks of data registered in the "Emergency Call
   Additional Data" registry, as defined in Section 11.1.9, can be
   included or referenced in the SIP signaling (using the Call-Info
   header field) or in the <provided-by> element of a PIDF-LO.  For
   interoperability, only blocks in the registry are permitted to be
   sent using the mechanisms specified in this document.  Since multiple
   entities are expected to provide sets of data, the data itself needs
   information describing the source.  Consequently, each entity adding
   additional data MUST supply a 'Data Provider' block.  All other
   blocks are optional, but each entity SHOULD supply all blocks where
   it has at least some of the information in the block.

   Note that, as with any mechanism, failures are possible.  For
   example, a block (provided by value or by reference) might not be the
   type indicated by the 'purpose' parameter, or might be badly formed,
   etc.  The general principle that applies to emergency calls is that
   it is more important for the call to go through than for everything
   to be correct.  Thus, most PSAPs will process a call if at all
   possible, even if data is missing or other failures occur.
Top   ToC   RFC7852 - Page 36

6.1. Transmitting Blocks Using Call-Info

A URI to a block MAY be inserted in any SIP request or response method (most often INVITE or MESSAGE), using a Call-Info header field containing a 'purpose' value starting with 'EmergencyCallData', a dot ('.'), and the type of data available at the URI. The type of data is denoted by including the root of the MIME media subtype (the 'EmergencyCallData' prefix is not repeated), omitting any suffix such as '+xml'. For example, when referencing a block with MIME media type 'application/EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set to 'EmergencyCallData.ProviderInfo'. An example Call-Info header field for this would be: Call-Info: https://www.example.com/23sedde3; purpose="EmergencyCallData.ProviderInfo" A Call-Info header field with a 'purpose' value starting with 'EmergencyCallData' only has meaning in the context of an emergency call (as ascertained by the presence of an emergency service URN in a Request-URI header field of a SIP message), test emergency calls (using an appropriate service URN), and some private-use calls where the endpoints have a preexisting relationship and privacy concerns do not apply because of the relationship; use in other contexts is undefined and is likely to unnecessarily expose confidential data. If the data is provided by reference, an HTTPS URI MUST be included, and consequently, Transport Layer Security (TLS) protection is used during the retrieval of the information. The data can also be supplied by value in any SIP request or response method that is permitted to contain a body (i.e., not a BYE request) [RFC3261]. In this case, CID [RFC2392] is used, with the CID URL referencing the MIME body part containing the data. Note that [RFC3261] forbids proxies from altering message bodies, so entities in the call path that add blocks by value need to do so using an appropriate SIP entity (e.g., a back-to-back user agent). Transmitting data by value is especially useful in certain cases, such as when the data exists in or is generated by the originating device but is not intended for very large data blocks. Additional security and privacy considerations apply to data transmitted by value, as discussed in Sections 9 and 10, respectively. More than one Call-Info header field with a 'purpose' value starting with 'EmergencyCallData' can be expected, but at least one MUST be provided. The device MUST provide one unless it knows that a service provider is in the path of the call. The device MAY insert one if it uses a service provider. Each service provider in the path of an
Top   ToC   RFC7852 - Page 37
   emergency call MUST insert its own.  For example, a device, a
   telematics service provider in the call path, as well as the mobile
   carrier handling the call will each provide one.  There might be
   circumstances where there is a service provider who is unaware that
   the call is an emergency call and cannot reasonably be expected to
   determine that it is an emergency call.  In that case, that service
   provider is not expected to provide EmergencyCallData.

   When blocks are transmitted by value, the 'purpose' parameter in a
   Call-Info header field identifies the data, and the CID URL points to
   the data block in the body (which has a matching Content-ID body part
   header field).  When a data block is carried in a signed or encrypted
   body part, the enclosing multipart (e.g., 'multipart/signed' or
   'multipart/encrypted') has the same Content-ID as the data part.
   This allows an entity to identify and access the data blocks it is
   interested in without having to dive deeply into the message
   structure or decrypt parts it is not interested in.

6.2. Transmitting Blocks by Reference Using the <provided-by> Element

The <EmergencyCallDataReference> element is used to transmit an additional data block by reference within a <provided-by> element of a PIDF-LO. The <EmergencyCallDataReference> element has two attributes: 'ref' to specify the URL and 'purpose' to indicate the type of data block referenced. The value of 'ref' is an HTTPS URL that resolves to a data structure with information about the call. The value of 'purpose' is the same as used in a Call-Info header field (as specified in Section 6.1). For example, to reference a block with MIME media type 'application/ EmergencyCallData.ProviderInfo+xml', the 'purpose' parameter is set to 'EmergencyCallData.ProviderInfo'. An example <EmergencyCallDataReference> element for this would be: <EmergencyCallDataReference ref="https://www.example.com/23sedde3" purpose="EmergencyCallData.ProviderInfo"/> The <EmergencyCallDataReference> element transmits one data block; multiple data blocks are transmitted by using multiple <EmergencyCallDataReference> elements. Multiple <EmergencyCallDataReference> elements MAY be included as child elements inside the <provided-by> element.
Top   ToC   RFC7852 - Page 38
   The following is a simplified example:

   <provided-by>
           <EmergencyCallDataReference
                    purpose="EmergencyCallData.ServiceInfo"
                    ref="https://example.com/ref2" />

           <EmergencyCallDataReference
                    purpose="EmergencyCallData.ProviderInfo"
                    ref="https://example.com/ref3" />

           <EmergencyCallDataReference
                    purpose="EmergencyCallData.Comment"
                    ref="https://example.com/ref4" />
   </provided-by>

                    Example <provided-by> by Reference

   For an example in context, Figure 18 shows a PIDF-LO example with an
   <EmergencyCallDataReference> element pointing to an
   EmergencyCallData.ServiceInfo data block with the URL in the 'ref'
   attribute and the 'purpose' attribute set to
   'EmergencyCallData.ServiceInfo'.

6.3. Transmitting Blocks by Value Using the <provided-by> Element

It is RECOMMENDED that access networks supply the data specified in this document by reference, because PIDF-LOs can be fetched by a client or other entity and stored locally, so providing the data by value risks exposing private information to a larger audience. The <EmergencyCallDataValue> element is used to transmit one or more additional data blocks by value within a <provided-by> element of a PIDF-LO. Each block being transmitted is placed (as a child element) inside the <EmergencyCallDataValue> element. (The same XML structure as would be contained in the corresponding MIME media type body part is placed inside the <EmergencyCallDataValue> element.) Multiple <EmergencyCallDataValue> elements MAY be included as child elements in the <provided-by> element.
Top   ToC   RFC7852 - Page 39
   The following is a simplified example:

   <provided-by>

           <EmergencyCallDataValue>

             <EmergencyCallData.ProviderInfo
                xmlns=
                "urn:ietf:params:xml:ns:EmergencyCallData:ProviderInfo">
                <DataProviderReference>flurbit735@es.example.com
                  </DataProviderReference>
                <DataProviderString>Access Network Examples, Inc.
                  </DataProviderString>
                <ProviderID>urn:nena:companyid:Test</ProviderID>
                <ProviderIDSeries>NENA</ProviderIDSeries>
                <TypeOfProvider>Access Network Provider
                  </TypeOfProvider>
                <ContactURI>tel:+1-555-555-0897</ContactURI>
                <Language>en</Language>
              </EmergencyCallData.ProviderInfo>

              <EmergencyCallData.Comment
                 xmlns=
                 "urn:ietf:params:xml:ns:EmergencyCallData:Comment">
                 <DataProviderReference>flurbit735@es.example.com
                   </DataProviderReference>
                 <Comment xml:lang="en">This is an example text.
                   </Comment>
              </EmergencyCallData.Comment>

           </EmergencyCallDataValue>

   </provided-by>

                      Example <provided-by> by Value

   For an example in context, Figure 18 shows a PIDF-LO example that
   contains a <provided-by> element with the
   <EmergencyCallData.ProviderInfo> and the <EmergencyCallData.Comment>
   elements as child elements of an <EmergencyCallDataValue> element.

6.4. The Content-Disposition Parameter

RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. It updates and clarifies handling originally defined in RFC 3261 [RFC3261] based on implementation experience. While RFC 3261 did not mandate support for 'multipart' message bodies, 'multipart/mixed' MIME bodies are used by many extensions (including this document)
Top   ToC   RFC7852 - Page 40
   today.  For example, adding a PIDF-LO, a Session Description Protocol
   (SDP), and additional data in the body of a SIP message requires a
   'multipart' message body.

   RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling'
   parameter for the Content-Disposition header field.  These RFCs
   describe how a User Agent Server (UAS) reacts if it receives a
   message body whose content type or disposition type it does not
   understand.  If the 'handling' parameter has the value 'optional',
   the UAS ignores the message body.  If the 'handling' parameter has
   the value 'required', the UAS returns a 415 (Unsupported Media Type)
   response.  The 'by-reference' disposition type of RFC 5621 [RFC5621]
   allows a SIP message to contain a reference to the body part, and the
   SIP User Agent (UA) processes the body part according to the
   reference.  This is the case for a Call-Info header field containing
   a CID URL.

   As an example, a SIP message indicates the 'Content-Disposition'
   parameter in the body of the SIP message as shown in Figure 14.

         Content-Type: application/sdp
         ...Omit Content-Disposition here; defaults are ok

         ...SDP goes in here

         --boundary1
         Content-Type: application/pidf+xml
         Content-ID: <target123@atlanta.example.com>
         Content-Disposition: by-reference;handling=optional

         ...PIDF-LO goes in here

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

         ...Data provider information data goes in here

         --boundary1--

      Figure 14: Example for Use of the Content-Disposition Parameter
                                  in SIP


(next page on part 3)

Next Section