One document matched: draft-schulzrinne-sipping-emergency-arch-00.txt
Network Working Group H. Schulzrinne
Internet-Draft Columbia U.
Expires: August 8, 2004 B. Rosen
Marconi
February 8, 2004
Emergency Services for Internet Telephony Systems
draft-schulzrinne-sipping-emergency-arch
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Summoning emergency help is a core feature of telephone networks.
This document describes how the Session Initiation Protocol (SIP) can
be used to provide advanced emergency services for voice-over-IP
(VoIP). The architecture employs standard SIP features and requires
no new protocol mechanisms. DNS is used to map civil and geospatial
locations to the appropriate emergency call center.
Schulzrinne & Rosen Expires August 8, 2004 [Page 1]
Internet-Draft Emergency Arch February 2004
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Identifying an Emergency Call . . . . . . . . . . . . . . . 7
5. Location and Its Role in an Emergency Call . . . . . . . . . 8
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Types of Location Information . . . . . . . . . . . . . . . 8
5.3 Sources of Location Information . . . . . . . . . . . . . . 8
5.4 Using Location Information for Call Routing . . . . . . . . 10
6. Routing the Call to the ECC . . . . . . . . . . . . . . . . 11
6.1 Routing the First Request . . . . . . . . . . . . . . . . . 11
6.2 Updating Location Information . . . . . . . . . . . . . . . 11
7. Preventing Call Misdirection . . . . . . . . . . . . . . . . 13
8. Requirements for SIP Proxy Servers . . . . . . . . . . . . . 14
9. Configuration . . . . . . . . . . . . . . . . . . . . . . . 15
10. Requirements for SIP User Agents . . . . . . . . . . . . . . 16
10.1 Emergency call taker . . . . . . . . . . . . . . . . . . . . 16
10.2 Calling users . . . . . . . . . . . . . . . . . . . . . . . 16
11. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 17
12. Security Considerations . . . . . . . . . . . . . . . . . . 18
12.1 ECC Impersonation . . . . . . . . . . . . . . . . . . . . . 18
12.2 Call Content Integrity . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . 21
Schulzrinne & Rosen Expires August 8, 2004 [Page 2]
Internet-Draft Emergency Arch February 2004
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Schulzrinne & Rosen Expires August 8, 2004 [Page 3]
Internet-Draft Emergency Arch February 2004
2. Overview
Summoning police, the fire department or an ambulance in emergencies
is one of the fundamental and most-valued functions of the telephone.
As telephone functionality moves from circuit-switched telephony to
Internet telephony, its users rightfully expect that this core
functionality works at least as well as for the older technology.
However, many of the technical advantages of Internet telephony
require re-thinking of the traditional emergency calling
architecture. This challenge also offers an opportunity to improve
the working of emergency calling technology, while potentially
lowering its cost and complexity.
It is beyond the scope of this document to enumerate and discuss all
the differences between traditional (PSTN) and Internet telephony,
but the core differences can be summarized as separation of signaling
and media data, the emergence of application-independent carriers,
and the potential mobility of all end systems, including landline
systems and not just those using radio access technology.
This document focuses on how ECCs can natively handle Internet
telephony emergency calls, rather than Describing how
circuit-switched ECCs can handle VoIP calls. However, in many cases,
ECCs making the transition from circuit-switched interfaces to
packet-switched interfaces may be able to use some of the mechanisms
described here, in combination with gateways that translate
packet-switched calls into legacy interfaces, e.g., to continue to be
able to use existing call taker equipment.
Existing emergency call systems are organized nationally; there are
currently no international standards. However, Internet telephony
does not respect national boundaries, and thus an international
standard is required.
Furthermore, VoIP endpoints can be connected through tunneling
mechanisms such as virtual private networks (VPNs). This
significantly complicates emergency calling, because the location of
the caller and the first element that routes emergency calls can be
on different continents, with different conventions and processes for
handling of emergency calls. The IETF has historically refused to
create national variants of its standards. Thus, this document
attempts to take into account best practices that have evolved for
circuit switched ECCs, but makes no assumptions on particular
operating practices currently in use, numbering schemes or
organizational structures.
This document assumes that ECC interface is using the Session
Initation Protocol (SIP). Use of a single protocol greatly
Schulzrinne & Rosen Expires August 8, 2004 [Page 4]
Internet-Draft Emergency Arch February 2004
simplifies the design and operation of the emergency calling
infrastructure. Only peer-to-peer protocols such as H.323, ISUP and
SIP are suitable for inter-domain communications, ruling out
master-slave protocols such as MGCP or H.248/Megaco. The latter
protocols can natually be used by the enterprise or carrier placing
the call, but any such call would reach the ECC through a media
gateway controller, similar to how interdomain VoIP calls would be
placed. Other signaling protocols may also use protocol translation
to communicate with a SIP-enabled ECC.
Existing emergency services rely exclusively on voice, and
conventional TDD text media streams. However, more choices of media
offer additional ways to communicate, evaluate and assist callers and
call takers to handle emergency calls. For example, instant
messaging and video could improve the ability to evaluate the
situation and provide appropriate instruction prior to arrival of
emergency crews. Thus, the architecture described here supports the
creation of sessions of any media type, negotiated between the caller
and ECC using existing SIP protocol mechanisms [RFC3264].
While traditionally, emergency services have been summoned by voice
calls only, this document does not rule out the use of additional
media during an emergency call, both to support callers with
disabilities (e.g., through interactive text or video communications)
and to provide additional information to the call taker and caller.
For example, video from the caller to the ECC may allow the call
taker to better assess the emergency situation; a video session from
the ECC to the emergency caller may allow the call taker to provide
instructions for first aid.
The choice of media and encodings is negotiated on a call-by-call
basis using standard SIP mechanisms [RFC3265]. To ensure that at
least one common means of communications, this document recommends
certain minimal capabilities in Section Section 10 that call taker
user agents and ECC-operated proxies should possess.
This document does not prescribe the detailed network architecture
for ECCs or collection of ECCs. For example, it does not describe
where ECCs may place firewalls or how many SIP proxies they should
use.
This document does not introduce any new SIP header fields, request
methods, status codes, message bodies, or events. User agents unaware
of the recommendations in this draft can place emergency calls, but
may not be able to provide the same user interface functionality. The
document suggests behavior for proxy servers, in particular outbound
proxy servers.
Schulzrinne & Rosen Expires August 8, 2004 [Page 5]
Internet-Draft Emergency Arch February 2004
3. Terminology
(emergency) call taker Person that answers an emergency call;
typically located in an emergency call center.
ECC (emergency call center) Call center that receives emergency calls
and dispatches polic, fire and rescue services. An ECC serves a
limited geographic area. In the United States, PSAPs are ECCs.
ESRP (emergency service routing proxy) SIP proxy that routes incoming
emergency calls to the appropriate ECC.
PSAP (public safety answering point) The United States and Canadian
term for ECC.
SIP proxy see [RFC3261]
SIP UA (user agent) see [RFC3261]
Schulzrinne & Rosen Expires August 8, 2004 [Page 6]
Internet-Draft Emergency Arch February 2004
4. Identifying an Emergency Call
Using the PSTN, emergency help can often be summoned at a designated,
widely known number, regardless of where the telephone was purchased.
However, this number differs between localities, even though it is
often the same for a country or region (such as many countries in the
European Union). For end systems based on the Session Initiation
Protocol (SIP), it is desirable to have a universal identifier,
independent of location, to simplify the user experience, allow the
automated inclusion of location information and to allow the device
and other entities in the call path to perform appropriate
processing.
As part of the overall emergency calling architecture, we define a
common user identifier, "sos" and "sos" with an emergency service
designation, as the contact mechanism for emergency assistance. In
addition, two tel URIs, tel:112 and tel:911, are permissible as
emergency call identifiers issued by a user agent. We refer to this
URI as the "emergency calling URI". The calling user agent sets both
the "To" header and the request-URI to the emergency URI, so that
entities after the ESRP can still readily determine that this is an
emergency call. Details are described in
[draft-schulzrinne-sipping-sos].
In addition, user agents SHOULD detect emergency calls following
local emergency calling conventions. There are two local
conventions, namely those local to the user's SIP domain, e.g., a
user's network at work, and those at the caller's current geographic
location, e.g., while traveling. The former can be obtained using
SIP configuration mechanisms (Section Section 9). Obtaining
geographically local emergency numbers is more difficult,
particularly if the outbound proxy or DHCP server may be in a
different country than the caller. There are several, complementary
solutions. First, DHCP can be extended with a pointer to a local SIP
configuration, including the dial plan specifying emergency numbers.
In addition, we define a new DNS resource record that identifies the
country-specific emergency number.
Location information can be provided by the user agent or a proxy. If
the user agent provides this information, the user agent needs to be
able to determine that a call is indeed an emergency call as it is
unlikely to include location information in each call.
Schulzrinne & Rosen Expires August 8, 2004 [Page 7]
Internet-Draft Emergency Arch February 2004
5. Location and Its Role in an Emergency Call
5.1 Introduction
Caller location plays a central role in routing emergency calls. For
practical reasons, each ECC generally handles only calls for a
certain geographic area. Other calls that reach it by accident must
be manually re-routed (transferred) to the appropriate ECC,
increasing call handling delay and the chance for errors. The area
covered by each ECC differs by jurisdiction, where some countries
have only a small number of ECCs, while others devolve ECC
responsibilities down to the community level.
In most cases, ECCs cover at least a city or town, but there are some
areas where ECC coverage areas follow old telephone rate center
boundaries and may straddle more than one city.
5.2 Types of Location Information
There are four primary types of location information: civil, postal,
geospatial, and cellular cell tower and sector.
Civil: Civil information describes the location of a person or object
by a floor and street address that corresponds to a building or
other structure.
Postal: Postal addresses are similar to civil addresses, but the may
contain post office boxes or street addresses that do not
correspond to an actual building. Postal addresses are generally
unsuitable for emergency call routing, but may be the only address
available to a service provider, derived from billing records.
Geospatial: Geospatial addresses contain longitude, latitude and
altitude information.
Cell tower/sector: Cell tower and sectors identify the cell tower and
the antenna sector that the mobile device is currently using.
(Cell/sector information could also be transmitted as an
irregularly shaped polygon of geospatial coordinates reflecting
the likely geospatial location of the mobile device, but since
these boundaries are not sharp, transmitting the raw information
is probaby preferable.)
5.3 Sources of Location Information
There are two principal contributors of location information. In
some cases, the calling end system knows its current civil and/or
Schulzrinne & Rosen Expires August 8, 2004 [Page 8]
Internet-Draft Emergency Arch February 2004
geospatial location, in others the outbound proxy or other network
entity. In some cases, both such entities may have location
information, possibly partially contradictory. This document
provides no recommendation on how to reconcile conflicting location
information or which one is to be used by routing elements.
Conflicting location information is particularly harmful if it points
to multiple distinct ECCs. If there is no other basis for choice,
the ESRP SHOULD determine the appropriate ECC for all location
objects and, if there is a conflict, route based on the most accurate
one.
To facilitate such policy decisions, location information SHOULD
contain information about the source of data, such as GPS, manually
entered or based on subscriber address information. In addition, the
author of the location information SHOULD be included. TBD: need to
add this to (e.g.) PIDF-LO!
End systems and network elements can derive location information from
a variety of sources. It is not the goal of this document to
exhaustively enumerate them, but we provide a few common examples
below:
GPS: Global Positioning System (GPS) information is generally only
available where there is a clear view of a large swath of the sky.
It is accurate to tens of feet.
Wireless triangulation: Either cell towers or 802.11 access points
triangulate based on signal strength or time of arrival.
DHCP: The device obtains location information provided by its DHCP
server, derived through one of the other methods enumerated here.
Location beacons: A short range wireless beacon, e.g., using
BlueTooth or infrared, announces its location to mobile devices in
the vicinity.
Subscriber information: A carrier has address information reflecting
the service location for its subscribers.
Manual configuration: A user manually enters civil or geospatial
information into a mobile or stationary device.
TBD: there is a need to indicate which location information has been
used to avoid possible routing loops, where two proxies pick
different location information from the call request, each pointing
to the other one.
Schulzrinne & Rosen Expires August 8, 2004 [Page 9]
Internet-Draft Emergency Arch February 2004
5.4 Using Location Information for Call Routing
Note that emergency calls may not be routed to the geographically
closest ECC, but rather to the most jurisdictionally appropriate one,
which may well be further away.
Location information may not be available at call setup time. For
example, if a GPS-enabled cell phone is turned on and then
immediately places an emergency call, it can take an additional 20-25
seconds before the cell phone acquires a GPS fix and its location.
Thus, while it is necessary and expedient to include caller location
information in the call setup message, this is not sufficient in all
circumstances. In some cases, the initial call setup will proceed
based on, for example, cell and sector information and then add
location information during the call, rather than delaying the
initial call setup by an unacceptable amount of time.
In addition, the location of a mobile caller, e.g., in a vehicle or
aircraft, can change significantly during the emergency call.
Schulzrinne & Rosen Expires August 8, 2004 [Page 10]
Internet-Draft Emergency Arch February 2004
6. Routing the Call to the ECC
6.1 Routing the First Request
Emergency calls are routed based on location information contained
within the call setup request (INVITE). If there is no or imprecise
(e.g., cell tower/sector) information, an on-going emergency call may
also be transferred to another ECC based on location information.
Each proxy receiving an emergency call request, identified as
described in Section Section 4, attempts to route the call to the
most appropriate ECC. Similarly, a user agent can also directly
route emergency calls if it has location information, either obtained
locally or from a redirect response provided by the outbound proxy.
There are three types of routing actions: default routing, DNS-based
routing and local routing.
ESRPs and user agents using default routing forward all emergency
call requests to one designated ESRP, regardless of the location of
the caller.
ESRPs and user agents using DNS-based routing employ the mechanism in
[-dns-] to route calls to another ESRP that is qualified to handle
the emergency call. Thus, DNS acts here as a location service for
the proxy.
Finally, an ESRP MAY use a local database to perform location-based
call routing. The details of such a database are beyond the scope of
this document.
If an emergency call INVITE request does not contain location
information and no other location hints (such as subscriber identity)
are available, the first ESRP in the call path SHOULD route it to an
ECC that is geographically local to that proxy, since no other call
routing can be performed.
Jurisdictions organizing ECCs may choose to implement multiple levels
of routing based on location. For example, a state or province might
deploy an ESRP in front of a collection of ECCs. The information
available to a VoIP carrier or enterprise ESRP may be coarse, so that
any location within the state or province gets routed to the state/
province ESRP, with that ESRP doing the detailed routing to a
specific ECC. Thus, each ESRP MUST inspect the INVITE request and
determine if more precise request routing is called for.
6.2 Updating Location Information
Location information is needed both for routing the initial INVITE
Schulzrinne & Rosen Expires August 8, 2004 [Page 11]
Internet-Draft Emergency Arch February 2004
message in a call as well as possibly later during a call since
location information may change or only become available later, after
the call has reached an ECC.
This document considers three mechanisms for conveying updated
location during a call: UPDATE or re-INVITE, INFO or dialog events.
In the first approach, the caller sends UDPATE [RFC3311], prior to
completion of the initial INVITE transaction, or re-INVITE requests
to the destination. Care must be taken that these requests are
routed to the same destination as the original call-initiating
request. This is unlikely to be a problem for a re-INVITE if the
Contact header field in the 200 OK indicates the ECC address.
In the second approach, the ECC subscribes to the location of the
caller, using the SIP event mechanism and PIDF-LO
[I-D.ietf-geopriv-pidf-lo]. This approach has the advantage that
authorized third parties can easily get access to call-related
location information. This also works better if a network entity has
location information, rather than the user agent. With the re-INVITE
approach, the user agent would have to obtain this information via
redirection.
A third alternative is to use the SIP INFO method, as the location
update does not require an offer-answer exchange and does not change
call state.
Schulzrinne & Rosen Expires August 8, 2004 [Page 12]
Internet-Draft Emergency Arch February 2004
7. Preventing Call Misdirection
We need to prevent that an emergency call reaches a destination other
than an ECC. For example, a rogue UA able to intercept SIP requests
might be able to impersonate an ECC.
In the absence of a globally recognized certificate that ensures that
the owner is a legitimate PSAP, we rely on a chain of trust enforced
by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop
to route the call only to destinations supporting TLS transport.
Each ESRP MUST verify that the next-hop destination chosen as
described in Section Section 6 corresponds to the server certificate
offered by that destination.
Schulzrinne & Rosen Expires August 8, 2004 [Page 13]
Internet-Draft Emergency Arch February 2004
8. Requirements for SIP Proxy Servers
All ESRP SHOULD support RFC 3261 [RFC3261] with UDP, TCP, TLS
transports.
For robustness, ESRPs SHOULD NOT use RFC 1918 [RFC1918] addresses,
i.e., should not be behind network address translators.
Schulzrinne & Rosen Expires August 8, 2004 [Page 14]
Internet-Draft Emergency Arch February 2004
9. Configuration
SIP devices do not require any additional configuration to place
emergency calls. They SHOULD use the local outbound proxy, discovered
via [RFC3361] or [RFC3319].
However, to acquire local dial plan numbers, the SIP configuration
framework [I-D.ietf-sipping-config-framework] can be used. The
format for dial plans remains to be defined. A device may retrieve
dial plan information for emergency calls from two locations, namely
the user's home domain and the local outbound proxy, as described in
Section 3.13 of [I-D.ietf-sipping-config-framework].
Since a traveling user cannot rely on a DHCP server in the visited
location to have accurate local emergency number information, we also
propose a new DNS resource record, EN. Typically, this resource
record will be associated with a country-level 'sos.arpa' zone, as
most countries either have or are developing country-wide emergency
numbers. These number strings are treated as dial strings, not "tel"
URIs. TBD: It might be possible to use NAPTR [RFC2915] records to
include translations such that 110 becomes sos.police for
de.sos.arpa. NAPTR translations are not limited to hostnames or URIs.
In the example below, the German emergency number for police is
translated into an 'sos' URI. This only works if there is a
designated SIP proxy that can route all emergency calls originating
in Germany. There does not appear to be a way to substitute the
caller's current home AOR domain, although one could conceivably
adopt a convention for including this information. Note that this
mechanism would also allow direct routing based on finer-grained
location information, e.g., at the city level.
de.sos.arpa.
;; order pre flags service regexp replacement
IN NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@notfall.de/i" .
bonn.nrw.de.sos.arpa.
;; order pre flags service regexp replacement
IN NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@pol.bonn.de/i" .
Example NAPTR records to map dial strings to 'sos' URIs
Figure 1
Schulzrinne & Rosen Expires August 8, 2004 [Page 15]
Internet-Draft Emergency Arch February 2004
10. Requirements for SIP User Agents
10.1 Emergency call taker
To increase the likelihood that diverse user equipment can
successfully communicate with the ECC, it is recommended that call
taker equipment has the following minimal capabilites:
signaling: RFC 3261, with UDP, TCP and TLS (sips) support RFC 3262
audio: RTP and RTCP according to ..., G.711, GSM 06.10, FEC, SRTP
Interactive text
SIP-based instant messaging
10.2 Calling users
A user agent placing an emergency call SHOULD use the "sips" URI
schema for all such calls, forcing these calls to use TLS as secure
hop-by-hop transport. If a call cannot be established using TLS
transport, the user agent SHOULD attempt a call using the "sip" URI.
If a user agent receives a redirect (3xx) response for an emergency
call, it MUST include the location information contained in that
response in the outgoing call. This differs from regular behavior for
redirects, where the message body is not copied into the new call.
A user agent MUST check the Contact URI in redirect responses to see
if it is an emergency call, as described in Section X. If so, the
behavior in the previous paragraph applies.
End systems that allow human users to initiate an emergency call with
a single button press or other similar stimulus SHOULD require
callers to confirm their call.
Schulzrinne & Rosen Expires August 8, 2004 [Page 16]
Internet-Draft Emergency Arch February 2004
11. Example Call Flows
TBD
Schulzrinne & Rosen Expires August 8, 2004 [Page 17]
Internet-Draft Emergency Arch February 2004
12. Security Considerations
12.1 ECC Impersonation
See Section Section 7.
With DNS-based call routing (Section Section 6), an attacker could
modify the DNS entries for one or more ECCs, re-routing calls
destined for them. Thus, the use of secure DNS is RECOMMENDED.
12.2 Call Content Integrity
Schulzrinne & Rosen Expires August 8, 2004 [Page 18]
Internet-Draft Emergency Arch February 2004
Normative References
[I-D.ietf-geopriv-pidf-lo]
Peterson, J., "A Presence-based GEOPRIV Location Object
Format", draft-ietf-geopriv-pidf-lo-01 (work in progress),
February 2004.
[I-D.ietf-sipping-config-framework]
Petrie, D., "A Framework for SIP User Agent
Configuration", draft-ietf-sipping-config-framework-01
(work in progress), October 2003.
[I-D.schulzrinne-geopriv-dhcp-civil]
Schulzrinne, H., "DHCP Option for Civil Location",
draft-schulzrinne-geopriv-dhcp-civil-01 (work in
progress), February 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", RFC 3319, July 2003.
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol
(SIP) Servers", RFC 3361, August 2002.
Schulzrinne & Rosen Expires August 8, 2004 [Page 19]
Internet-Draft Emergency Arch February 2004
Informative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Brian Rosen
Marconi
2000 Marconi Drive
Warrendale, PA 15086
US
EMail: brian.rosen@marconi.com
Schulzrinne & Rosen Expires August 8, 2004 [Page 20]
Internet-Draft Emergency Arch February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
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
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Schulzrinne & Rosen Expires August 8, 2004 [Page 21]
Internet-Draft Emergency Arch February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schulzrinne & Rosen Expires August 8, 2004 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-22 09:43:40 |