draft-ietf-sipping-sos-00.txt   draft-ietf-sipping-sos-01.txt 
Network Working Group H. Schulzrinne Network Working Group H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: August 8, 2004 February 8, 2004 Expires: April 26, 2006 October 23, 2005
Emergency Services URI for the Session Initiation Protocol Emergency Services URI for the Session Initiation Protocol
draft-ietf-sipping-sos-00 draft-ietf-sipping-sos-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2004. This Internet-Draft will expire on April 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
As part of an overall architecture for supporting emergency calling As part of an overall architecture for supporting emergency calling
for the Session Initiation Protocol (SIP), this document defines for the Session Initiation Protocol (SIP), this document defines
universal emergency SIP URIs, sip:sos@domain and sips:sos@domain, universal emergency SIP URIs, sip:sos@domain and sips:sos@domain,
that allows SIP user agents to contact the local emergency call that allows SIP user agents to contact the local emergency call
center. It also defines conventions that increase the high center. It also defines conventions that increase the high
probability of reaching the appropriate emergency call center. The probability of reaching the appropriate emergency call center. The
document does not define any SIP protocol extensions. document does not define any SIP protocol extensions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Emergency URIs . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Emergency URIs . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 SIP URIs for Emergency Calls . . . . . . . . . . . . . . . . . 6 5. Identifying the Local Emergency Numbers . . . . . . . . . . 5
4.2 Tel URIs for Emergency Calls . . . . . . . . . . . . . . . . . 7 6. Request Handling . . . . . . . . . . . . . . . . . . . . . . 6
5. Request Handling . . . . . . . . . . . . . . . . . . . . . . . 8 7. Alternative Approaches Considered . . . . . . . . . . . . . 6
6. Identifying the Local Emergency Numbers . . . . . . . . . . . 9 8. Media Feature Tag Registration: Service . . . . . . . . . . 7
7. Alternative Identifiers Considered . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Normative References . . . . . . . . . . . . . . . . . . . . . 14 12.1 Normative References . . . . . . . . . . . . . . . . . . 9
Informative References . . . . . . . . . . . . . . . . . . . . 15 12.2 Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . 11
1. Introduction 1. Introduction
Using the public switched telephone network (PSTN), emergency help Using the public switched telephone network (PSTN), emergency help
can often be summoned at a designated, widely known number, can often be summoned at a designated, widely known number,
regardless of where the telephone was purchased. However, this regardless of where the telephone was purchased. However, this
number differs between localities, even though it is often the same number differs between localities, even though it is often the same
for a country or continent-size region (such as many countries in the for a country or continent-size region (such as many countries in the
European Union or North America). For end systems based on the European Union or North America). For end systems based on the
Session Initiation Protocol (SIP) [RFC3261], it is desirable to have Session Initiation Protocol (SIP) [RFC3261], it is desirable to have
a universal identifier, independent of location, to simplify the user a universal identifier, independent of location, to simplify the user
experience and to allow the device to perform appropriate processing. experience and to allow the device to perform appropriate processing.
Here, we define a common user identifier, "sos", as the contact Here, we define a common user identifier, "sos", as the contact
mechanism for emergency assistance. This identifier is meant to be mechanism for emergency assistance. This identifier is meant to be
used in addition to any local emergency numbers. used in addition to any local emergency numbers.
This document specifies only a small part of a comprehensive set of This document specifies only a small part of a comprehensive set of
recommendations for operating emergency services. The overall recommendations for operating emergency services. The overall
architecture is described in [schulzrinne-sipping-emergency-arch]. architecture is described in [I-D.schulzrinne-sipping-emergency-
That document describes, for example, how a device that identifies a arch]. That document describes, for example, how a device that
call as an emergency call can route it to the appropriate emergency identifies a call as an emergency call can route it to the
call center (ECC). appropriate emergency call center (ECC).
This document does not introduce any new SIP header fields, request This document does not introduce any new SIP header fields, request
methods, status codes, message bodies, or events. User agents methods, status codes, message bodies, or events. User agents
unaware of the recommendations in this draft can place emergency unaware of the recommendations in this draft can place emergency
calls, but may not be able to provide the same user interface calls, but may not be able to provide the same user interface
functionality. The document suggests behavior for proxy servers, in functionality. The document suggests behavior for proxy servers, in
particular outbound proxy servers. particular outbound proxy servers.
The solution described here is not as general as the alternative
approach, service URNs [I-D.schulzrinne-sipping-service], but
requires no changes to end systems or proxies.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUSTNOT", "REQUIRED", In this document, the key words "MUST", "MUSTNOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
3. Requirements 3. Requirements
o It should be possible for devices to provide user interfaces that o It should be possible for devices to provide user interfaces that
can directly cause an emergency call, without the user having to can directly cause an emergency call, without the user having to
"dial" or type a specific address. "dial" or type a specific address.
o Even as each country is likely to operate their emergency calling o Even as each country is likely to operate their emergency calling
infrastructure differently, SIP devices should be able to reach infrastructure differently, SIP devices should be able to reach
emergency help and, if possible, be located in any country. emergency help and, if possible, be located in any country.
o While traveling, users should be able to use their familiar "home"
o While traveling, users must be able to use their familiar "home" emergency number. Users must also be able to dial the local
emergency identifier. Users should also be able to dial the local
emergency number in the country they are visiting. emergency number in the country they are visiting.
o Any mechanism must be deployable incrementally and work even if o Any mechanism must be deployable incrementally and work even if
not all SIP entities support emergency calling. User agents not all SIP entities support emergency calling. User agents
conforming to the SIP specification [RFC3261], but unaware of this conforming to the SIP specification [RFC3261], but unaware of this
document, must be able to place emergency calls, possibly with document, must be able to place emergency calls, possibly with
restricted functionality. restricted functionality.
o Given incremental deployment, emergency call functionality should o Given incremental deployment, emergency call functionality should
be testable by the user without causing an emergency response. be testable by the user without causing an emergency response.
o Emergency calling mechanisms must support existing emergency call o Emergency calling mechanisms must support existing emergency call
centers based on circuit-switched technology as well as future ECC centers based on circuit-switched technology as well as future ECC
that are SIP-capable. that are SIP-capable.
4. Emergency URIs 4. Emergency URIs
A single, global (set of) identifiers for emergency services is Having a single, global identifier for emergency services is highly
highly desirable, as it allows end system and network devices to be desirable, as it allows end system and network devices to be built
built that recognize such services and can act appropriately. Such that recognize such services and can act appropriately. Such actions
actions may include restricting the functionality of the end system, may include restricting the functionality of the end system,
providing special features, overriding user service constraints or providing special features, overriding user service constraints or
routing session setup messages. routing session setup messages.
SIP user agents (UAs) that determine that a dialog or transaction SIP user agents (UAs) that determine that a dialog or transaction
relates to an emergency MUST use an emergency call identifier in the relates to an emergency MUST use an an emergency SIP URI defined
Request-URI. The Request-URI MUST be either an emergency SIP URI below as the Request-URI and "To" header field.
defined in Section Section 4.1 or an emergency tel URI defined in
Section Section 4.2.
4.1 SIP URIs for Emergency Calls
It is RECOMMENDED that SIP-based [RFC3261] end systems and proxy It is RECOMMENDED that SIP-based [RFC3261] end systems and proxy
servers support a uniform emergency call identifier, namely the servers support a uniform emergency call identifier, namely the SIP
reserved user name "sos" within any domain, e.g., and SIPS URIs with the reserved user name "sos" within any domain,
e.g.,
sip:sos@example.com sip:sos@example.com
sips:sos@example.com sips:sos@example.com
The reserved name is case-insensitive. The reserved name is case-insensitive.
The host part of the emergency URI SHOULD be the host portion of the The host part of the emergency URI SHOULD be the host portion of the
address-of-record of the caller. The "sips" form SHOULD be used to address-of-record of the caller. The "sips" form SHOULD be used to
ensure integrity and confidentiality. All SIP requests with URIs of ensure integrity and confidentiality; the "sip" form MAY be used if a
this form are assumed to be emergency calls. "sips" call fails with status code 416 (Unsupported URI Scheme). All
SIP requests with URIs of this form are assumed to be emergency
(The domain-of-record was chosen since a SIP user agent may not be calls.
able to determine the local domain it is visiting. This also allows
each user to test this facility, as the user can ensure that such
services are operational in his home domain. An outbound proxy in the
visited domain can handle the call if it believes to be in a position
to provide appropriate emergency services.)
In addition, we reserve user addresses beginning with the string The domain-of-record was chosen since a SIP user agent may not be
"sos." for specific emergency services: able to determine the local domain it is visiting. This also
allows each user to test this facility, as the user can ensure
that such services are operational in his home domain. An
outbound proxy in the visited domain can handle the call if it
believes to be in a position to provide appropriate emergency
services.
sos.fire fire brigade In some cases, end users or, more likely, emergency service routing
sos.rescue ambulance (rescue) proxies may want to request specific emergency services. We support
sos.marine marine guard this feature by leveraging the caller preferences [RFC3841] extension
sos.police police (law enforcement) and define a new media feature tag, service, in Section 8.
sos.mountain mountain rescue
The sub-addresses are also case-insensitive. Additional subaddresses The SIP URI user name "sos" MUST NOT be assigned to any regular user.
can be registered with IANA (Section Section 8).
(In some areas, these emergency services use different numbers.) Outbound proxy servers MUST be configurable to recognize additional
emergency numbers valid in their geographic service area in "tel"
URIs.
The SIP URI user name "sos" and user names starting with "sos." There are about 60 service numbers for emergency services in the
MUSTNOT be assigned to any regular user. world; including them all is not practical, as that would
interfere with existing local two, three and four-digit dialing
plans.
4.2 Tel URIs for Emergency Calls 5. Identifying the Local Emergency Numbers
User agents SHOULD determine the local emergency numbers, either by There are many ways that a user agent can configure emergency numbers
consulting their manual configuration for devices that do not move for use in analyzing calls made with telephony-type user input. Such
across national borders, by DHCP, DNS NAPTR or some other numbers become part of the device dialplan. Mechanisms include
configuration mechanism [schulzrinne-sipping-emergency-arch]. If a configuration tokens such as SIM cards in mobile devices, network-
user agent has no knowledge of local emergency numbers, it MUST also specific solutions (e.g., for 3GPP networks) or protocol-based
recognize the digit strings 000, 08, 112, 110, 118, 119, 911 and 999 solutions. Protocol-based solutions, using XCAP and DNS, are
as emergency numbers. discussed in [I-D.schulzrinne-sipping-emergency-arch]. Given the
different trade-offs in user agent implementation complexity and
deployment difficulty, it appears likely that multiple such
mechanisms will co-exist.
(SIP user agents, such as Ethernet deskphones, that are unlikely to Regardless of the mechanism chosen and whether any of the
move frequently across national borders can easily implement a local configuration mechanisms succeed, the digit strings "112" and "911"
dialing plan that recognizes local emergency numbers. Mobile MUST always be recognized as emergency numbers.
devices, including PDAs and laptops, may not have a reliable way of
determining their current location. Using automatic configuration
avoids collisions with extensions that equal one of the eight numbers
above. If a local network does not have an outbound proxy server,
local dial plans also do not apply, so the problem of number
collision does not arise. Collisions with non-emergency service
numbers are still possible, albeit less likely. For example, 118 is
used for directory assistance in Finland.)
If the user dials any of these digit strings, the UAC SHOULD generate User agents SHOULD allow users and/or administrators to configure
a request with the "sos" URI described in Section Section 4.1 unless additional emergency numbers.
it has discovered a local outbound proxy. In that case, a UAC MAY
use a "tel" URI [RFC2806] without 'phone-context', such as
tel:911 User agents SHOULD attempt to ascertain the set of emergency numbers
tel:112 that are valid in the geographic region that the user agent is
currently located in. Two such mechanisms included XCAP and DNS,
discussed in [I-D.schulzrinne-sipping-emergency-arch].
Outbound proxy servers MUST be configurable to recognize additional If and only if an end system is unable to determine the emergency
local emergency numbers in "tel" URIs. numbers valid in its current geographical location, it SHOULD
recognize any of the number 000, 08, 110, 999, 118 and 119 as
emergency numbers. Since these numbers are also used for non-
emergency purposes, their automatic transformation incurs the risk of
accidentally dialing an emergency number when, for example, directory
assistance was desired. To minimize such mistakes, end systems
SHOULD alert users that they are dialing a recognized emergency
number.
There are about 60 service numbers for emergency services in the This behavior corresponds to the guidelines in 3GPP TS 22.101.
world; including them all is not practical, as that would Since general SIP end points cannot be assumed to have SIMs or
interfere with existing local two, three and four-digit dialing USIMs, this document uses the default list (000, 08, 110, 999, 118
plans. and 119) only if no other configuration information about
geographically local emergency numbers is available.
5. Request Handling 6. Request Handling
Once identified, a user agent can either determine the appropriate Outbound proxy servers SHOULD check whether a tel URIs or a SIP URIs
ECC locally or delegate this task to an outbound proxy. Details are containing a dial string represents an emergency number within its
in [schulzrinne-sipping-emergency-arch]. geographic service area, but only if they can be reasonably certain
that the call originated from within that area, e.g., if the call
contained location information or the network is known to only be
reachable from a restricted geographic area. Typically, these
service areas encompass whole countries since many countries now have
nationwide emergency numbers. Once they recognize an emergency
number, they translate the Request-URI to an "sos" URI as described
above.
Outbound proxy servers MUST recognize all local emergency numbers as The proxy MAY use any additional information contained in the call
well as the tel URIs enumerated in Section Section 4.2. The proxy MAY request to recognize additional numbers as emergency numbers. Such
use any additional information contained in the call request, such as information includes the Mobile Country Code and the Mobile Network
Mobile Country Code and the Mobile Network Code for 3GPP devices, to Code for 3GPP devices or country information in location information
recognize additional numbers as emergency numbers. available about the call, The [I-D.schulzrinne-sipping-emergency-
arch] document describes a possible DNS-based mechanism to obtain
country-specific emergency numbers.
It is RECOMMENDED that gateway SIP MESSAGE requests are directed to a It is RECOMMENDED that gateway SIP MESSAGE requests are directed to a
TTY-for-the-deaf translator or a short-message service (SMS) if the TTY-for-the-deaf translator or a short-message service (SMS) if the
emergency call center cannot handle SIP instant messaging. emergency call center cannot handle SIP instant messaging.
OPTIONS requests to the user "sos" and the "sos.*" addresses 7. Alternative Approaches Considered
(sos.fire, etc.) can be used to test if the "sos" addresses are
valid. As in standard SIP, a 200 (OK) response indicates that the
address was recognized and a 404 (Not found) that it was not. Such
request cause no further action. It is RECOMMENDED that user agents
periodically automatically check for the availability of the "sos"
identifier and alert the user if the check fails. The period of such
automated checks SHOULDNOT be less than once per day and MUST be
randomly placed over the testing interval.
6. Identifying the Local Emergency Numbers
There are many ways that a user agent can configure emergency numbers
for use in analyzing calls made with telephony-type user input. Such
numbers become part of the device dialplan. Mechanisms include
configuration tokens such as SIM cards in mobile devices,
network-specific solutions (e.g., for 3GPP networks) or
protocol-based solutions. Protocol-based solutions, using XCAP and
DNS, are discussed in [schulzrinne-sipping-emergency-arch.] Given the
different trade-offs in user agent implementation complexity and
deployment difficulty, it appears likely that multiple such
mechanisms will co-exist.
7. Alternative Identifiers Considered
The "sos" SIP URI reserved user name proposed here follows the The "sos" SIP URI reserved user name proposed here follows the
convention of RFC 2142 [RFC2142] and the "postmaster" convention convention of RFC 2142 [RFC2142] and the "postmaster" convention
documented in RFC 2822 [RFC2822]. One drawback is that it may documented in RFC 2822 [RFC2822]. One drawback is that it may
conflict with locally assigned addresses of the form "sos@somewhere". conflict with locally assigned addresses of the form "sos@domain".
There are a number of possible alternatives, each with their own set There are a number of possible alternatives, each with their own set
of advantages and problems: of advantages and problems:
tel:sos This solution avoids name conflicts, but is not a valid "tel" tel:sos This solution avoids name conflicts, but is not a valid "tel"
URI. It also only works if every outbound proxy knows how to URI. It also only works if every outbound proxy knows how to
route requests to a proxy that can reach emergency services. The route requests to a proxy that can reach emergency services. The
SIP URI proposed here only requires a user's home domain to be SIP URI proposed here only requires a user's home domain to be
appropriately configured. appropriately configured.
urn:service:sos A related document [I-D.schulzrinne-sipping-service]
URI parameter: One could create a special URI, such as defines a URN for identifying services, such as emergency calling.
"aor-domain;user=sos". This avoids the name conflict problem, but This solution fits most cleanly into the overall URI architecture
and avoids dependencies on the home domain, but, like the tel URI
solution above, also requires that every outbound proxy can
resolve this URN and can route calls accordingly. Alternatively,
the end system has to be configured with a suitable URN-resolving
proxy, e.g., in its home domain.
URI parameter: One could create a special URI, such as "aor-
domain;user=sos". This avoids the name conflict problem, but
requires mechanism-aware user agents that are capable of emitting requires mechanism-aware user agents that are capable of emitting
this special URI. this special URI.
Special domain: A special domain, such as "sip:fire@sos.int" could be Special domain: A special domain, such as "sip:fire@sos.int" could be
used to identify emergency calls. This has similar properties as used to identify emergency calls. This has similar properties as
the "tel:sos" URI, except that it is indeed a valid URI. the "tel:sos" URI, except that it is indeed a valid URI.
8. IANA Considerations 8. Media Feature Tag Registration: Service
This specification defines an additional media feature tag, extending
the SIP tree entries described in [RFC3840] and following the
registration process in Section 12.1 of that document. This section
serves as the IANA registration for the service feature tags, which
are made into the SIP media feature tag tree.
This facility is not meant to encourage end users to select emergency
services where a uniform ECC for all such services exist. Rather,
these identifiers reflect current practice in jurisdictions that
already have different numbers for the different emergency services.
For example, in Germany, ambulance and fire use 112, while police
uses 110.
We expect that users will rarely invoke specific emergency
services directly. Rather, they might be generated by outbound
proxy servers translating dial strings or be generated when
pressing icon-bearing speed dial buttons.
Using feature tags has the advantage that they are not affected by
entities that translate URIs, e.g., to route emergency calls to a
specific ECC.
The service types for this feature tag are case-insensitive.
Additional service types can be registered with IANA (Section
Section 9).
Media feature tag name: sip.emergency-service
ASN.1 Identifier: New assignment by IANA.
Summary of the media feature indicated by this tag: Each feature tag
indicates the type of communication service requested.
Values appropriate for use with this feature tag: Token with an
equality relationship. Initial values include a number of
emergency services:
sos: general emergency service
sos.fire: fire brigade
sos.marine: marine guard
sos.mountain: mountain rescue
sos.police: police (law enforcement)
sos.rescue: ambulance, emergency medical service
sos.test: testing, not a real emergency call
The feature tag is intended primarily for use in the following
applications, protocols, services, or negotiation mechanisms: This
feature tag is most useful in a communications application, for
describing the capabilities of a user agent providing a particular
type of communication service.
Examples of typical use: Allowing an emergency service proxy to
select the desired emergency service, such as police or ambulance.
Related standards or documents: RFC3840.
Security Considerations: Security considerations for this media
feature tag are discussed in Section 11.1 of RFC3840.
9. IANA Considerations
Subaddresses of the "sos" address are registered with IANA This Subaddresses of the "sos" address are registered with IANA This
specification establishes the "sos" subaddres sub-registry under specification establishes the "sos" subaddres sub-registry under
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Subaddresses are registered by the IANA when they are published in Subaddresses are registered by the IANA when they are published in
standards track RFCs. The IANA Considerations section of the RFC standards track RFCs. The IANA Considerations section of the RFC
must include the following information, which appears in the IANA must include the following information, which appears in the IANA
registry along with the RFC number of the publication. registry along with the RFC number of the publication.
o Name of the subaddress. The name MAY be of any length, but SHOULD o Name of the subaddress. The name MAY be of any length, but SHOULD
be no more than twenty characters long. The name MUST consist of be no more than twenty characters long. The name MUST consist of
alphanumeric characters only and is case-insensitive. NVT alphanumeric characters only and is case-insensitive.
o Descriptive text that describes the emergency service. o Descriptive text that describes the emergency service.
9. Security Considerations 10. Security Considerations
The SIP specification [RFC3261] details security considerations that The SIP specification [RFC3261] details security considerations that
apply to emergency calls as well. Security for emergency calls has apply to emergency calls as well. Security for emergency calls has
conflicting goals, namely to make it as easy and reliable as possible conflicting goals, namely to make it as easy and reliable as possible
to reach emergency services, while discouraging and possibly tracing to reach emergency services, while discouraging and possibly tracing
prank calls. It appears unlikely that classical authentication prank calls. It appears unlikely that classical authentication
mechanisms can be required by emergency call centers, but SIP proxy mechanisms can be required by emergency call centers, but SIP proxy
servers may be able to add identifying information. servers may be able to add identifying information.
Given the sensitive nature of many emergency calls, it is highly Given the sensitive nature of many emergency calls, it is highly
skipping to change at page 12, line 29 skipping to change at page 9, line 25
Allowing the user agent to clearly and unambiguously identify Allowing the user agent to clearly and unambiguously identify
emergency calls makes it possible for the user agent to make emergency calls makes it possible for the user agent to make
appropriate policy decisions. For example, a user agent policy may appropriate policy decisions. For example, a user agent policy may
reveal a different amount of information to the callee when making an reveal a different amount of information to the callee when making an
emergency call. Local laws may affect what information network emergency call. Local laws may affect what information network
servers or service providers may be allowed or be required to release servers or service providers may be allowed or be required to release
to emergency call centers. They may also base their decision on the to emergency call centers. They may also base their decision on the
user-declared destination of the call. user-declared destination of the call.
Recognizing only "sos" in the user's home domain, i.e., the domain of
the user's AOR, prevents spoofing where a link points to a fake
emergency calling number and leads the user to, for example, include
location information in the request.
Additional security considerations related to call routing, Additional security considerations related to call routing,
destination authentication and other issues are detailed in destination authentication and other issues are detailed in
[schulzrinne-sipping-emergency-arch]. [I-D.schulzrinne-sipping-emergency-arch].
10. Acknowledgements 11. Acknowledgements
Andrew Allen, Keith Drage, Mike Pierce, James Polk, Brian Rosen and Andrew Allen, Keith Drage, Cullen Jennings, Mike Pierce, James Polk,
John Schnizlein contributed helpful comments. Brian Rosen and John Schnizlein contributed helpful comments.
Normative References 12. References
12.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806,
April 2000.
[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. Schooler, A., Peterson, J., Sparks, R., Handley, M., and E.
"SIP: Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol
(SIP) Servers", RFC 3361, August 2002. (SIP) Servers", RFC 3361, August 2002.
Informative References [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
12.2 Informative References
[I-D.schulzrinne-sipping-emergency-arch]
Schulzrinne, H. and B. Rosen, "Emergency Services for
Internet Telephony Systems",
draft-schulzrinne-sipping-emergency-arch-02 (work in
progress), October 2004.
[I-D.schulzrinne-sipping-service]
Schulzrinne, H., "A Uniform Resource Name (URN) for
Services", draft-schulzrinne-sipping-service-00 (work in
progress), July 2005.
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
2001. April 2001.
Author's Address Author's Address
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7042 Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 57 change blocks. 
194 lines changed or deleted 258 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/