idnits 2.17.00 (12 Aug 2021) /tmp/idnits47693/draft-schulzrinne-sipping-emergency-arch-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1129. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1135. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 16 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2004) is 6417 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2793' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 1041, but no explicit reference was found in the text == Outdated reference: draft-ietf-avt-rfc2793bis has been published as RFC 4103 == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 == Outdated reference: draft-ietf-geopriv-pidf-lo has been published as RFC 4119 == Outdated reference: draft-ietf-sip-authid-body has been published as RFC 3893 == Outdated reference: draft-ietf-sip-callee-caps has been published as RFC 3840 == Outdated reference: draft-ietf-sip-callerprefs has been published as RFC 3841 == Outdated reference: draft-ietf-sip-gruu has been published as RFC 5627 == Outdated reference: draft-ietf-sipping-config-framework has been published as RFC 6080 == Outdated reference: A later version (-02) exists of draft-ietf-sipping-location-requirements-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sipping-location-requirements' == Outdated reference: A later version (-02) exists of draft-ietf-sipping-sos-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sipping-sos' == Outdated reference: A later version (-03) exists of draft-rosen-dns-sos-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.rosen-dns-sos' == Outdated reference: draft-rosen-iptel-dialstring has been published as RFC 4967 ** Obsolete normative reference: RFC 2733 (Obsoleted by RFC 5109) ** Obsolete normative reference: RFC 2793 (Obsoleted by RFC 4103) ** Obsolete normative reference: RFC 2833 (Obsoleted by RFC 4733, RFC 4734) ** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: draft-ietf-iptel-rfc2806bis has been published as RFC 3966 Summary: 12 errors (**), 0 flaws (~~), 18 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Schulzrinne 2 Internet-Draft Columbia U. 3 Expires: April 18, 2005 B. Rosen 4 Marconi 5 October 18, 2004 7 Emergency Services for Internet Telephony Systems 8 draft-schulzrinne-sipping-emergency-arch-02 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 18, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 Summoning emergency help is a core feature of telephone networks. 44 This document describes how the Session Initiation Protocol (SIP) can 45 be used to provide advanced emergency services for voice-over-IP 46 (VoIP). The architecture employs standard SIP features and requires 47 no new protocol mechanisms. DNS is used to map civil and geospatial 48 locations to the appropriate emergency call center. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Identifying an Emergency Call . . . . . . . . . . . . . . . . 6 56 5. Location and Its Role in an Emergency Call . . . . . . . . . . 7 57 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.2 Types of Location Information . . . . . . . . . . . . . . 7 59 5.3 Sources of Location Information . . . . . . . . . . . . . 8 60 5.3.1 Manually-Entered Location Information . . . . . . . . 9 61 5.3.2 End-System Measured Location Information . . . . . . . 9 62 5.3.3 Third-party Measured Location Information . . . . . . 9 63 5.3.4 Conveying Location to End Systems . . . . . . . . . . 10 64 5.4 Using Location Information for Call Routing . . . . . . . 10 65 5.5 Mid-Call Location Information . . . . . . . . . . . . . . 10 66 5.6 Civic Address Verification . . . . . . . . . . . . . . . . 11 67 6. Routing the Call to the PSAP . . . . . . . . . . . . . . . . . 11 68 6.1 Routing the First Request . . . . . . . . . . . . . . . . 11 69 6.2 DNS-based Mapping from Civic Coordinates to PSAP URIs . . 13 70 6.3 Updating Location Information . . . . . . . . . . . . . . 14 71 7. Signaling of Emergency Calls . . . . . . . . . . . . . . . . . 14 72 8. Preventing Call Misdirection . . . . . . . . . . . . . . . . . 15 73 9. Including a Valid Call-Back Identifier . . . . . . . . . . . . 15 74 10. Mid-Call Services and Behavior . . . . . . . . . . . . . . . 15 75 11. Requirements for SIP Proxy Servers . . . . . . . . . . . . . 15 76 12. Configuration . . . . . . . . . . . . . . . . . . . . . . . 16 77 13. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 13.1 Testing Mechanism . . . . . . . . . . . . . . . . . . . . 17 79 13.2 Manual Testing . . . . . . . . . . . . . . . . . . . . . . 17 80 13.3 Automatic 'sos' Resolution Testing . . . . . . . . . . . . 17 81 14. Requirements for SIP User Agents . . . . . . . . . . . . . . 18 82 14.1 Emergency call taker . . . . . . . . . . . . . . . . . . . 18 83 14.2 Calling users . . . . . . . . . . . . . . . . . . . . . . 18 84 15. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 19 85 16. Alternatives Considered . . . . . . . . . . . . . . . . . . 19 86 16.1 tel URIs . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 16.2 DHCP for Configuring the PSAP URI . . . . . . . . . . . . 19 88 17. Security Considerations . . . . . . . . . . . . . . . . . . 20 89 17.1 Caller Authentication . . . . . . . . . . . . . . . . . . 20 90 17.2 PSAP Impersonation . . . . . . . . . . . . . . . . . . . . 20 91 17.3 Call Signaling Integrity . . . . . . . . . . . . . . . . . 20 92 17.4 Media Integrity and Confidentiality . . . . . . . . . . . 20 93 17.5 PSAP Hiding . . . . . . . . . . . . . . . . . . . . . . . 21 94 18. Changes Since the Last Version . . . . . . . . . . . . . . . 21 95 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 96 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 20.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 98 20.2 Informative References . . . . . . . . . . . . . . . . . . . 24 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 100 Intellectual Property and Copyright Statements . . . . . . . . 26 102 1. Requirements notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Terminology 110 (Emergency) call taker: An emergency call taker is the person that 111 answers an emergency call, typically located in an emergency call 112 center. 113 ECC (emergency control center): Facilities used by emergency 114 organizations to accept and handle emergency calls. A PSAP 115 (below) forwards emergency calls to the emergency control center, 116 which dispatches polic, fire and rescue services. An ECC serves a 117 limited geographic area. A PSAP and ECC can be combined into one 118 facility. (ETSI SR 002 180 definition) 119 ESRP (emergency service routing proxy): SIP proxy that routes 120 incoming emergency calls to the appropriate ECC. 121 PSAP (public safety answering point): Physical location where 122 emergency calls are received under the responsibility of a public 123 authority. (This terminology is used by both ETSI, in ETSI SR 002 124 180, and NENA.) In the United Kingdom, PSAPs are called Operator 125 Assistance Centres, in New Zealand Communications Centres. 126 SIP proxy: see [RFC3261]. 127 SIP UA (user agent): see [RFC3261]. 128 Stationary device (user): User agent that is connected to the network 129 at a fixed, long-term-stable geographic location. Examples 130 include a home PC or a payphone. 131 Nomadic device (user): User agent that is connected to the network 132 temporarily, for relatively short durations, but does not move 133 significantly during the lifetime of a network connection or 134 during the emergency call. Examples include a laptop using an 135 802.11 hotspot or a desk IP phone that is moved from one cubicle 136 to another. 137 Mobile device (user): User agent that changes geographic location and 138 possibly its network attachment point during an emergency call. 140 3. Overview 142 Summoning police, the fire department or an ambulance in emergencies 143 is one of the fundamental and most-valued functions of the telephone. 144 As telephone functionality moves from circuit-switched telephony to 145 Internet telephony, its users rightfully expect that this core 146 functionality works at least as well as for the older technology. 147 However, many of the technical advantages of Internet telephony 148 require re-thinking of the traditional emergency calling 149 architecture. This challenge also offers an opportunity to improve 150 the working of emergency calling technology, while potentially 151 lowering its cost and complexity. 153 It is beyond the scope of this document to enumerate and discuss all 154 the differences between traditional (PSTN) and Internet telephony, 155 but the core differences can be summarized as separation of signaling 156 and media data, the emergence of application-independent carriers, 157 and the potential mobility of all end systems, including landline 158 systems and not just those using radio access technology. 160 This document focuses on how emergency call centers (PSAPs) (Section 161 2) can natively handle Internet telephony emergency calls, rather 162 than describing how circuit-switched PSAPs can handle VoIP calls. 163 However, in many cases, PSAPs making the transition from 164 circuit-switched interfaces to packet-switched interfaces may be able 165 to use some of the mechanisms described here, in combination with 166 gateways that translate packet-switched calls into legacy interfaces, 167 e.g., to continue to be able to use existing call taker equipment. 169 Existing emergency call systems are organized nationally; there are 170 currently no international standards. However, Internet telephony 171 does not respect national boundaries, and thus an international 172 standard is required. 174 Furthermore, VoIP endpoints can be connected through tunneling 175 mechanisms such as virtual private networks (VPNs). This 176 significantly complicates emergency calling, because the location of 177 the caller and the first element that routes emergency calls can be 178 on different continents, with different conventions and processes for 179 handling of emergency calls. The IETF has historically refused to 180 create national variants of its standards. Thus, this document 181 attempts to take into account best practices that have evolved for 182 circuit switched PSAPs, but makes no assumptions on particular 183 operating practices currently in use, numbering schemes or 184 organizational structures. 186 This document assumes that PSAP interface is using the Session 187 Initation Protocol (SIP). Use of a single protocol greatly 188 simplifies the design and operation of the emergency calling 189 infrastructure. Only peer-to-peer protocols such as H.323, ISUP and 190 SIP are suitable for inter-domain communications, ruling out 191 master-slave protocols such as MGCP or H.248/Megaco. The latter 192 protocols can natually be used by the enterprise or carrier placing 193 the call, but any such call would reach the PSAP through a media 194 gateway controller, similar to how interdomain VoIP calls would be 195 placed. Other signaling protocols may also use protocol translation 196 to communicate with a SIP-enabled PSAP. 198 Existing emergency services rely exclusively on voice and 199 conventional text telephony (known as TDD in the United States) media 200 streams. However, more choices of media offer additional ways to 201 communicate, evaluate and assist callers and call takers to handle 202 emergency calls. For example, instant messaging and video could 203 improve the ability to evaluate the situation and provide appropriate 204 instruction prior to arrival of emergency crews. Thus, the 205 architecture described here supports the creation of sessions of any 206 media type, negotiated between the caller and PSAP using existing SIP 207 protocol mechanisms [RFC3264]. 209 While, traditionally, emergency services have been summoned by voice 210 calls only, this document does not rule out the use of additional 211 media during an emergency call, both to support callers with 212 disabilities (e.g., through interactive text or video communications) 213 and to provide additional information to the call taker and caller. 214 For example, video from the caller to the PSAP may allow the call 215 taker to better assess the emergency situation; a video session from 216 the PSAP to the emergency caller may allow the call taker to provide 217 instructions for first aid. 219 The choice of media and encodings is negotiated on a call-by-call 220 basis using standard SIP mechanisms [RFC3264]. To ensure that at 221 least one common means of communications, this document recommends 222 certain minimal capabilities in Section 14 that call taker user 223 agents and PSAP-operated proxies should possess. 225 This document does not prescribe the detailed network architecture 226 for PSAPs or collection of PSAPs. For example, it does not describe 227 where PSAPs may place firewalls or how many SIP proxies they should 228 use. 230 This document does not introduce any new SIP header fields, request 231 methods, status codes, message bodies, or events. User agents 232 unaware of the recommendations in this draft can place emergency 233 calls, but may not be able to provide the same user interface 234 functionality. The document suggests behavior for proxy servers, in 235 particular outbound proxy servers. 237 4. Identifying an Emergency Call 239 Using the PSTN, emergency help can often be summoned at a designated, 240 widely known number, regardless of where the telephone was purchased. 241 However, this number differs between localities, even though it is 242 often the same for a country or region (such as many countries in the 243 European Union). For end systems based on the Session Initiation 244 Protocol (SIP), it is desirable to have a universal identifier, 245 independent of location, to simplify the user experience, allow the 246 automated inclusion of location information and to allow the device 247 and other entities in the call path to perform appropriate 248 processing. 250 As part of the overall emergency calling architecture, we define a 251 common user identifier, "sos", as the contact mechanism for emergency 252 assistance. We refer to this URI as the "emergency calling URI". 253 The calling user agent sets both the "To" header and the request-URI 254 to the emergency URI, so that entities after the ESRP can still 255 readily determine that this is an emergency call. Details are 256 described in [I-D.ietf-sipping-sos]. The draft also discusses how a 257 user agent or outbound proxy determines whether a dialed number 258 represents an emergency number and thus should be translated into a 259 "sos" URI. 261 In addition, user agents SHOULD detect emergency calls following 262 local emergency calling conventions. There are two local 263 conventions, namely those local to the user's SIP domain, e.g., a 264 user's network at work, and those at the caller's current geographic 265 location, e.g., while traveling. The former can be obtained using 266 SIP/XCAP and DNS configuration mechanisms (Section 12). 268 Location information can be provided by the user agent or a proxy. 269 If the user agent provides this information, the user agent needs to 270 be able to determine that a call is indeed an emergency call as it is 271 unlikely to include location information in each call. 273 5. Location and Its Role in an Emergency Call 275 5.1 Introduction 277 Caller location plays a central role in routing emergency calls. For 278 practical reasons, each PSAP generally handles only calls for a 279 certain geographic area. Other calls that reach it by accident must 280 be manually re-routed (transferred) to the appropriate PSAP, 281 increasing call handling delay and the chance for errors. The area 282 covered by each PSAP differs by jurisdiction, where some countries 283 have only a small number of PSAPs, while others devolve PSAP 284 responsibilities down to the community level. 286 In most cases, PSAPs cover at least a city or town, but there are 287 some areas where PSAP coverage areas follow old telephone rate center 288 boundaries and may straddle more than one city. 290 5.2 Types of Location Information 292 There are four primary types of location information: civic, postal, 293 geospatial, and cellular cell tower and sector. 295 Civic: Civic location information describes the location of a person 296 or object by a floor and street address that corresponds to a 297 building or other structure. (This is sometimes also called 298 "civic" location information.) 299 Postal: Postal addresses are similar to civic addresses, but the may 300 contain post office boxes or street addresses that do not 301 correspond to an actual building. Also, the name of the post 302 office sometimes does not correspond to the actual community name. 303 Postal addresses are generally unsuitable for emergency call 304 routing, but may be the only address available to a service 305 provider, derived from billing records. 306 Geospatial: Geospatial addresses contain longitude, latitude and 307 altitude information. 308 Cell tower/sector: Cell tower and sectors identify the cell tower and 309 the antenna sector that the mobile device is currently using. 310 (Cell/sector information could also be transmitted as an 311 irregularly shaped polygon of geospatial coordinates reflecting 312 the likely geospatial location of the mobile device, but since 313 these boundaries are not sharp, transmitting the raw information 314 is probaby preferable.) Mobile systems, possible in conjunction 315 with the cell site location, may also transmit mobile country code 316 (MCC) and mobile network code (MNC) of the host network. This MCC 317 and MNC constitutes location information, in that it tells that 318 the user (with border constraints) is in a particular country. In 319 some cases, this may be sufficient for determining the PSAP to be 320 used. 322 5.3 Sources of Location Information 324 Location information can be entered by the user or installer of a 325 device ("manual configuration"), can be measured by the end system, 326 can be conveyed to the end system or can be measured by a third party 327 and inserted into the call signaling. We discuss these in detail 328 below. 330 In some cases, an entity may have multiple sources of location 331 information, possibly partially contradictory. This is particularly 332 likely if the location information is determined both by the end 333 system and a third party. This document provides no recommendation 334 on how to reconcile conflicting location information or which one is 335 to be used by routing elements. Conflicting location information is 336 particularly harmful if it points to multiple distinct PSAPs. If 337 there is no other basis for choice, the ESRP SHOULD determine the 338 appropriate PSAP for all location objects and, if there is a 339 conflict, route based on the most accurate one. 341 All location objects MUST be delivered to the PSAP. To facilitate 342 such policy decisions, location information SHOULD contain 343 information about the source of data, such as GPS, manually entered 344 or based on subscriber address information. In addition, the author 345 of the location information SHOULD be included. 347 TBD: SIP system should indicate which location information has been 348 used for routing, so that the same location information is used for 349 all call routing decisions. Otherwise, two proxies might pick 350 different location information from the call request, each pointing 351 to the other one. 353 End systems and network elements can derive location information from 354 a variety of sources. It is not the goal of this document to 355 exhaustively enumerate them, but we provide a few common examples in 356 the sections below. 358 5.3.1 Manually-Entered Location Information 360 Location information can be maintained by the end user or the 361 installer of a network connection ("wire database"). In LANs, wire 362 databases map Ethernet switch ports to office locations. In DSL 363 installations, the local telephone carrier maintains a mapping of 364 wire pairs to subscriber addresses. 366 Even for IEEE 802.11 wireless access points, wire data bases may 367 provide sufficient location accuracy. 369 Location information added by end users is almost always inferior to 370 measured or wire database information, as users may mistype civic 371 location information, may not know the meaning of geospatial 372 coordinates or may use address information that does not correspond 373 to a recognized civic address. 375 Wire databases are likely to be the most promising solution for 376 residential users where a service provider knows the customer's 377 service address. The service provider can then perform address 378 verification, similar to the current system in some jurisdictions. 380 5.3.2 End-System Measured Location Information 382 GPS: Global Positioning System (GPS) information is generally only 383 available where there is a clear view of a large swath of the sky. 384 It is accurate to tens of feet. 386 5.3.3 Third-party Measured Location Information 387 Wireless triangulation: Elements in the network infrastructure 388 triangulate end systems based on signal strength or time of 389 arrival. Signal strength may be reported by access points, 390 special measurement devices or the end systems. 391 Location beacons: A short range wireless beacon, e.g., using 392 BlueTooth or infrared, announces its location to mobile devices in 393 the vicinity. 395 5.3.4 Conveying Location to End Systems 397 Unless a user agent has access to locally measured location 398 information, it MUST use DHCP to obtain location information. DHCP 399 can deliver civic [I-D.ietf-geopriv-dhcp-civil] or geospatial 400 [RFC3825] information. User agents MUST support both formats. Note 401 that a user agent can use DHCP, via the INFORM request, even if it 402 uses other means to acquire its IP address. 404 In addition, link-layer mechanisms such as the Link-Layer Discovery 405 Protocol (LLDP, IEEE 802.1ab), with proposed extensions, MAY also be 406 used to deliver such information. 408 5.4 Using Location Information for Call Routing 410 Since all existing emergency services have limited geographic and 411 jurisdictional coverage, all emergency calls need to be routed to the 412 appropriate PSAP. Rather than to the geographically closest PSAP, 413 calls need to be directed to the most jurisdictionally appropriate 414 one, which may well be further away. 416 5.5 Mid-Call Location Information 418 Location information may not be available at call setup time. For 419 example, if a GPS-enabled cell phone is turned on and then 420 immediately places an emergency call, it can take an additional 20-25 421 seconds before the cell phone acquires a GPS fix and its location. 422 Thus, while it is necessary and expedient to include caller location 423 information in the call setup message, this is not sufficient in all 424 circumstances. In some cases, the initial call setup will proceed 425 based on, for example, cell and sector information and then add 426 location information during the call, rather than delaying the 427 initial call setup by an unacceptable amount of time. 429 In addition, the location of a mobile caller, e.g., in a vehicle or 430 aircraft, can change significantly during the emergency call. 432 Location updates MAY be conveyed either in re-INVITE or UPDATE 433 messages or the PSAP may subscribe to the location information of the 434 caller, using SIP presence mechanisms (RFC 3265 [RFC3265]RFC 3856 436 [RFC3856]). Authorization for subscriptions is for future study. 438 5.6 Civic Address Verification 440 Users of SIP endpoints must be able to verify that their address is 441 valid ahead of an actual emergency call. For example, in the United 442 States, the Master Street Address Guide (MSAG) records all valid 443 street addresses and is used to ensure that phone billing records 444 correspond to valid emergency service street addresses. 446 There are several ways to verify this information, depending on its 447 source. If the location information is provided by the network 448 service provider via DHCP, SIP end systems SHOULD display this 449 information at boot-up and at regular intervals thereafter to allow 450 users to confirm that the information is correct. 452 If the DNS emergency services directory contains street-level 453 addresses rather than just towns or counties, an end system can 454 verify that a civic address, configured manually or via DHCP, exists. 456 6. Routing the Call to the PSAP 458 6.1 Routing the First Request 460 Emergency calls are routed based on one or more of the following 461 criteria expressed in the call setup request (INVITE): 463 Location: Since each PSAP serves a limited geographic region and 464 transferring existing calls delays the emergency response, calls 465 need to be routed to the most appropriate PSAP. In this 466 architecture, emergency call setup requests contain location 467 information, expressed in civic or geospatial coordinates, that 468 allows such routing. If there is no or imprecise (e.g., cell 469 tower and sector) information at call setup time, an on-going 470 emergency call may also be transferred to another PSAP based on 471 location information that becomes available in mid-call. 472 Type of emergency service: In some jurisdictions, emergency calls for 473 fire, police, ambulance or mountain rescue are directed to 474 emergency-specific PSAPs. We support this mechanism by optionally 475 labeling calls with a service identifier [I-D.ietf-sipping-sos]. 476 Using the caller preferences [I-D.ietf-sip-callerprefs] 477 mechanisms, ESRPs can then route labeled calls appropriately. 478 Media capabilities of caller: In some cases, emergency call centers 479 for specific caller media preferences, such as typed text or 480 video, are separate from voice systems. Also, even if media 481 capability does not affect the selection of the PSAP, there may be 482 call takers within the PSAP that are specifically trained, e.g., 483 in interactive text or sign language communications. Again, we 484 use the callee capabilities [I-D.ietf-sip-callee-caps] mechanism 485 to label and route such calls. 487 Call routing can be performed in three different ways: 489 1. The calling user agent can route the call to the PSAP URI it 490 received in a DHCP or SIP configuration message (not discussed 491 further; TBD!). This is generally only possible for stationary 492 and nomadic devices. In that case, the DHCP server has to be 493 able to map callers to PSAP URIs. 494 2. The calling user agent uses DNS to translate a geospatial or 495 civic address into a URI identifying a PSAP or group of PSAPs. 496 This mode can be used by stationary, nomadic and mobile devices. 497 3. Any SIP proxy along the call path from the mobile device to the 498 home domain can recognize an emergency call and route it based on 499 the location information contained in the INVITE request, using 500 DNS or other mechanisms not defined in this document. 502 Each proxy receiving an emergency call request, identified as 503 described in Section 4, attempts to route the call to the most 504 appropriate PSAP, group of PSAPs or another, more suitable ESRP. 505 Similarly, a user agent can also directly route emergency calls if it 506 has location information, either obtained locally or from a redirect 507 response provided by the outbound proxy. There are three types of 508 routing actions: default routing, DNS-based routing and local 509 routing. Not all routing actions can take all three dimensions 510 (location, type of service, capabilities) into account. 512 ESRPs and user agents using default routing forward all emergency 513 call requests to one designated ESRP, regardless of the location of 514 the caller, type of service or media capabilities. 516 ESRPs and user agents using DNS-based routing employ the mechanism in 517 [I-D.rosen-dns-sos] to route calls to another ESRP that is qualified 518 to handle the emergency call. 520 Finally, an ESRP MAY use a local database or other query protocols to 521 perform call routing using location, type of service or callee 522 capabilities. The details of such a database are beyond the scope of 523 this document. 525 Call routing may combine several of these methods. For example, an 526 outbound proxy might route all emergency calls to a designated ESRP. 527 The ESRP extracts civic location information from the request and 528 converts the elements into a DNS query, using the "sos.arpa" domain, 529 starting from the countrycode and adding the A1 through A6 elements 530 of the civic location contained [I-D.ietf-geopriv-pidf-lo] in the 531 call. It starts from the most precise location and strips location 532 elements if there are no entries at that level. For example, the 533 ESRP might find that "leonia.bergen.nj.us.sos.arpa" does not exist, 534 but that "bergen.nj.us.sos.arpa" features an entry. The ESRP 535 identified in that entry may in turn use the location information to 536 route the request to individual communities, without exposing this 537 information to the public. In the extreme case, only a country-level 538 ESRP needs to be exposed in DNS. Thus, each jurisdiction can make 539 its own decisions as to whether it wants to use DNS or local 540 databases to perform call routing. 542 If an emergency call INVITE request does not contain location 543 information and no other location hints (such as subscriber identity) 544 are available, the first ESRP in the call path SHOULD route it to a 545 PSAP or group of PSAPs that is geographically local to that proxy, 546 since no other call routing can be performed. 548 Jurisdictions organizing PSAPs may choose to implement multiple 549 levels of routing based on location. For example, a state, province 550 or county might deploy an ESRP in front of a collection of PSAPs. 551 The information available to a VoIP carrier or enterprise ESRP may be 552 coarse, so that any location within the state or province gets routed 553 to that representative ESRP, with that ESRP performing the detailed 554 routing to a specific PSAP. The routing mechanism used by the ESRP 555 may nor may not rely on public information. Depending on choices 556 made by the operator of the PSAP and ESRP, the PSAP may only be 557 reachable by SIP requests routed through the ESRP. 559 6.2 DNS-based Mapping from Civic Coordinates to PSAP URIs 561 We define a hierarchy of domain names corresponding to the country 562 name and A1 through A6 hierarchy of administrative units (e.g., 563 state, county, and city), as subdomains below sos.arpa. For example, 564 the domain leonia.bergen.nj.us.sos.arpa designates the town of Leonia 565 in Bergen County in the state of New Jersey, United States. Unless 566 the domain is the lowest one in the hierarchy, with no subdomains, it 567 contains a PTR resource record pointing to the leaves below it. For 568 example: 570 us.sos.arpa. PTR al.us.sos.arpa. 571 us.sos.arpa. PTR ak.us.sos.arpa. 572 us.sos.arpa. PTR as.us.sos.arpa. 573 us.sos.arpa. PTR az.us.sos.arpa. 574 ... 575 us.sos.arpa. PTR wi.us.sos.arpa. 576 us.sos.arpa. PTR wy.us.sos.arpa. 578 nj.us.sos.arpa. PTR sussex.nj.us.sos.arpa. 579 nj.us.sos.arpa. PTR passaic.nj.us.sos.arpa. 580 nj.us.sos.arpa. PTR bergen.nj.us.sos.arpa. 581 ... 582 bergen.nj.us.sos.arpa. PTR fort_lee.bergen.nj.us.sos.arpa. 583 bergen.nj.us.sos.arpa. PTR leonia.bergen.nj.us.sos.arpa. 584 ... 585 leonia.bergen.nj.us.sos.arpa IN NAPTR 586 NAPTR 100 10 "u" "SOS" "/.*/sips:fire@leoniaboro.org/i" . 587 ... 589 PTR records were chosen since they are designed to allow retrieval of 590 multiple matching resource records, without doing a zone transfer. 592 Street names and their components (XXX in PIDF-LO) are concatenated 593 by using a hyphen in the order .... Empty elements are omitted, 594 including the hyphen. 596 6.3 Updating Location Information 598 Location information is needed both for routing the initial INVITE 599 message in a call as well as possibly later during a call since 600 location information may change or only become available later, after 601 the call has reached a PSAP. 603 The caller sends UDPATE [RFC3311], either prior to completion of the 604 initial INVITE transaction or during the call, to the destination. 605 Care must be taken that these requests are routed to the same 606 destination as the original call-initiating request. This is 607 unlikely to be a problem for a re-INVITE if the Contact header field 608 in the 200 OK indicates the PSAP address. 610 7. Signaling of Emergency Calls 612 Since emergency calls carry privacy-sensitive information, they are 613 subject to the requirements for geospatial protocols. In particular, 614 signaling information MUST be carried in TLS, i.e., in 'sips' mode. 616 Details can be found in [I-D.ietf-sipping-location-requirements]. 618 8. Preventing Call Misdirection 620 We need to prevent an emergency call reaching a destination other 621 than an PSAP. For example, a rogue UA able to intercept SIP requests 622 might be able to impersonate an PSAP. 624 In the absence of a globally recognized certificate that ensures that 625 the owner is a legitimate PSAP, we rely on a chain of trust enforced 626 by the 'sips' URI schema. The 'sips' URI schema forces each SIP hop 627 to route the call only to destinations supporting TLS transport. 628 Each ESRP MUST verify that the next-hop destination chosen as 629 described in Section 6 corresponds to the server certificate offered 630 by that destination. 632 9. Including a Valid Call-Back Identifier 634 The call taker must be able to reach the emergency caller if the 635 original call is disconnected. In traditional emergency calls, 636 wireline and wireless emergency calls include a callback number for 637 this purpose. In SIP systems, the caller SHOULD include a Contact 638 header indicating its device URI, if available, or possibly a GRUU 639 [I-D.ietf-sip-gruu] if calls need to be routed via a proxy. 641 10. Mid-Call Services and Behavior 643 If the called PSAP can sign the response, it can include the 644 'service' media feature tag in the response to indicate to the 645 calling user agent that the call is an emergency call. The calling 646 user agent can then modify its normal behavior to reflect the special 647 nature of the call, e.g., to prevent accidental disconnects. A UA 648 MUST NOT modify its behavior unless the call response is 649 authenticated, as this could otherwise be used by malicious 650 destinations to affect caller UA functionality. 652 The PSAP MAY return 403 (Forbidden) in response to a BYE request if 653 caller hangs up before the PSAP wants to relinquish the call. 655 11. Requirements for SIP Proxy Servers 657 All ESRP SHOULD support RFC 3261 [RFC3261] with UDP, TCP, TLS 658 transports. 660 User agent servers and proxy servers MUSTNOT require that the user 661 agent client be registered or authenticated in order to place an 662 emergency call. 664 For robustness, ESRPs SHOULD NOT use RFC 1918 [RFC1918] addresses, 665 i.e., should not be behind network address translators. 667 12. Configuration 669 SIP devices do not require any additional configuration to place 670 emergency calls. They SHOULD use the local outbound proxy, 671 discovered via [RFC3361] or [RFC3319]. 673 However, to acquire local dial plan numbers, the SIP configuration 674 framework [I-D.ietf-sipping-config-framework] can be used. The 675 format for dial plans remains to be defined. A device may retrieve 676 dial plan information for emergency calls from two locations, namely 677 the user's home domain and the local outbound proxy, as described in 678 Section 3.13 of [I-D.ietf-sipping-config-framework]. 680 Since a traveling user cannot rely on a DHCP server in the visited 681 location to have accurate local emergency number information, we also 682 propose a new DNS resource record, EN. Typically, this resource 683 record will be associated with a country-level 'sos.arpa' zone, as 684 most countries either have or are developing country-wide emergency 685 numbers. These number strings are treated as dial strings 686 [I-D.rosen-iptel-dialstring], not "tel" URIs. TBD: It might be 687 possible to use NAPTR [RFC2915] records to include translations such 688 that 112 becomes sos for de.sos.arpa. NAPTR translations are not 689 limited to hostnames or URIs. 691 In the example below, the German emergency number for police is 692 translated into an 'sos' URI. This only works if there is a 693 designated SIP proxy that can route all emergency calls originating 694 in Germany. There does not appear to be a way to substitute the 695 caller's current home AOR domain, although one could conceivably 696 adopt a convention for including this information. Note that this 697 mechanism would also allow direct routing based on finer-grained 698 location information, e.g., at the city level. 700 de.sos.arpa. 701 ;; order pre flags service regexp replacement 702 IN NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@notfall.de/i" . 704 bonn.nrw.de.sos.arpa. 705 ;; order pre flags service regexp replacement 706 IN NAPTR 100 10 "u" "SOS" "/110/sips:sos.police@pol.bonn.de/i" . 708 Example NAPTR records to map dial strings to 'sos' URIs 710 Figure 2 712 In addition to the generic mechanism describe above, there may be 713 access transport specific mechanisms for downloading this information 714 to the user agent. For example, a 3GPP phone from release 5 onwards 715 can have emergency number information downloaded from visited network 716 entities at network registration time. 718 13. Testing 720 13.1 Testing Mechanism 722 Since the emergency calling architecture consists of a number of 723 pieces operated by independent entities, it is important to be able 724 to test whether an emergency call is likely to succeed without 725 actually occupying the human resources at a PSAP. Both signaling and 726 media paths need to be tested since NATs and firewalls may allow the 727 session setup request to reach the PSAP, while preventing the 728 exchange of media. 730 INVITE requests to the user "sos" address and a service indicator of 731 sos.test can be used to test if the "sos" address is valid. As in 732 standard SIP, a 200 (OK) response indicates that the address was 733 recognized and a 404 (Not found) that it was not. Such request cause 734 no further action. The response MAY contain a message body 735 describing the PSAP that was reached and may automatically. The test 736 server SHOULD echo a limited number of RTP audio packets to test 737 media connectivity. 739 User agents SHOULD perform a full call test, including media, 740 according to Section 13.1 after a disconnect and subsequent change in 741 IP address, as the NAT configuration may have changed. 743 User agents MUST NOT place a test call immediately after booting, as 744 a widespread power outage and subsequent restoration would impose an 745 inordinate load on the emergency call routing system. 747 13.2 Manual Testing 749 A compliant user agent implementation MUST have the capability to 750 perform the test outlined in Section 13.1 by explicit user request. 752 13.3 Automatic 'sos' Resolution Testing 754 If a user agent does its own call routing, it MUST periodically and 755 after every significant location change ascertain that it can still 756 resolve its current location to a PSAP address. It does not actually 757 have to generate a SIP request to test emergency calls. 759 A significant location change is defined here as a change of one 760 degree or more in longitude or latitude or a change in the A1 or A2 761 level of civil locations. 763 The periodic test should be performed every 24 to 48 hours and MUST 764 be randomly placed over the testing interval. 766 14. Requirements for SIP User Agents 768 14.1 Emergency call taker 770 To increase the likelihood that diverse user equipment can 771 successfully communicate with the PSAP, it is recommended that call 772 taker equipment has at least the following capabilites: 774 Signaling: RFC 3261 [RFC3261], with UDP, TCP and TLS (sips) support. 775 Media transport: RTP and RTCP according to RFC 3550 [RFC3550] and RFC 776 3551 [RFC3551]. SRTP according to RFC 3711. [RFC3711] 777 Audio codecs: G.711, GSM 06.10, DTMF support using RFC 2833 778 [RFC2833], with forward error correction (RFC 2733 [RFC2733]). 779 Interactive text: using RTP according to RFC 2793bis 780 [I-D.ietf-avt-rfc2793bis]. 781 Video: Support H.261, H.263 and H.264 in QCIF, CIF and 4CIF sizes. 782 SIP-based instant messaging: RFC 3428 [RFC3428] 784 14.2 Calling users 786 A user agent placing an emergency call SHOULD use the "sips" URI 787 schema for all such calls, forcing these calls to use TLS as secure 788 hop-by-hop transport. If a call cannot be established using TLS 789 transport, the user agent SHOULD attempt a call using the "sip" URI. 791 If a user agent receives a redirect (3xx) response for an emergency 792 call, it MUST include the location information contained in that 793 response in the outgoing call. This differs from regular behavior 794 for redirects, where the message body is not copied into the new 795 call. 797 User agents MUST support blind transfer using REFER [RFC3515]. 799 A user agent MUST check the Contact URI in redirect responses to see 800 if it is an emergency call, as described in Section 4. If so, the 801 behavior in the previous paragraph applies. 803 End systems that allow human users to initiate an emergency call with 804 a single button press or other similar stimulus SHOULD require 805 callers to confirm their call. 807 UAs SHOULD place a "Priority" header with value "emergency" in all 808 emergency calls, but its presence cannot be relied upon to identify 809 an emergency call. 811 15. Example Call Flows 813 TBD 815 16. Alternatives Considered 817 This is a non-normative appendix. During discussions of emergency 818 calling, a number of suggestions are commonly made. Below, we 819 discuss some of the reasons why these alternatives do not satisfy the 820 requirements of emergency calling. 822 16.1 tel URIs 824 Instead of providing URIs to call routing proxies or end systems, it 825 has been suggested that end systems be configured with a "tel" URI 826 [I-D.ietf-iptel-rfc2806bis]. Such a "tel" URI would have to be 827 routed to a geographically appropriate telephony gateway, as it is 828 unlikely that every building, enterprise or residence will have its 829 own gateway. VoIP devices can be used in networks that are 830 completely unaware of VoIP services, with VoIP service providers that 831 are physically far removed from the caller's network location. Thus, 832 the use of a tel URI simply moves the problem to the outbound proxy, 833 which has to use the caller's location to determine the appropriate 834 telephony gateway. 836 In addition, emergency telephone numbers are far from universal, with 837 some such numbers used for non-emergency purposes elsewhere. Thus, 838 an outbound proxy would have to ascertain the location of the caller 839 to guess whether the "tel" URI identifies an emergency call or some 840 other number. 842 Thus, "tel" URIs are not likely to be appropriate or sufficient for 843 identifying emergency calls and do not, by themselves, solve the call 844 routing problem. 846 16.2 DHCP for Configuring the PSAP URI 848 One could add emergency calling information to network configuration 849 protocols such as DHCP. A DHCP option could identify the appropriate 850 PSAP URI, for example. This simple approach runs into two problems: 851 lack of congruence of DHCP and PSAP serving areas and difficulty of 852 DHCP server configuration. 854 DHCP servers may provide information to large groups of 855 geographically dispersed users, often spanning jurisdictional 856 boundaries. (For example, CATV plants generally do not follow 857 community boundaries.) 858 The DHCP server would also have to be able to determine the 859 appropriate URI. Unless all calls, at least within a country, are 860 routed to a single logical proxy and that proxy maintains a national 861 jurisdictional database, DCHP serves would have to be manually or 862 automatically configured with regional or local PSAP information. 863 Since the number of such DHCP servers is large and since authorities 864 are unlikely to maintain a mailing list of DHCP server operators, it 865 would be up to each owner of such servers to keep up with 866 jurisdictional changes. While such changes are not frequent, they do 867 occur, as PSAP jurisdictions are merged or as unincorporated areas 868 are merged into neighboring municipalities. 870 17. Security Considerations 872 17.1 Caller Authentication 874 To prevent crank calling and to support call back, PSAPs may want to 875 authenticate the caller. If the call is routed via an outbound 876 proxy, the outbound proxy may be able to ascertain whether the 877 identity provided in the call corresponds at least to the appropriate 878 domain. However, visiting users may legitimately feature a different 879 caller identity than the domain of the outbound proxy. Mechanisms 880 such as the authenticated identity body [I-D.ietf-sip-authid-body] 881 may be used to assert identities. 883 In keeping with established customs in circuit-switched emergency 884 calling, authentication cannot be made a pre-requisite for routing or 885 accepting an emergency call. However, a call taker may be more 886 suspicious of a caller and request additional information if the call 887 authenticity cannot be verified. 889 17.2 PSAP Impersonation 891 See Section 8. 893 With DNS-based call routing (Section 6), an attacker could modify the 894 DNS entries for one or more PSAPs, re-routing calls destined for 895 them. Thus, the use of secure DNS is RECOMMENDED. 897 17.3 Call Signaling Integrity 899 To prevent a malicious outsider from manipulating call information, 900 SIP requests SHOULD be routed via "sips" from caller to emergency 901 call taker. 903 17.4 Media Integrity and Confidentiality 905 Media integrity and confidentiality can be assured by the use of 906 SRTP. 908 17.5 PSAP Hiding 910 The issue of hiding PSAP identity has been raised in mailing list 911 discussion. It has been argued that hiding the identity of an PSAP 912 confers some protection against denial-of-service attacks, for 913 example. However, it appears that this notion is based on false 914 assumptions. Unless a B2BUA or NAT is involved, media packets will 915 carry the IP address of the PSAP (or one of its call takers) and thus 916 can be readily used to deduce the address of the PSAP, even if it is 917 not advertised in DNS. (B2BUAs and NATs have known architectural, 918 reliability and other operational disadvantages that do not recommend 919 their use simply to hide PSAP addresses.) 921 Similarly, trying to protect the mapping between geographic location 922 and PSAP is similarly difficult. Unless it is required that all 923 location information is verified in real time, which would be close 924 to impossible for mobile devices, end systems can simply pretend to 925 be in different parts of the city or county and deduce which PSAP is 926 answering the call. 928 18. Changes Since the Last Version 930 Added references to LLDP (IEEE 802.1ab) as a protocol for 931 conveying location to end system. 932 Changed ECC to PSAP. ECC is also used by ETSI (ETSI SR 002 180) 933 to designate Emergency Control Centers, which dispatch emergency 934 assistance. ETSI uses the term PSAP, so it seemed unnecessary to 935 create new terminology. 936 The description of location sources has been extended. 937 An non-normative section on why DHCP or tel URIs are not 938 sufficient has been added. 939 Text on testing and preventing call hang-ups has been added. 941 19. Acknowledgements 943 Keith Drage provided helpful comments. 945 20. References 947 20.1 Normative References 949 [I-D.ietf-avt-rfc2793bis] 950 Hellstrom, G., "RTP Payload for Text Conversation", 951 draft-ietf-avt-rfc2793bis-09 (work in progress), August 952 2004. 954 [I-D.ietf-geopriv-dhcp-civil] 955 Schulzrinne, H., "Dynamic Host Configuration Protocol 956 (DHCPv4 and DHCPv6) Option for Civic Addresses 957 Configuration Information", 958 draft-ietf-geopriv-dhcp-civil-04 (work in progress), 959 October 2004. 961 [I-D.ietf-geopriv-pidf-lo] 962 Peterson, J., "A Presence-based GEOPRIV Location Object 963 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), 964 September 2004. 966 [I-D.ietf-sip-authid-body] 967 Peterson, J., "SIP Authenticated Identity Body (AIB) 968 Format", draft-ietf-sip-authid-body-03 (work in progress), 969 May 2004. 971 [I-D.ietf-sip-callee-caps] 972 Rosenberg, J., "Indicating User Agent Capabilities in the 973 Session Initiation Protocol (SIP)", 974 draft-ietf-sip-callee-caps-03 (work in progress), January 975 2004. 977 [I-D.ietf-sip-callerprefs] 978 Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Caller 979 Preferences for the Session Initiation Protocol (SIP)", 980 draft-ietf-sip-callerprefs-10 (work in progress), October 981 2003. 983 [I-D.ietf-sip-gruu] 984 Rosenberg, J., "Obtaining and Using Globally Routable User 985 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 986 (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 987 2004. 989 [I-D.ietf-sipping-config-framework] 990 Petrie, D., "A Framework for Session Initiation Protocol 991 User Agent Profile Delivery", 992 draft-ietf-sipping-config-framework-04 (work in progress), 993 July 2004. 995 [I-D.ietf-sipping-location-requirements] 996 Polk, J., "Requirements for Session Initiation Protocol 997 Location Conveyance", 998 draft-ietf-sipping-location-requirements-01 (work in 999 progress), July 2004. 1001 [I-D.ietf-sipping-sos] 1002 Schulzrinne, H., "Emergency Services URI for the Session 1003 Initiation Protocol", draft-ietf-sipping-sos-00 (work in 1004 progress), February 2004. 1006 [I-D.rosen-dns-sos] 1007 Rosen, B., "Emergency Call Information in the Domain Name 1008 System", draft-rosen-dns-sos-01 (work in progress), July 1009 2004. 1011 [I-D.rosen-iptel-dialstring] 1012 Rosen, B., "Dialstring parameter for the sip URI", 1013 draft-rosen-iptel-dialstring-00 (work in progress), June 1014 2004. 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, March 1997. 1019 [RFC2733] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format 1020 for Generic Forward Error Correction", RFC 2733, December 1021 1999. 1023 [RFC2793] Hellstrom, G., "RTP Payload for Text Conversation", RFC 1024 2793, May 2000. 1026 [RFC2833] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF 1027 Digits, Telephony Tones and Telephony Signals", RFC 2833, 1028 May 2000. 1030 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 1031 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 1033 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1034 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1035 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1037 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1038 with Session Description Protocol (SDP)", RFC 3264, June 1039 2002. 1041 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1042 Event Notification", RFC 3265, June 2002. 1044 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1045 UPDATE Method", RFC 3311, October 2002. 1047 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 1048 Protocol (DHCPv6) Options for Session Initiation Protocol 1049 (SIP) Servers", RFC 3319, July 2003. 1051 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 1052 (DHCP-for-IPv4) Option for Session Initiation Protocol 1053 (SIP) Servers", RFC 3361, August 2002. 1055 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. 1056 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1057 for Instant Messaging", RFC 3428, December 2002. 1059 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1060 Method", RFC 3515, April 2003. 1062 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1063 Jacobson, "RTP: A Transport Protocol for Real-Time 1064 Applications", STD 64, RFC 3550, July 2003. 1066 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1067 Video Conferences with Minimal Control", STD 65, RFC 3551, 1068 July 2003. 1070 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. 1071 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1072 RFC 3711, March 2004. 1074 [RFC3825] Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host 1075 Configuration Protocol Option for Coordinate-based 1076 Location Configuration Information", RFC 3825, July 2004. 1078 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1079 Initiation Protocol (SIP)", RFC 3856, August 2004. 1081 20.2 Informative References 1083 [I-D.ietf-iptel-rfc2806bis] 1084 Schulzrinne, H., "The tel URI for Telephone Numbers", 1085 draft-ietf-iptel-rfc2806bis-09 (work in progress), June 1086 2004. 1088 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 1089 E. Lear, "Address Allocation for Private Internets", BCP 1090 5, RFC 1918, February 1996. 1092 Authors' Addresses 1094 Henning Schulzrinne 1095 Columbia University 1096 Department of Computer Science 1097 450 Computer Science Building 1098 New York, NY 10027 1099 US 1101 Phone: +1 212 939 7042 1102 EMail: hgs@cs.columbia.edu 1103 URI: http://www.cs.columbia.edu 1105 Brian Rosen 1106 Marconi 1107 2000 Marconi Drive 1108 Warrendale, PA 15086 1109 US 1111 EMail: brian.rosen@marconi.com 1113 Intellectual Property Statement 1115 The IETF takes no position regarding the validity or scope of any 1116 Intellectual Property Rights or other rights that might be claimed to 1117 pertain to the implementation or use of the technology described in 1118 this document or the extent to which any license under such rights 1119 might or might not be available; nor does it represent that it has 1120 made any independent effort to identify any such rights. Information 1121 on the procedures with respect to rights in RFC documents can be 1122 found in BCP 78 and BCP 79. 1124 Copies of IPR disclosures made to the IETF Secretariat and any 1125 assurances of licenses to be made available, or the result of an 1126 attempt made to obtain a general license or permission for the use of 1127 such proprietary rights by implementers or users of this 1128 specification can be obtained from the IETF on-line IPR repository at 1129 http://www.ietf.org/ipr. 1131 The IETF invites any interested party to bring to its attention any 1132 copyrights, patents or patent applications, or other proprietary 1133 rights that may cover technology that may be required to implement 1134 this standard. Please address the information to the IETF at 1135 ietf-ipr@ietf.org. 1137 Disclaimer of Validity 1139 This document and the information contained herein are provided on an 1140 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1141 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1142 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1143 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1144 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1145 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1147 Copyright Statement 1149 Copyright (C) The Internet Society (2004). This document is subject 1150 to the rights, licenses and restrictions contained in BCP 78, and 1151 except as set forth therein, the authors retain all their rights. 1153 Acknowledgment 1155 Funding for the RFC Editor function is currently provided by the 1156 Internet Society.