idnits 2.17.1 draft-schulzrinne-sipping-sos-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 177 has weird spacing: '....rescue amb...' == Line 178 has weird spacing: '....marine mar...' == Line 179 has weird spacing: '....police pol...' == Line 180 has weird spacing: '...ountain mount...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The user agent SHOULD not issue a REFER during an emergency call. -- 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 (January 8, 2003) is 7769 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2806 (ref. '3') (Obsoleted by RFC 3966) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '16') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3281 (ref. '17') (Obsoleted by RFC 5755) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 Internet Draft H. Schulzrinne 4 Columbia U. 5 draft-schulzrinne-sipping-sos-04.txt 6 January 8, 2003 7 Expires: June 2003 9 Emergency Services for Internet Telephony based on the Session 10 Initiation Protocol (SIP) 12 STATUS OF THIS MEMO 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 To view the list Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes how Session Initiation Protocol (SIP) user 36 agents and proxies can set up emergency calls and, more generally, 37 reach emergency assistance via SIP requests. For that purpose, it 38 defines a universal emergency SIP URI, sip:sos@domain and 39 sips:sos@domain, that allows SIP user agents to contact the local 40 emergency number. It also defines conventions that increase the high 41 probability of reaching the appropriate emergency call center. The 42 document does not define any SIP protocol extensions. 44 1 Introduction 46 Using the PSTN, emergency help can often be summoned at a designated, 47 widely known number, regardless of where the telephone was purchased. 48 However, this number differs between localities, even though it is 49 often the same for a country or region (such as many countries in the 50 European Union). For end systems based on the Session Initiation 51 Protocol (SIP) [1], it is desirable to have a universal identifier, 52 independent of location, to simplify the user experience and to allow 53 the device to perform appropriate processing. Here, we define a 54 common user identifier, "sos", as the contact mechanism for emergency 55 assistance. This identifier is meant to be used in addition to any 56 local emergency numbers. 58 We also describe how emergency calls are routed to the appropriate 59 emergency call center (ECC). (In the United States and Canada, 60 emergency call centers are referred to as Public Safety Answering 61 Points (PSAPs).) Since each emergency call center is generally only 62 responsible for a specific geographic area, it is important that 63 calls are routed to the correct ECC. Regardless of whether the ECC is 64 connected to the PSTN or is directly reachable via SIP, the network 65 location of the caller has little relationship to its physical 66 location. If the call is routed through a PSTN gateway, the 67 originating number is likely either associated with the gateway or is 68 permanently assigned to the IP phone, regardless of where it is 69 currently located. For SIP-based ECCs, the IP address or Contact 70 header information in the call only provides crude approximation as 71 to the geographic location of the caller and may well be completely 72 wrong if virtual private networks are used. Thus, the SIP request 73 needs to convey the location of the caller so that the call can be 74 routed appropriately. Section 6 discusses one possible approach. 76 This document does not introduce any new SIP header fields, request 77 methods, status codes, message bodies, or events. User agents unaware 78 of the recommendations in this draft can place emergency calls, but 79 may not be able to provide the same user interface functionality. The 80 document suggests behavior for proxy servers, in particular outbound 81 proxy servers. 83 1.1 Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 87 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 88 [2] and indicate requirement levels for compliant SIP 89 implementations. 91 2 Requirements 93 o SIP-based end systems must be able to reach emergency call 94 centers. These emergency call centers may have SIP 95 capabilities or may be reachable only via a SIP-to-PSTN 96 gateway. Since each ECC serves only a limited geographic area, 97 often defined by jurisdictional boundaries such as state, 98 province or county, SIP-based emergency requests must 100 o While current emergency call centers are limited to voice and 101 TDD (telecommunication device for the deaf) communications, 102 future SIP-based ECCs should handle all relevant means of 103 interaction, including multimedia and instant messaging [8]. 105 o It should be possible for devices to provide user interfaces 106 that can directly cause an emergency call, without the user 107 having to "dial" or type a specific address. 109 o Even as each country is likely to operate their emergency 110 calling infrastructure differently, SIP devices should be able 111 to reach emergency help and, if possible, be located in any 112 country. 114 o While traveling, users must be able to use their familiar 115 "home" emergency identifier. Users should also be able to dial 116 the local emergency number in the country they are visiting. 118 o Any mechanism must be deployable incrementally and work even 119 if not all SIP entities support emergency calling. User agents 120 conforming to the SIP specification [1], but unaware of this 121 document, must be able to place emergency calls, possibly with 122 restricted functionality. 124 o Given incremental deployment, emergency call functionality 125 should be testable by the user without causing an emergency 126 response. 128 o Emergency calling mechanisms must support existing emergency 129 call centers based on circuit-switched technology as well as 130 future ECC that are SIP-capable. 132 o Emergency call mechanisms should not require a specific 133 technology for determining the location of the caller. 135 3 Emergency URIs 137 A single, global (set of) identifiers for emergency services is 138 highly desirable, as it allows end system and network devices to be 139 built that recognize such services and can act appropriately. Such 140 actions may include restricting the functionality of the end system, 141 providing special features, overriding user service constraints or 142 routing session setup messages. 144 UAs that determine that a dialog or transaction relates to an 145 emergency MUST use an emergency call identifier in the Request-URI. 146 The Request-URI MUST be either an emergency SIP URI defined in 147 Section 3.1 or an emergency tel URI defined in Section 3.2. 149 3.1 SIP URIs for Emergency Calls 151 It is RECOMMENDED that SIP-based [1] end systems and proxy servers 152 support a uniform emergency call identifier, namely the reserved user 153 name "sos" within any domain, e.g., 155 sip:sos@example.com 156 sips:sos@example.com 158 The reserved name is case-insensitive. 160 The host part of the emergency URI SHOULD be the host portion of the 161 address-of-record of the caller. The "sips" form SHOULD be used to 162 ensure integrity and confidentiality. All SIP requests with URIs of 163 this form are assumed to be emergency calls. 165 The domain-of-record was chosen since a SIP user agent may 166 not be able to determine the local domain it is visiting. 167 This also allows each user to test this facility, as the 168 user can ensure that such services are operational in his 169 home domain. An outbound proxy in the visited domain can 170 handle the call if it believes to be in a position to 171 provide appropriate emergency services. 173 In addition, we reserve user addresses beginning with the string 174 "sos." for specific emergency services: 176 sos.fire fire brigade 177 sos.rescue ambulance (rescue) 178 sos.marine marine guard 179 sos.police police (law enforcement) 180 sos.mountain mountain rescue 182 The sub-addresses are also case-insensitive. Additional subaddresses 183 can be registered with IANA (Section 11). 185 In some areas, these emergency services use different 186 numbers. 188 The SIP URI user name "sos" and user names starting with "sos." MUST 189 NOT be assigned to any regular user. 191 3.2 Tel URIs for Emergency Calls 193 User agents SHOULD determine the local emergency numbers, either by 194 consulting their manual configuration for devices that do not move 195 across national borders, by DHCP (Section 9) or some other 196 configuration mechanism. If a user agent has no knowledge of local 197 emergency numbers, it MUST also recognize the digit strings 000, 08, 198 112, 110, 118, 119, 911 and 999 as emergency numbers. 200 SIP user agents, such as Ethernet deskphones, that are 201 unlikely to move frequently across national borders can 202 easily implement a local dialing plan that recognizes local 203 emergency numbers. Mobile devices, including PDAs and 204 laptops, may not have a reliable way of determining their 205 current location. Using automatic configuration avoids 206 collisions with extensions that equal one of the eight 207 numbers above. If a local network does not have an outbound 208 proxy server, local dial plans also do not apply, so the 209 problem of number collision does not arise. Collisions with 210 non-emergency service numbers are still possible, albeit 211 less likely. For example, 118 is used for directory 212 assistance in the United Kingdom. 214 If the user dials any of these digit strings, the UAC SHOULD generate 215 a request with the "sos" URI described in Section 3.1 unless it has 216 discovered a local outbound proxy as described in Section 9. In that 217 case, a UAC MAY use a "tel" URI [3,4] without phone-context, such as 219 tel:911 220 tel:112 222 Outbound proxy servers MUST be configurable to recognize additional 223 local emergency numbers in "tel" URIs. 225 There are about 60 service numbers for emergency services 226 in the world; including them all is not practical, as that 227 would interfere with existing local two, three and four- 228 digit dialing plans. 230 4 Request Handling 232 Once identified, a user agent SHOULD direct an emergency call request 233 to an outbound proxy server or use the discovery mechanism described 234 in Section 9 to find a local PSTN gateway that can connect the caller 235 to a local emergency call center. 237 Outbound proxy servers MUST recognize all local emergency numbers as 238 well as the tel URIs enumerated in Section 3.2. The proxy MAY use any 239 additional information contained in the call request, such as Mobile 240 Country Code and the Mobile Network Code for 3GPP devices, to 241 recognize additional numbers as emergency numbers. 243 It is RECOMMENDED that gateway SIP MESSAGE requests are directed to a 244 TTY-for-the-deaf translator or a short-message service (SMS) if the 245 emergency call center cannot handle SIP instant messaging. 247 Using a proxy server that is local to the user agent is 248 more likely to reach a geographically local server, 249 although that is not guaranteed if virtual private networks 250 are being used. 252 User agent servers and proxy servers MUST NOT require that the user 253 agent client be registered or authenticated in order to place an 254 emergency call. 256 OPTIONS requests to the user "sos" and the "sos.*" addresses 257 (sos.fire, etc.) can be used to test if the "sos" addresses are 258 valid. As in standard SIP, a 200 (OK) response indicates that the 259 address was recognized and a 404 (Not found) that it was not. Such 260 request cause no further action. It is RECOMMENDED that user agents 261 periodically automatically check for the availability of the "sos" 262 identifier and alert the user if the check fails. The period of such 263 automated checks SHOULD NOT be less than once per day and MUST be 264 randomly placed over the testing interval. 266 5 Determining User Agent Location 268 Proper handling of emergency calls requires knowledge of the caller 269 location to route the call to the appropriate ECC and to help the ECC 270 in locating the caller when rendering emergency assistance. We 271 describe the routing details in Section 6. 273 The SIP UA determines its location, preferably ahead of the emergency 274 call. It MAY use DHCP [9], retrieving the the location one or more 275 of: geospatial coordinates (longitude, latitude and altitude) [10], 276 civil address (street and community) [11] or network access 277 information such as the port and switch number or the wireless cell 278 identity. 280 The UA needs to inform the DHCP server about its network attachment 281 point. There are several possibilities, including use of the RFC 3046 282 [12] Agent-Circuit-ID or Remote-ID sub-options. This approach will 283 only work if the DHCP relay agent is colocated with the LAN device 284 close to the SIP UA. Another option, not yet fully supported, is to 285 have the UA determine the device and port information and then 286 include this in the DHCP request. There currently is no DHCP option 287 for doing so, however. 289 The UAC inserts this location into a SIP header field. For geographic 290 information, this might look something like the following: 292 Location: ;lat=38.89868 ;long=-77.03723 ;alt=15 ;alt-unit=m 293 ;lares=0.000122 ;lores=0.000122 294 ;hno=600 ;lmk="White House" ;mcn="Washington" 295 ;stn="Pennsylvania" ;sts="Ave" ;sta="DC" 296 ;privacy=dnf 298 Here, we assume that the DHCP option provided a resolution of 22 299 bits. The example is taken from [13]. 301 (The SIP header field format is fictitious and is defined in TBD.) 303 For 3GPP networks, the P-Access-Network-Info header field [14] can 304 convey the cell information, as defined in 3GPP TS 24.229. 306 Alternatively, an outbound proxy may map the UA's device address to a 307 physical location, e.g., based on a traceback within an Ethernet 308 switched LAN. Such mechanisms are beyond the scope of this document. 310 6 Request Routing 312 Any proxy, outbound or otherwise, that receives such a request MUST 313 forward (proxy) or redirect the request to the appropriate emergency 314 number local to the caller, using the location information described 315 in Section 5. 317 Note that in some limited cases, the proxy may be able to determine 318 that the requestor is in the same local network even without explicit 319 location information. This may be the case, for example, if the IP 320 address of the request indicates a local device and the network 321 offers no VPN services. Even under these restricted circumstances, 322 back-to-back UAs may mislead the proxy in this estimation. 324 We distinguish two cases, depending on whether the proxy has access 325 to a location-to-ECC mapping service or not. A special, but 326 important, case is that the caller is known to be local to a PSTN 327 gateway. 329 6.1 Known to be Local 331 In some cases, the proxy server can reliably determine that the 332 caller and a local PSTN gateway are in the same emergency service 333 area. In that case, the proxy forwards the call request to the 334 gateway, translating the emergency URI into the local emergency 335 number. 337 6.2 Mapping Service Available 339 We refer to the location-to-ECC mapping service as a jurisdictional 340 directory service (JDS) since it maps geographic and/or civil 341 locations to emergency response jurisdictions. [TBD: better term?] 342 The JDS can be considered a special kind of SIP location service. The 343 protocol between the proxy and the JDS is beyond the scope of this 344 document. 346 One plausible solution simply proxies the SIP request 347 itself to the JDS. 349 Conceptually, the JDS is provided with a geographic location and 350 possibly the type of emergency service requested (for 351 "sip:sos.service" URIs) and returns SIP or tel URIs for one or more 352 ECCs serving the caller. If the JDS does not recognize the service 353 specification, it treats the mapping request like a general emergency 354 service request. 356 The tel URI returned by the JDS will contain a globally reachable 357 (E.164) number, i.e., a global-number according to [4]. The proxy 358 routes the call accordingly, using a local mechanism to determine the 359 appropriate gateway, e.g., TRIP [5]. 361 Ideally, the chosen gateway should be local to the ECC, but 362 that may not be achievable, as it would require a gateway 363 in every community. In the United States, for example, 364 there are about 5,000 primary emergency call centers, 365 called Public Safety Answering Points (PSAPs). 367 6.3 No Mapping Service Available 369 If the proxy does not have access to a JDS, it attempts to pick the 370 closest PSTN gateway, translates the Request-URI to a locally valid 371 emergency number and proxies the call to that gateway. 373 If a proxy receives a service-specific request of the form 374 "sip:sos.*@domain" (such as "sos.fire@example.com"), the proxy 375 forwards it to the local appropriate specific emergency service. If 376 it does not recognize the suffix (e.g., "fire"), it MUST forward the 377 request to the appropriate general emergency contact, handling it as 378 if the address was "sip:sos@domain". 380 7 Caller Identification 382 When using a PSTN gateway, the gateway causes the calling number to 383 be a telephone number that is mapped by the ECC to the location of 384 the caller. (The process for creating such mappings is beyond the 385 scope of this document. The process has been demonstrated in some 386 jurisdictions for multi-line telephone systems.) It is not clear 387 whether all circuit-switched trunk technologies allow potentially 388 arbitrary, out-of-area calling numbers. 390 8 Call Behavior 392 The user agent SHOULD not issue a REFER during an emergency call. 394 The user agent SHOULD NOT issue a BYE request during an emergency 395 call. If the user "hangs up", it is RECOMMENDED that the end system 396 generate an alert tone until the user reconnects. 398 The UA SHOULD automatically accept an incoming call from the same 399 entity that accepted the previous emergency call. 401 This allows the ECC to call back should the call be 402 interrupted accidentally. 404 9 Identifying the Local Emergency Numbers and Gateway 406 There are many ways that a user agent can configure emergency numbers 407 for use in analyzing calls made with telephony-type user input. These 408 include configuration tokens such as SIM cards in mobile devices, or 409 protocol-based solutions. We describe one such protocol-based 410 mechanism, based on DHCP, but this does not imply a requirement for 411 devices. 413 We propose a new DHCP option that enumerates the valid local 414 emergency identifiers, as a list of "tel", "sip" or "sips" URIs. 415 These identifiers can be used by the UA to trigger special behavior 416 when the user dials those numbers, or they can identify a local PSTN 417 gateway that can provide local emergency service. A DHCP server 418 SHOULD advertise its local emergency number as well as those numbers 419 among the eight digit strings enumerated in Section 3.2 that do not 420 collide with local non-emergency services or extensions. 422 This DHCP option MUST NOT be used if DHCP does not announce the local 423 SIP server [6]. 425 Unlike an outbound proxy server, the DHCP server is very 426 likely to be located within the same country as the user 427 agent. However, since the user agent needs to perform the 428 call routing, it makes little sense to have the DHCP 429 information identify a set of numbers that mean nothing 430 special to the outbound proxy server. Thus, server 431 identification and emergency number identification belong 432 together. 434 If the local network supports the location of gateways via SLP [7], 435 the user agent can discover such gateways. The SLP service 436 description needs to be enhanced with a list of valid emergency 437 numbers. 439 Details are described in TBD. 441 [This is for discussion only and, if suitable, will move to a 442 different draft.] 444 10 Alternative Identifiers Considered 446 The "sos" SIP URI reserved user name proposed here follows the 447 convention of RFC 2142 [15] and the "postmaster" convention 448 documented in RFC 2822 [16]. One drawback is that it may conflict 449 with locally assigned addresses of the form "sos@somewhere". 451 There are a number of possible alternatives, each with their own set 452 of advantages and problems: 454 tel:sos This solution avoids name conflicts, but is not a valid 455 "tel" URI. It also only works if every outbound proxy knows 456 how to route requests to a proxy that can reach emergency 457 services. The SIP URI proposed here only requires a user's 458 home domain to be appropriately configured. 460 URI parameter: One could create a special URI, such as "aor- 461 domain;user=sos". This avoids the name conflict problem, 462 but requires mechanism-aware user agents that are capable 463 of emitting this special URI. 465 Special domain: A special domain, such as "sip:fire@sos.int" 466 could be used to identify emergency calls. This has similar 467 properties as the "tel:sos" URI, except that it is indeed a 468 valid URI. 470 11 IANA Considerations 472 Subaddresses of the "sos" address are registered with IANA This 473 specification establishes the "sos" subaddres sub-registry under 474 http://www.iana.org/assignments/sip-parameters. 476 Subaddresses are registered by the IANA when they are published in 477 standards track RFCs. The IANA Considerations section of the RFC must 478 include the following information, which appears in the IANA registry 479 along with the RFC number of the publication. 481 o Name of the subaddress. The name MAY be of any length, but 482 SHOULD be no more than twenty characters long. The name MUST 483 consist of alphanumeric characters only and is case- 484 insensitive. 486 o Descriptive text that describes the emergency service. 488 12 Security Considerations 490 The SIP specification [1] details a number of security 491 considerations. Security for emergency calls has conflicting goals, 492 namely to make it as easy and reliable as possible to reach emergency 493 services, while discouraging and possibly tracing prank calls. It 494 appears unlikely that classical authentication mechanisms can be 495 required by emergency call centers, but SIP proxy servers may be able 496 to add identifying information. 498 Given the sensitive nature of many emergency calls, it is desirable 499 to use the "sips" URI to ensure transport-level confidentiality and 500 integrity. However, this may cause the call to fail in some 501 environments. 503 Allowing the user agent to clearly and unambiguously identify 504 emergency calls makes it possible for the user agent to make 505 appropriate policy decisions. For example, a user agent policy may 506 reveal a different amount of information to the callee when making an 507 emergency call. Local laws may affect what information network 508 servers or service providers may be allowed or be required to release 509 to emergency call centers. They may also base their decision on the 510 user-declared destination of the call. 512 Outbound proxies may need to adjust their authentication requirements 513 for such emergency calls. 515 It is desirable to be able to verify that the call is reaching a true 516 emergency call center. The caller is unlikely to know or be able to 517 obtain the public key of the destination ECC since it does not even 518 know the ECC identity. The responding ECC could sign the response, 519 via standard SIP S/MIME mechanisms. However, the principal in the 520 certificate would appear as a random-looking domain name, such as 521 admin.fayette.co.ga.us, which cannot be reliably identified as an 522 ECC. Here, an attribute certificate (AC) [17] could be used to 523 associate the attribute "ECC" with the SIP URI. However, it appears 524 unlikely that such an Attribute Authority will emerge anytime soon, 525 particularly across national borders. Alternatively, ICANN could 526 create a new restricted top-level domain, such as .sos, that is open 527 only to accredited emergency response entities. Clearly, this is also 528 not likely in the short term. 530 The caller has little choice other than to trust the outbound proxy 531 server acting as an ERC or to act as its own ERC. In the former, more 532 likely case, the ERC will obtain the ECC identity from a database 533 source it trusts. The ERC then only has to ensure that the call 534 reaches the appropriate domain, which standard TLS server 535 authentication accomplishes, regardless of the domain name used by 536 the ECC and without the notion of attribute certificates. Since a 537 caller cannot assume that all ECCs will have valid ACs, the absence 538 of such a certificate is unlikely to cause the caller to abandon the 539 call in an emergency. Thus, the transitive trust model, which is 540 easier to implement, appears to be a more pragmatic approach. 542 13 Normative References 544 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. 545 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 546 initiation protocol," RFC 3261, Internet Engineering Task Force, June 547 2002. 549 [2] S. Bradner, "Key words for use in rfcs to indicate requirement 550 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 552 [3] A. Vaha-Sipila, "Urls for telephone calls," RFC 2806, Internet 553 Engineering Task Force, Apr. 2000. 555 [4] H. Schulzrinne and A. Vaha-Sipila, "The tel URI for telephone 556 calls," internet draft, Internet Engineering Task Force, Dec. 2002. 557 Work in progress. 559 [5] J. Rosenberg, H. F. Salama, and M. Squire, "Telephony routing 560 over IP (TRIP)," RFC 3219, Internet Engineering Task Force, Jan. 562 2002. 564 [6] H. Schulzrinne, "Dynamic host configuration protocol (dhcp-for- 565 ipv4) option for session initiation protocol (SIP) servers," RFC 566 3361, Internet Engineering Task Force, Aug. 2002. 568 [7] W. Zhao and H. Schulzrinne, "Locating ip-to-public switched 569 telephone network (PSTN) telephony gateways via SLP," internet draft, 570 Internet Engineering Task Force, Aug. 2002. Work in progress. 572 14 Informative References 574 [8] B. Campbell, J. Rosenberg, and H. Schulzrinne, eds., "Session 575 initiation protocol (SIP) extension for instant messaging," RFC 3428, 576 Internet Engineering Task Force, Dec. 2002. 578 [9] R. E. Droms, "Dynamic host configuration protocol," RFC 2131, 579 Internet Engineering Task Force, Mar. 1997. 581 [10] J. Polk et al., "DHCP option for geographic location," internet 582 draft, Internet Engineering Task Force, Oct. 2002. Work in progress. 584 [11] H. Schulzrinne, "DHCP option for civil location," internet 585 draft, Internet Engineering Task Force, Dec. 2002. Work in progress. 587 [12] M. Patrick, "DHCP relay agent information option," RFC 3046, 588 Internet Engineering Task Force, Jan. 2001. 590 [13] J. Polk et al., "Semantics for DHC location object within 591 GEOPRIV," internet draft, Internet Engineering Task Force, Oct. 592 2002. Work in progress. 594 [14] M. Garcia, E. Henrikson, and D. L. Mills, "Private extensions 595 (p-header) extensions to the session initiation protocol (SIP) for 596 the 3rd-generation partnership project (3GPP)," internet draft, 597 Internet Engineering Task Force, Nov. 2002. Work in progress. 599 [15] D. H. Crocker, "Mailbox names for common services, roles and 600 functions," RFC 2142, Internet Engineering Task Force, May 1997. 602 [16] P. Resnick, ed., "Internet message format," RFC 2822, Internet 603 Engineering Task Force, Apr. 2001. 605 [17] S. Farrell and R. Housley, "An Internet attribute certificate 606 profile for authorization," RFC 3281, Internet Engineering Task 607 Force, Apr. 2002. 609 15 Change History 610 15.1 Changes since -03 612 o Added description of local discovery mechanism for finding a 613 local gateway. 615 o Noted that 'sos' is case-insensitive and only applies to SIP 616 URIs, not other URIs. 618 o Described the ECC verification options available to a caller. 620 o Added local gateway discovery. 622 o Added outline of how to use DHCP for configuring additional 623 local emergency numbers. 625 o Added 3GPP emergency numbers beyond 112 and 911. 627 16 Acknowledgements 629 Andrew Allen, Keith Drage, Mike Pierce, James Polk, Brian Rosen and 630 John Schnizlein contributed helpful comments. 632 17 Authors' Addresses 634 Henning Schulzrinne 635 Dept. of Computer Science 636 Columbia University 637 1214 Amsterdam Avenue 638 New York, NY 10027 639 USA 640 electronic mail: schulzrinne@cs.columbia.edu