RFC 7852
Additional Data Related to an Emergency Call
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
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>
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.
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
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
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 Example4.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
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.
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>
<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>
<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 Example4.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.
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 Example5. 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.
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
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
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.
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
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.
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.
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)
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)
