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>firstname.lastname@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
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>email@example.com</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 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.
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>firstname.lastname@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.
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>email@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>firstname.lastname@example.org </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: <email@example.com> Content-Disposition: by-reference;handling=optional ...PIDF-LO goes in here --boundary1 Content-Type: application/EmergencyCallData.ProviderInfo+xml Content-ID: <firstname.lastname@example.org> 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