draft-ietf-ecrit-data-only-ea-15.txt   draft-ietf-ecrit-data-only-ea-16.txt 
ECRIT B. Rosen ECRIT B. Rosen
Internet-Draft NeuStar, Inc. Internet-Draft
Intended status: Standards Track H. Schulzrinne Intended status: Standards Track H. Schulzrinne
Expires: October 25, 2018 Columbia U. Expires: April 26, 2019 Columbia U.
H. Tschofenig H. Tschofenig
ARM Limited ARM Limited
R. Gellens R. Gellens
Core Technology Consulting Core Technology Consulting
April 23, 2018 October 23, 2018
Data-Only Emergency Calls Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-15 draft-ietf-ecrit-data-only-ea-16
Abstract Abstract
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
describes how devices use the Internet to place emergency calls and describes how devices use the Internet to place emergency calls and
how Public Safety Answering Points (PSAPs) handle Internet multimedia how Public Safety Answering Points (PSAPs) handle Internet multimedia
emergency calls natively. The exchange of multimedia traffic for emergency calls natively. The exchange of multimedia traffic for
emergency services involves a Session Initiation Protocol (SIP) emergency services involves a Session Initiation Protocol (SIP)
session establishment starting with a SIP INVITE that negotiates session establishment starting with a SIP INVITE that negotiates
various parameters for that session. various parameters for that session.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
transaction. transaction.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 October 25, 2018. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 7 skipping to change at page 3, line 7
10.4. IANA Registration of New AlertMsg-Error Header Field . . 19 10.4. IANA Registration of New AlertMsg-Error Header Field . . 19
10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19 10.5. IANA Registration for the SIP AlertMsg-Error Codes . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
RFC 6443 [RFC6443] describes how devices use the Internet to place [RFC6443] describes how devices use the Internet to place emergency
emergency calls and how Public Safety Answering Points (PSAPs) handle calls and how Public Safety Answering Points (PSAPs) handle Internet
Internet multimedia emergency calls natively. The exchange of multimedia emergency calls natively. The exchange of multimedia
multimedia traffic for emergency services involves a SIP session traffic for emergency services involves a SIP session establishment
establishment starting with a SIP INVITE that negotiates various starting with a SIP INVITE that negotiates various parameters for
parameters for that session. that session.
In some cases, however, there is only application data to be conveyed In some cases, however, there is only application data to be conveyed
from the end devices to a PSAP or an intermediary. Examples of such from the end devices to a PSAP or an intermediary. Examples of such
environments includes sensors issuing alerts, or certain types of environments includes sensors issuing alerts, or certain types of
medical monitors. These messages may be one-shot alerts to emergency medical monitors. These messages may be one-shot alerts to emergency
authorities and do not require establishment of a session. These authorities and do not require establishment of a session. These
type of interactions are called 'data-only emergency calls'. In this type of interactions are called 'data-only emergency calls'. In this
document, we use the term "call" so that similarities between data- document, we use the term "call" so that similarities between data-
only (non-interactive) alerts and sessions with interactive media are only (non-interactive) alerts and sessions with interactive media are
more obvious. more obvious.
skipping to change at page 3, line 52 skipping to change at page 3, line 52
(a URI is included in the message, which when dereferenced returns (a URI is included in the message, which when dereferenced returns
the CAP message). The additional data mechanism is also used to send the CAP message). The additional data mechanism is also used to send
alert specific data beyond that available in the CAP message. This alert specific data beyond that available in the CAP message. This
document also describes how a SIP MESSAGE [RFC3428] transaction can document also describes how a SIP MESSAGE [RFC3428] transaction can
be used to send a data-only call. be used to send a data-only call.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Architectural Overview 3. Architectural Overview
This section illustrates two envisioned usage modes: targeted and This section illustrates two envisioned usage modes: targeted and
location-based emergency alert routing. location-based emergency alert routing.
1. Emergency alerts containing only data are targeted to an 1. Emergency alerts containing only data are targeted to an
intermediary recipient responsible for evaluating the next steps. intermediary recipient responsible for evaluating the next steps.
These steps could include: These steps could include:
skipping to change at page 7, line 17 skipping to change at page 7, line 17
with a Call-Info header field with a purpose of with a Call-Info header field with a purpose of
"EmergencyCallData.cap". The header field may contain a URI that is "EmergencyCallData.cap". The header field may contain a URI that is
used by the recipient (or in some cases, an intermediary) to obtain used by the recipient (or in some cases, an intermediary) to obtain
the CAP message. Alternative, the Call-Info header field may contain the CAP message. Alternative, the Call-Info header field may contain
a Content Indirect url [RFC2392] and the CAP message included in the a Content Indirect url [RFC2392] and the CAP message included in the
body of the message. In the latter case, the CAP message is located body of the message. In the latter case, the CAP message is located
in a MIME block of the type 'application/emergencyCallData.cap+xml'. in a MIME block of the type 'application/emergencyCallData.cap+xml'.
If the SIP server does not support the functionality required to If the SIP server does not support the functionality required to
fulfill the request then a 501 Not Implemented MUST be returned as fulfill the request then a 501 Not Implemented MUST be returned as
specified in RFC 3261 [RFC3261]. This is the appropriate response specified in [RFC3261]. This is the appropriate response when a User
when a User Agent Server (UAS) does not recognize the request method Agent Server (UAS) does not recognize the request method and is not
and is not capable of supporting it for any user. capable of supporting it for any user.
The 415 Unsupported Media Type error MUST be returned as specified in The 415 Unsupported Media Type error MUST be returned as specified in
RFC 3261 [RFC3261] if the SIP server is refusing to service the [RFC3261] if the SIP server is refusing to service the request
request because the message body of the request is in a format not because the message body of the request is in a format not supported
supported by the server for the requested method. The server MUST by the server for the requested method. The server MUST return a
return a list of acceptable formats using the Accept, Accept- list of acceptable formats using the Accept, Accept-Encoding, or
Encoding, or Accept-Language header fields, depending on the specific Accept-Language header fields, depending on the specific problem with
problem with the content. the content.
4.2. Profiling of the CAP Document Content 4.2. Profiling of the CAP Document Content
The usage of CAP MUST conform to the specification provided with The usage of CAP MUST conform to the specification provided with
[cap]. For usage with SIP the following additional requirements are [cap]. For usage with SIP the following additional requirements are
imposed: imposed:
sender: The following restrictions and conditions apply to setting sender: The following restrictions and conditions apply to setting
the value of the <sender> element: the value of the <sender> element:
skipping to change at page 10, line 5 skipping to change at page 10, line 5
; (message-header from 3261) ; (message-header from 3261)
AlertMsg-Error = "AlertMsg-Error" HCOLON AlertMsg-Error = "AlertMsg-Error" HCOLON
ErrorValue ErrorValue
ErrorValue = error-code ErrorValue = error-code
*(SEMI error-params) *(SEMI error-params)
error-code = 1*3DIGIT error-code = 1*3DIGIT
error-params = error-code-text error-params = error-code-text
/ generic-param ; from RFC3261 / generic-param ; from RFC3261
error-code-text = "code" EQUAL quoted-string ; from RFC3261 error-code-text = "code" EQUAL quoted-string ; from RFC3261
HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is HCOLON, SEMI, and EQUAL are defined in [RFC3261]. DIGIT is defined
defined in RFC5234 [RFC5234]. in [RFC5234].
The AlertMsg-Error header field MUST contain only one ErrorValue to The AlertMsg-Error header field MUST contain only one ErrorValue to
indicate what was wrong with the alert payload the recipient indicate what was wrong with the alert payload the recipient
determined was bad. determined was bad.
The ErrorValue contains a 3-digit error code indicating what was The ErrorValue contains a 3-digit error code indicating what was
wrong with the alert in the request. This error code has a wrong with the alert in the request. This error code has a
corresponding quoted error text string that is human understandable. corresponding quoted error text string that is human understandable.
The text string is OPTIONAL, but RECOMMENDED for human readability, The text string is OPTIONAL, but RECOMMENDED for human readability,
similar to the string phrase used for SIP response codes. That said, similar to the string phrase used for SIP response codes. That said,
skipping to change at page 16, line 18 skipping to change at page 16, line 18
an important role in deciding whether to accept or ignore an incoming an important role in deciding whether to accept or ignore an incoming
alert message. With the scenario shown in Figure 1 it is very likely alert message. With the scenario shown in Figure 1 it is very likely
that only authorized sensor input will be processed. For this that only authorized sensor input will be processed. For this
reason, it needs to be possible to refuse to accept alert messages reason, it needs to be possible to refuse to accept alert messages
from an unknown origin. Two types of information elements can be from an unknown origin. Two types of information elements can be
used for this purpose: used for this purpose:
1. SIP itself provides security mechanisms that allow the 1. SIP itself provides security mechanisms that allow the
verification of the originator's identity. These mechanisms can verification of the originator's identity. These mechanisms can
be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity
[RFC4474]. The latter provides a cryptographic assurance while [RFC8224]. The latter provides a cryptographic assurance while
the former relies on a chain of trust model. the former relies on a chain of trust model.
2. CAP provides additional security mechanisms and the ability to 2. CAP provides additional security mechanisms and the ability to
carry further information about the sender's identity. carry further information about the sender's identity.
Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP
documents. documents.
In addition to the desire to perform identity-based access control, In addition to the desire to perform identity-based access control,
the classic communication security threats need to be considered, the classic communication security threats need to be considered,
including integrity protection to prevent forgery or replay of alert including integrity protection to prevent forgery or replay of alert
messages in transit. To deal with replay of alerts, a CAP document messages in transit. To deal with replay of alerts, a CAP document
contains the mandatory <identifier>, <sender>, <sent> elements and an contains the mandatory <identifier>, <sender>, <sent> elements and an
optional <expire> element. Together, these elements make the CAP optional <expire> element. Together, these elements make the CAP
document unique for a specific sender and provide time restrictions. document unique for a specific sender and provide time restrictions.
An entity that has already received a CAP message within the An entity that has already received a CAP message within the
indicated timeframe is able to detect a replayed message and, if the indicated timeframe is able to detect a replayed message and, if the
content of that message is unchanged, then no additional security content of that message is unchanged, then no additional security
vulnerability is created. Additionally, it is RECOMMENDED to make vulnerability is created. Additionally, it is RECOMMENDED to make
use of SIP security mechanisms, such as SIP Identity [RFC4474], to use of SIP security mechanisms, such as SIP Identity [RFC8224], to
tie the CAP message to the SIP message. To provide protection of the tie the CAP message to the SIP message. To provide protection of the
entire SIP message exchange between neighboring SIP entities, the entire SIP message exchange between neighboring SIP entities, the
usage of TLS is REQUIRED. usage of TLS is REQUIRED.
Note that none of the security mechanism in this document protect Note that none of the security mechanism in this document protect
against a compromised sensor sending crafted alerts. Privacy against a compromised sensor sending crafted alerts. Privacy
provided for any emergency calls, including data-only messages, is provided for any emergency calls, including data-only messages, is
subject to local regulations. subject to local regulations.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 17, line 22 skipping to change at page 17, line 22
MIME media type name: application MIME media type name: application
MIME subtype name: cap+xml MIME subtype name: cap+xml
Required parameters: (none) Required parameters: (none)
Optional parameters: charset; Indicates the character encoding of Optional parameters: charset; Indicates the character encoding of
enclosed XML. Default is UTF-8 [RFC3629]. enclosed XML. Default is UTF-8 [RFC3629].
Encoding considerations: Uses XML, which can employ 8-bit Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC characters, depending on the character encoding used. See
3023 [RFC3023], Section 3.2. [RFC3023], Section 3.2.
Security considerations: This content type is designed to carry Security considerations: This content type is designed to carry
payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace payloads of the Common Alerting Protocol (CAP). RFC XXX [Replace
by the RFC number of this specification] discusses security by the RFC number of this specification] discusses security
considerations for this. considerations for this.
Interoperability considerations: This content type provides a way to Interoperability considerations: This content type provides a way to
convey CAP payloads. convey CAP payloads.
Published specification: RFC XXX [Replace by the RFC number of this Published specification: RFC XXX [Replace by the RFC number of this
skipping to change at page 18, line 17 skipping to change at page 18, line 17
documents.php&wg_abbrev=emergency documents.php&wg_abbrev=emergency
Person and email address to contact for further information: Hannes Person and email address to contact for further information: Hannes
Tschofenig, hannes.tschofenig@gmx.net Tschofenig, hannes.tschofenig@gmx.net
Intended usage: Limited use Intended usage: Limited use
Author/Change controller: IETF ECRIT working group Author/Change controller: IETF ECRIT working group
Other information: This media type is a specialization of Other information: This media type is a specialization of
application/xml RFC 3023 [RFC3023], and many of the considerations application/xml [RFC3023], and many of the considerations
described there also apply to application/cap+xml. described there also apply to application/cap+xml.
10.2. IANA Registration of 'cap' Additional Data Block 10.2. IANA Registration of 'cap' Additional Data Block
This document registers a new block type in the sub-registry called This document registers a new block type in the sub-registry called
'Emergency Call Data Types' of the Emergency Call Additional Data 'Emergency Call Data Types' of the Emergency Call Additional Data
Registry defined in [RFC7852]. The token is "cap", the Data About is Registry defined in [RFC7852]. The token is "cap", the Data About is
"The Call" and the reference is this document. "The Call" and the reference is this document.
10.3. IANA Registration for 425 Response Code 10.3. IANA Registration for 425 Response Code
skipping to change at page 20, line 45 skipping to change at page 20, line 45
[cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v.
1.1", October 2005. 1.1", October 2005.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002,
editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., [RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
Huitema, C., and D. Gurle, "Session Initiation Protocol Huitema, C., and D. Gurle, "Session Initiation Protocol
(SIP) Extension for Instant Messaging", RFC 3428, (SIP) Extension for Instant Messaging", RFC 3428,
DOI 10.17487/RFC3428, December 2002, <https://www.rfc- DOI 10.17487/RFC3428, December 2002,
editor.org/info/rfc3428>. <https://www.rfc-editor.org/info/rfc3428>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008,
editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, DOI 10.17487/RFC3023, January 2001, Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
<https://www.rfc-editor.org/info/rfc3023>. <https://www.rfc-editor.org/info/rfc3023>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol", RFC 6442, for the Session Initiation Protocol", RFC 6442,
DOI 10.17487/RFC6442, December 2011, <https://www.rfc- DOI 10.17487/RFC6442, December 2011,
editor.org/info/rfc6442>. <https://www.rfc-editor.org/info/rfc6442>.
[RFC6881] Rosen, B. and J. Polk, "Best Current Practice for [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in Support of Emergency Calling", Communications Services in Support of Emergency Calling",
BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
<https://www.rfc-editor.org/info/rfc6881>. <https://www.rfc-editor.org/info/rfc6881>.
[RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and [RFC7852] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
J. Winterbottom, "Additional Data Related to an Emergency J. Winterbottom, "Additional Data Related to an Emergency
Call", RFC 7852, DOI 10.17487/RFC7852, July 2016, Call", RFC 7852, DOI 10.17487/RFC7852, July 2016,
<https://www.rfc-editor.org/info/rfc7852>. <https://www.rfc-editor.org/info/rfc7852>.
12.2. Informative References 12.2. Informative References
[RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
"Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
December 2014, <https://www.rfc-editor.org/info/rfc7378>. December 2014, <https://www.rfc-editor.org/info/rfc7378>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC4474, August 2006, <https://www.rfc- DOI 10.17487/RFC8224, February 2018,
editor.org/info/rfc4474>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002, <https://www.rfc- DOI 10.17487/RFC3325, November 2002,
editor.org/info/rfc3325>. <https://www.rfc-editor.org/info/rfc3325>.
[RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
"Framework for Emergency Calling Using Internet "Framework for Emergency Calling Using Internet
Multimedia", RFC 6443, DOI 10.17487/RFC6443, December Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
2011, <https://www.rfc-editor.org/info/rfc6443>. 2011, <https://www.rfc-editor.org/info/rfc6443>.
Authors' Addresses Authors' Addresses
Brian Rosen Brian Rosen
NeuStar, Inc.
470 Conrad Dr 470 Conrad Dr
Mars, PA 16046 Mars, PA 16046
US US
Email: br@brianrosen.net Email: br@brianrosen.net
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
 End of changes. 23 change blocks. 
46 lines changed or deleted 45 lines changed or added

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