< draft-ietf-ecrit-additional-data-15.txt   draft-ietf-ecrit-additional-data-16.txt >
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar Internet-Draft NeuStar
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: May 07, 2014 Nokia Solutions and Networks Expires: July 20, 2014 Nokia Solutions and Networks
R. Marshall R. Marshall
TeleCommunication Systems, Inc. TeleCommunication Systems, Inc.
R. Gellens R. Gellens
Qualcomm Technologies, Inc. Qualcomm Technologies, Inc.
J. Winterbottom J. Winterbottom
November 03, 2013 January 16, 2014
Additional Data related to an Emergency Call Additional Data related to an Emergency Call
draft-ietf-ecrit-additional-data-15.txt draft-ietf-ecrit-additional-data-16.txt
Abstract Abstract
When an emergency call is sent to a Public Safety Answering Point When an emergency call is sent to a Public Safety Answering Point
(PSAP), the device that sends it, as well as any application service (PSAP), the device that sends it, as well as any application service
provider in the path of the call, or access network provider through provider in the path of the call, or access network provider through
which the call originated may have information about the call, the which the call originated may have information about the call, the
caller or the location which the PSAP may be able to use. This caller or the location which the PSAP may be able to use. This
document describes data structures and a mechanism to convey such document describes data structures and a mechanism to convey such
data to the PSAP. The mechanism uses a Uniform Resource Identifier data to the PSAP. The mechanism uses a Uniform Resource Identifier
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 07, 2014. This Internet-Draft will expire on July 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Data Provider Information . . . . . . . . . . . . . . . . 7 3.1. Data Provider Information . . . . . . . . . . . . . . . . 7
3.1.1. Data Provider String . . . . . . . . . . . . . . . . 7 3.1.1. Data Provider String . . . . . . . . . . . . . . . . 8
3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8 3.1.2. Data Provider ID . . . . . . . . . . . . . . . . . . 8
3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 8 3.1.3. Data Provider ID Series . . . . . . . . . . . . . . . 9
3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9 3.1.4. Type of Data Provider . . . . . . . . . . . . . . . . 9
3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10 3.1.5. Data Provider Contact URI . . . . . . . . . . . . . . 10
3.1.6. Data Provider Languages(s) Supported . . . . . . . . 11 3.1.6. Data Provider Languages(s) Supported . . . . . . . . 10
3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11 3.1.7. xCard of Data Provider . . . . . . . . . . . . . . . 11
3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12 3.1.8. Subcontractor Principal . . . . . . . . . . . . . . . 12
3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12 3.1.9. Subcontractor Priority . . . . . . . . . . . . . . . 12
3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 13 3.1.10. ProviderInfo Example . . . . . . . . . . . . . . . . 12
3.2. Service Information . . . . . . . . . . . . . . . . . . . 15 3.2. Service Information . . . . . . . . . . . . . . . . . . . 15
3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15 3.2.1. Service Environment . . . . . . . . . . . . . . . . . 15
3.2.2. Service Delivered by Provider to End User . . . . . . 15 3.2.2. Service Delivered by Provider to End User . . . . . . 15
3.2.3. Service Mobility Environment . . . . . . . . . . . . 18 3.2.3. Service Mobility Environment . . . . . . . . . . . . 17
3.2.4. emergencyCallData.SvcInfo Example . . . . . . . . . . 18 3.2.4. emergencyCallData.SvcInfo Example . . . . . . . . . . 17
3.3. Device Information . . . . . . . . . . . . . . . . . . . 19 3.3. Device Information . . . . . . . . . . . . . . . . . . . 18
3.3.1. Device Classification . . . . . . . . . . . . . . . . 19 3.3.1. Device Classification . . . . . . . . . . . . . . . . 18
3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 20 3.3.2. Device Manufacturer . . . . . . . . . . . . . . . . . 19
3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 21 3.3.3. Device Model Number . . . . . . . . . . . . . . . . . 20
3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 21 3.3.4. Unique Device Identifier . . . . . . . . . . . . . . 20
3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 21 3.3.5. Type of Device Identifier . . . . . . . . . . . . . . 20
3.3.6. Device/Service Specific Additional Data Structure . . 22 3.3.6. Device/Service Specific Additional Data Structure . . 21
3.3.7. Device/Service Specific Additional Data Structure 3.3.7. Device/Service Specific Additional Data Structure
Type . . . . . . . . . . . . . . . . . . . . . . . . 23 Type . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.8. Choosing between defining a new type of block or new 3.3.8. Issues with getting new types of data into use . . . 22
3.3.9. Choosing between defining a new type of block or new
type of device/service specific additional data . . . 23 type of device/service specific additional data . . . 23
3.3.9. emergencyCallData.DevInfo Example . . . . . . . . . . 24 3.3.10. emergencyCallData.DevInfo Example . . . . . . . . . . 24
3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24 3.4. Owner/Subscriber Information . . . . . . . . . . . . . . 24
3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 25 3.4.1. Subscriber Data Privacy Indicator . . . . . . . . . . 24
3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25 3.4.2. xCard for Subscriber's Data . . . . . . . . . . . . . 25
3.4.3. emergencyCallData.SubInfo Example . . . . . . . . . . 26 3.4.3. emergencyCallData.SubInfo Example . . . . . . . . . . 25
3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Comment . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28 3.5.1. Comment . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2. emergencyCallData.Comment Example . . . . . . . . . . 29 3.5.2. emergencyCallData.Comment Example . . . . . . . . . . 28
4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. Transmitting Blocks using the Call-Info Header . . . . . 31 4.1. Transmitting Blocks using the Call-Info Header . . . . . 30
4.2. Transmitting Blocks by Reference using the Provided-By 4.2. Transmitting Blocks by Reference using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 31 Element . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. Transmitting Blocks by Value using the Provided-By 4.3. Transmitting Blocks by Value using the Provided-By
Element . . . . . . . . . . . . . . . . . . . . . . . . . 32 Element . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4. The Content-Disposition Parameter . . . . . . . . . . . . 33 4.4. The Content-Disposition Parameter . . . . . . . . . . . . 32
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 45 6. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.1. emergencyCallData.ProviderInfo XML Schema . . . . . . . . 45 6.1. emergencyCallData.ProviderInfo XML Schema . . . . . . . . 44
6.2. emergencyCallData.SvcInfo XML Schema . . . . . . . . . . 47 6.2. emergencyCallData.SvcInfo XML Schema . . . . . . . . . . 46
6.3. emergencyCallData.DevInfo XML Schema . . . . . . . . . . 48 6.3. emergencyCallData.DevInfo XML Schema . . . . . . . . . . 47
6.4. emergencyCallData.SubInfo XML Schema . . . . . . . . . . 49 6.4. emergencyCallData.SubInfo XML Schema . . . . . . . . . . 48
6.5. emergencyCallData.Comment XML Schema . . . . . . . . . . 49 6.5. emergencyCallData.Comment XML Schema . . . . . . . . . . 49
6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 50 6.6. Provided-By XML Schema . . . . . . . . . . . . . . . . . 50
7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 54 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 53
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 56 9.1. Registry creation . . . . . . . . . . . . . . . . . . . . 55
9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 56 9.1.1. Provider ID Series Registry . . . . . . . . . . . . . 55
9.1.2. Service Environment Registry . . . . . . . . . . . . 57 9.1.2. Service Environment Registry . . . . . . . . . . . . 56
9.1.3. Service Provider Type Registry . . . . . . . . . . . 57 9.1.3. Service Provider Type Registry . . . . . . . . . . . 56
9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57 9.1.4. Service Delivered Registry . . . . . . . . . . . . . 57
9.1.5. Device Classification Registry . . . . . . . . . . . 58 9.1.5. Device Classification Registry . . . . . . . . . . . 57
9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 58 9.1.6. Device ID Type Type Registry . . . . . . . . . . . . 57
9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58 9.1.7. Device/Service Data Type Registry . . . . . . . . . . 58
9.1.8. Additional Data Blocks Registry . . . . . . . . . . . 59 9.1.8. Additional Data Blocks Registry . . . . . . . . . . . 58
9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 60 9.2. 'emergencyCallData' Purpose Parameter Value . . . . . . . 59
9.3. URN Sub-Namespace Registration for provided-by Registry 9.3. URN Sub-Namespace Registration for provided-by Registry
Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Entry . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 60 9.4. MIME Registrations . . . . . . . . . . . . . . . . . . . 59
9.4.1. MIME Content-type Registration for 9.4.1. MIME Content-type Registration for
'application/emergencyCallData.ProviderInfo+xml' . . 60 'application/emergencyCallData.ProviderInfo+xml' . . 59
9.4.2. MIME Content-type Registration for 9.4.2. MIME Content-type Registration for
'application/emergencyCallData.SvcInfo+xml' . . . . . 61 'application/emergencyCallData.SvcInfo+xml' . . . . . 60
9.4.3. MIME Content-type Registration for 9.4.3. MIME Content-type Registration for
'application/emergencyCallData.DevInfo+xml' . . . . . 62 'application/emergencyCallData.DevInfo+xml' . . . . . 61
9.4.4. MIME Content-type Registration for 9.4.4. MIME Content-type Registration for
'application/emergencyCallData.SubInfo+xml' . . . . . 63 'application/emergencyCallData.SubInfo+xml' . . . . . 62
9.4.5. MIME Content-type Registration for 9.4.5. MIME Content-type Registration for
'application/emergencyCallData.Comment+xml' . . . . . 64 'application/emergencyCallData.Comment+xml' . . . . . 63
9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 65 9.5. URN Sub-Namespace Registration . . . . . . . . . . . . . 64
9.5.1. Registration for 9.5.1. Registration for
urn:ietf:params:xml:ns:emergencycalldata . . . . . . 65 urn:ietf:params:xml:ns:emergencycalldata . . . . . . 64
9.5.2. Registration for 9.5.2. Registration for
urn:ietf:params:xml:ns:emergencycalldata:providerinfo 66 urn:ietf:params:xml:ns:emergencycalldata:providerinfo 65
9.5.3. Registration for 9.5.3. Registration for
urn:ietf:params:xml:ns:emergencycalldata:svcinfo . . 67 urn:ietf:params:xml:ns:emergencycalldata:svcinfo . . 66
9.5.4. Registration for 9.5.4. Registration for
urn:ietf:params:xml:ns:emergencycalldata:devinfo . . 67 urn:ietf:params:xml:ns:emergencycalldata:devinfo . . 67
9.5.5. Registration for 9.5.5. Registration for
urn:ietf:params:xml:ns:emergencycalldata:subinfo . . 68 urn:ietf:params:xml:ns:emergencycalldata:subinfo . . 67
9.5.6. Registration for 9.5.6. Registration for
urn:ietf:params:xml:ns:emergencycalldata:comment . . 69 urn:ietf:params:xml:ns:emergencycalldata:comment . . 68
9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 70 9.6. Schema Registrations . . . . . . . . . . . . . . . . . . 69
9.7. VCard Parameter Value Registration . . . . . . . . . . . 70 9.7. VCard Parameter Value Registration . . . . . . . . . . . 69
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.1. Normative References . . . . . . . . . . . . . . . . . . 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 70
11.2. Informational References . . . . . . . . . . . . . . . . 72 11.2. Informational References . . . . . . . . . . . . . . . . 71
Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 74 Appendix A. XML Schema for vCard/xCard . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95
1. Introduction 1. Introduction
When an IP-based emergency call is initiated a rich set of data from When an IP-based emergency call is initiated a rich set of data from
multiple data sources is conveyed to the Public Safety Answering multiple data sources is conveyed to the Public Safety Answering
Point (PSAP). This data includes information about the calling party Point (PSAP). This data includes information about the calling party
identity, the multimedia capabilities of the device, the emergency identity, the multimedia capabilities of the device, the emergency
service number, location information, and meta-data about the sources service number, location information, and meta-data about the sources
of the data. The device, the access network provider, and any of the data. The device, the access network provider, and any
service provider in the call path may have even more information service provider in the call path may have even more information
skipping to change at page 23, line 45 skipping to change at page 22, line 45
may assist in emergency response. may assist in emergency response.
How Used by Call Taker: This data element allows the end user How Used by Call Taker: This data element allows the end user
(calltaker or first responder) to know what type of additional (calltaker or first responder) to know what type of additional
data may be available to aid in providing the needed emergency data may be available to aid in providing the needed emergency
services. services.
Note: Information which is specific to a location or a caller Note: Information which is specific to a location or a caller
(person) should not be placed in this section. (person) should not be placed in this section.
3.3.8. Choosing between defining a new type of block or new type of 3.3.8. Issues with getting new types of data into use
This document describes two mechanisms which allow extension of the
kind of data provided with an emergency call: define a new block or
define a new service specific additional data URL for the DevInfo
block. While defining new data types and getting a new device or
application to send the new data may 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 may 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 may be encouraged to upgrade their systems and train their
staff to use the data. Variations, however well intentioned, are
unlikely to be supported.
Implementers should consider that data from sensor-based devices in
some cases may not be useful to call takers or PSAPs (and privacy or
other considerations may preclude the PSAP from touching the data),
but may be of use to responders. Some standards being developed by
other organizations to carry data from the PSAP to responders are
designed to carry all additional data supplied in the call that
conform to this document, even if the PSAP does not fetch or
interpret the data. This allows responders to get the data even if
the PSAP does not.
3.3.9. Choosing between defining a new type of block or new type of
device/service specific additional data device/service specific additional data
For devices that have device or service specific data, there are two 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/ choices to carry it. A new block can be defined, or the device/
service specific additional data URL the DevInfo block can be used service specific additional data URL the DevInfo block can be used
and a new type for it defined . The data passed would likely be the and a new type for it defined . The data passed would likely be the
same in both cases. Considerations for choosing which mechanism to same in both cases. Considerations for choosing which mechanism to
register under include: register under include:
Applicability: Information which will be carried by many kinds of Applicability: Information which will be carried by many kinds of
skipping to change at page 24, line 33 skipping to change at page 24, line 13
DevInfo block, rather than a new block so that implementations are DevInfo block, rather than a new block so that implementations are
not tempted to send the data by value. Conversely, data which is not tempted to send the data by value. Conversely, data which is
small may best be sent in a separate block so that it can be sent small may best be sent in a separate block so that it can be sent
by value by value
Availability of a server: Providing the data via the device block Availability of a server: Providing the data via the device block
requires a server be made available to retrieve the data. requires a server be made available to retrieve the data.
Providing the data via new block allows it to be sent by value Providing the data via new block allows it to be sent by value
(CID). (CID).
3.3.9. emergencyCallData.DevInfo Example 3.3.10. emergencyCallData.DevInfo Example
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dev:emergencyCallData.DevInfo <dev:emergencyCallData.DevInfo
xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo" xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dev:id>12345</dev:id> <dev:id>12345</dev:id>
<dev:DeviceClassification>Fixed phone</dev:DeviceClassification> <dev:DeviceClassification>Fixed phone</dev:DeviceClassification>
<dev:DeviceMfgr>Nokia</dev:DeviceMfgr> <dev:DeviceMfgr>Nokia</dev:DeviceMfgr>
<dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr> <dev:DeviceModelNr>Lumia 800</dev:DeviceModelNr>
<dev:UniqueDeviceID>35788104</dev:UniqueDeviceID> <dev:UniqueDeviceID>35788104</dev:UniqueDeviceID>
skipping to change at page 33, line 15 skipping to change at page 32, line 42
</emergencyCallDataValue> </emergencyCallDataValue>
</provided-by> </provided-by>
Example Provided-By by Value. Example Provided-By by Value.
4.4. The Content-Disposition Parameter 4.4. The Content-Disposition Parameter
RFC 5621 [RFC5621] discusses the handling of message bodies in SIP. RFC 5621 [RFC5621] discusses the handling of message bodies in SIP.
It updates and clarifies handling originally defined in RFC 3261 It updates and clarifies handling originally defined in RFC 3261
[RFC3261] based on implementation experience. While RFC 3261 did not [RFC3261] based on implementation experience. While RFC 3261 did not
mandate support for 'multipart' message bodies 'multipart/mixed' MIME mandate support for 'multipart' message bodies, 'multipart/mixed'
bodies are, however, used by many extensions (including additional MIME bodies are used by many extensions (including this document)
data) today. For example, adding a PIDF-LO, SDP, and additional data today. For example, adding a PIDF-LO, SDP, and additional data in
in body of a SIP message requires a 'multipart' message body. body of a SIP message requires a 'multipart' message body.
RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling' RFC 3204 [RFC3204] and RFC 3459 [RFC3459] define the 'handling'
parameter for the Content-Disposition header field. These RFCs parameter for the Content-Disposition header field. These RFCs
describe how a UAS reacts if it receives a message body whose content describe how a UAS reacts if it receives a message body whose content
type or disposition type it does not understand. If the 'handling' type or disposition type it does not understand. If the 'handling'
parameter has the value "optional", the UAS ignores the message body. parameter has the value "optional", the UAS ignores the message body.
If the 'handling' parameter has the value "required", the UAS returns If the 'handling' parameter has the value "required", the UAS returns
a 415 (Unsupported Media Type) response. The 'by-reference' a 415 (Unsupported Media Type) response. The 'by-reference'
disposition type allows a SIP message to contain a reference to the disposition type allows a SIP message to contain a reference to the
body part, and the SIP UA processes the body part according to the body part, and the SIP UA processes the body part according to the
skipping to change at page 34, line 4 skipping to change at page 33, line 29
--boundary1 --boundary1
Content-Type: application/pidf+xml Content-Type: application/pidf+xml
Content-ID: <target123@atlanta.example.com> Content-ID: <target123@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
...PIDF-LO goes in here ...PIDF-LO goes in here
--boundary1-- --boundary1--
Content-Type: application/emergencyCall.ProviderInfo+xml Content-Type: application/emergencyCall.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <1234567890@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference; handling=optional
...Data provider information data goes in here ...Data provider information data goes in here
--boundary1-- --boundary1--
Figure 10: Example for use of the Content-Disposition Parameter in Figure 10: Example for use of the Content-Disposition Parameter in
SIP. SIP.
5. Examples 5. Examples
This section illustrates a longer and more complex example, as shown This section illustrates a longer and more complex example, as shown
in Figure 11. In this example additional data is added by the end in Figure 11. In this example additional data is added by the end
device, included by the VoIP provider, and provided by the access device, included by the VoIP provider (via the PIDF-LO), and provided
network provider. by the access network provider.
O +----+ Emergency Call [================] (1) [================]
/|\ | UA |--+ +Device Info [ O +----+ ] Emergency Call [ ]
| +----+ | +Data Provider Info [ /|\ | UA |-------------------------------> ]
/ \ | +Location URI [ | +----+ ] +Device Info [ ]
| [ / \ ] +Data Provider Info [ ]
| (1) [ ] +Location URI [ ]
\ [ Access Network ] [ ]
\ [ Provider ] [ VoIP Provider ]
,-----------. Location [ ] [ example.org ]
,' `. +Owner/Subscriber Info [ ^ ] [ ]
/ \ +Device Info [=======.========] [============|===]
| Access | +Data Provider Info #3 . |
| Network |<..................+ . |
| Provider | . . [================] |
\ / . (4) . [ ] (2) |
`. ,' . . (3) [ <--------------+
'----------' . ....................> PSAP ] Emergency Call
| . Location [ ] +Device Info
| v +Owner/Subscriber Info [ ] +Data Provider Info #2
| +----------+ +Device Info [ ] +Location URI
(2)| | | +Data Provider Info #3 [================]
| | PSAP |
\ | |
\ +----------+
Emergency Call \ ^
+Device Info \ |
+Data Provider Info ,-------. | (3)
+Location URI ,' `. -
/ VoIP \ ----
( Provider )---
\ example.org / Emergency Call
`. ,' +Device Info
'-------' +Owner/Subscriber Info
+Data Provider Info
//////////////
+Service Info
+Location URI
+Data Provider Info #2
Legend: Legend:
--- Emergency Call Setup Procedure --- Emergency Call Setup Procedure
... Location Retrieval/Response ... Location Retrieval/Response
Figure 11: Additional Data Example Flow. Figure 11: Additional Data Example Flow
The example scenario starts with the end device itself adding device The example scenario starts with the end device itself adding device
information, owner/subscriber information, a location URI, and data information, owner/subscriber information, a location URI, and data
provider information to the outgoing emergency call setup message provider information to the outgoing emergency call setup message
(see step #1 in Figure 11). The SIP INVITE example is shown in (see step #1 in Figure 11). The SIP INVITE example is shown in
Figure 12. Figure 12.
INVITE urn:service:sos SIP/2.0 INVITE urn:service:sos SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: <urn:service:sos> To: <urn:service:sos>
From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon, Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon,
<http://www.example.com/hannes/> ;purpose=info, <http://www.example.com/hannes/> ;purpose=info,
<cid:1234567890@example.com> <cid:1234567890@atlanta.example.com>
;purpose=emergencyCallData.ProviderInfo ;purpose=emergencyCallData.ProviderInfo,
<cide:0123456789@atlanta.example.com>
;purpose=emergencyCallData.DevInfo
Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o> Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: yes Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallProviderinfo+xml application/emergencyCallProviderinfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:hannes@example.com> Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
skipping to change at page 36, line 4 skipping to change at page 35, line 16
Geolocation-Routing: yes Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallProviderinfo+xml application/emergencyCallProviderinfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:hannes@example.com> Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1-- --boundary1--
Content-Type: application/emergencyCallData.DevInfo+xml Content-Type: application/emergencyCallData.DevInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <0123456789@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dev:emergencyCallData.DevInfo <dev:emergencyCallData.DevInfo
xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo" xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dev:id>12345</svc:id> <dev:id>12345</svc:id>
<dev:DeviceClassification>SoftPhn</dev:DeviceClassification> <dev:DeviceClassification>SoftPhn</dev:DeviceClassification>
<dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID> <dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID>
<dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID> <dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID>
skipping to change at page 39, line 6 skipping to change at page 38, line 18
resulting message is shown in Figure 13. resulting message is shown in Figure 13.
INVITE sips:psap@example.org SIP/2.0 INVITE sips:psap@example.org SIP/2.0
Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9 Via: SIPS/2.0/TLS server.example.com;branch=z9hG4bK74bf9
Max-Forwards: 70 Max-Forwards: 70
To: <urn:service:sos> To: <urn:service:sos>
From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl From: Hannes Tschofenig <sips:hannes@example.com>;tag=9fxced76sl
Call-ID: 3848276298220188511@example.com Call-ID: 3848276298220188511@example.com
Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon, Call-Info: <http://wwww.example.com/hannes/photo.jpg> ;purpose=icon,
<http://www.example.com/hannes/> ;purpose=info, <http://www.example.com/hannes/> ;purpose=info,
<cid:1234567890@example.com> <cid:1234567890@atlanta.example.com>
;purpose=emergencyCallData.ProviderInfo
<cid:0123456789@atlanta.example.com>
;purpose=emergencyCallData.DevInfo
Call-Info: <cid:bloorpyhex@atlanta.example.com>
;purpose=emergencyCallData.SrvcInfo
Call-Info: <cid:aaabbb@atlanta.example.com>
;purpose=emergencyCallData.ProviderInfo ;purpose=emergencyCallData.ProviderInfo
Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o> Geolocation: <https://ls.example.net:9768/357yc6s64ceyoiuy5ax3o>
Geolocation-Routing: yes Geolocation-Routing: yes
Accept: application/sdp, application/pidf+xml, Accept: application/sdp, application/pidf+xml,
application/emergencyCallData.ProviderInfo+xml application/emergencyCallData.ProviderInfo+xml
CSeq: 31862 INVITE CSeq: 31862 INVITE
Contact: <sips:hannes@example.com> Contact: <sips:hannes@example.com>
Content-Type: multipart/mixed; boundary=boundary1 Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ... Content-Length: ...
--boundary1 --boundary1
Content-Type: application/sdp Content-Type: application/sdp
...SDP goes here ...SDP goes here
--boundary1-- --boundary1--
Content-Type: application/emergencyCallData.DevInfo+xml Content-Type: application/emergencyCallData.DevInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <0123456789@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<dev:emergencyCallData.DevInfo <dev:emergencyCallData.DevInfo
xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo" xmlns:dev="urn:ietf:params:xml:ns:emergencycalldata:devinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dev:id>12345</svc:id> <dev:id>12345</svc:id>
<dev:DeviceClassification>SoftPhn</dev:DeviceClassification> <dev:DeviceClassification>SoftPhn</dev:DeviceClassification>
<dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID> <dev:UniqueDeviceID>00-0d-4b-30-72-df</dev:UniqueDeviceID>
<dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID> <dev:TypeOfDeviceID>MAC</dev:TypeOfDeviceID>
skipping to change at page 41, line 33 skipping to change at page 41, line 4
</parameters> </parameters>
<uri>https://www.example.com/key.asc <uri>https://www.example.com/key.asc
</uri> </uri>
</key> </key>
<tz><text>Finland/Helsinki</text></tz> <tz><text>Finland/Helsinki</text></tz>
<url> <url>
<parameters><type><text>home</text></type> <parameters><type><text>home</text></type>
</parameters> </parameters>
<uri>http://example.com/hannes.tschofenig</uri> <uri>http://example.com/hannes.tschofenig</uri>
</url> </url>
</vcard> </vcard>
</xc:DataProviderContact> </xc:DataProviderContact>
</pi:emergencyCallData.ProviderInfo> </pi:emergencyCallData.ProviderInfo>
--boundary1-- --boundary1--
Content-Type: application/emergencyCall.SvcInfo+xml Content-Type: application/emergencyCall.SvcInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <bloorpyhex@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<svc:emergencyCall.SvcInfo <svc:emergencyCall.SvcInfo
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo" xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:id>abc123</svc:id> <svc:id>abc123</svc:id>
<svc:SvcEnvironment>Residence</svc:SvcEnvironment> <svc:SvcEnvironment>Residence</svc:SvcEnvironment>
<svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider> <svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider>
<svc:SvcMobility>Unknown</svc:SvcMobility> <svc:SvcMobility>Unknown</svc:SvcMobility>
</svc:emergencyCall.SvcInfo> </svc:emergencyCall.SvcInfo>
skipping to change at page 42, line 4 skipping to change at page 41, line 23
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<svc:emergencyCall.SvcInfo <svc:emergencyCall.SvcInfo
xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo" xmlns:svc="urn:ietf:params:xml:ns:emergencyCall.SvcInfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<svc:id>abc123</svc:id> <svc:id>abc123</svc:id>
<svc:SvcEnvironment>Residence</svc:SvcEnvironment> <svc:SvcEnvironment>Residence</svc:SvcEnvironment>
<svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider> <svc:SvcDelByProvider>VOIP</svc:SvcDelByProvider>
<svc:SvcMobility>Unknown</svc:SvcMobility> <svc:SvcMobility>Unknown</svc:SvcMobility>
</svc:emergencyCall.SvcInfo> </svc:emergencyCall.SvcInfo>
--boundary1-- --boundary1--
Content-Type: application/emergencyCallData.ProviderInfo+xml Content-Type: application/emergencyCallData.ProviderInfo+xml
Content-ID: <1234567890@atlanta.example.com> Content-ID: <aaabbb@atlanta.example.com>
Content-Disposition: by-reference;handling=optional Content-Disposition: by-reference;handling=optional
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<pi:emergencyCallData.ProviderInfo <pi:emergencyCallData.ProviderInfo
xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo" xmlns:pi="urn:ietf:params:xml:ns:emergencycalldata:providerinfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<pi:id>abc123</pi:id> <pi:id>abc123</pi:id>
<pi:DataProviderString>Example VoIP Provider <pi:DataProviderString>Example VoIP Provider
</pi:DataProviderString> </pi:DataProviderString>
<pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID> <pi:ProviderID>urn:nena:companyid:ID123</pi:ProviderID>
<pi:ProviderIDSeries>NENA</pi:ProviderIDSeries> <pi:ProviderIDSeries>NENA</pi:ProviderIDSeries>
 End of changes. 47 change blocks. 
121 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/