Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+SearchTech-invite World Map Symbol

in Index   Prev   Next
in Index   Prev   Next  Group: ECRIT

RFC 7852

Additional Data Related to an Emergency Call

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

Top   ToC   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   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   Page 24
   Description:  The plain language name of the manufacturer of the

   Reason for Need:  Used by PSAP management for post-mortem

   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

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

4.3.6.  Device/Service-Specific Additional Data Structure Type

   Data Element:  Type of device/service-specific additional data

   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   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:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
       <dev:UniqueDeviceID TypeOfDeviceID="IMEI">35788104

              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/

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

   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

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   Page 29
4.4.3.  EmergencyCallData.SubscriberInfo Example

   <?xml version="1.0" encoding="UTF-8"?>
       <sub:SubscriberData xmlns="urn:ietf:params:xml:ns:vcard-4.0">
                   <fn><text>Simon Perreault</text></fn>
                       <suffix>ing. jr</suffix>
                           <label><text>Simon Perreault
                               2875 boul. Laurier, suite D2-630
                               Quebec, QC, Canada
                               G1V 2M2</text></label>
Top   ToC   Page 30
                       <street>2875 boul. Laurier,
                               suite D2-630</street>
                       <code>G1V 2M2</code>
Top   ToC   Page 31

            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/

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

   How Used by Call Taker:  To interpret the data provided.
Top   ToC   Page 32
4.5.2.  EmergencyCallData.Comment Example

   <?xml version="1.0" encoding="UTF-8"?>
      <com:Comment xml:lang="en">This is an example text.</com: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   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

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


   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   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=""

   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   Page 38
   The following is a simplified example:

                    ref="" />

                    ref="" />

                    ref="" />

                    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

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   Page 39
   The following is a simplified example:



                <DataProviderString>Access Network Examples, Inc.
                <TypeOfProvider>Access Network Provider

                 <Comment xml:lang="en">This is an example text.



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

         Content-Type: application/pidf+xml
         Content-ID: <>
         Content-Disposition: by-reference;handling=optional

         ...PIDF-LO goes in here

         Content-Type: application/EmergencyCallData.ProviderInfo+xml
         Content-ID: <>
         Content-Disposition: by-reference; handling=optional

         ...Data provider information data goes in here


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