idnits 2.17.1 draft-rosen-sos-phonebcp-01.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 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 585. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 591. ** 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. 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.) 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 (June 25, 2006) is 6487 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) == Missing Reference: 'AND L7' is mentioned on line 197, but not defined == Unused Reference: 'I-D.ietf-geopriv-pdif-lo-profile' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-location-conveyance' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sipping-toip' is defined on line 497, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 538, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-00 == Outdated reference: A later version (-14) exists of draft-ietf-geopriv-pdif-lo-profile-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-09 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sip-location-conveyance' == Outdated reference: A later version (-09) exists of draft-ietf-sipping-toip-04 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-toip (ref. 'I-D.ietf-sipping-toip') -- Possible downref: Normative reference to a draft: ref. 'I-D.schulzrinne-geopriv-dhcp-civil' -- Possible downref: Normative reference to a draft: ref. 'I-D.schulzrinne-sipping-service' ** Downref: Normative reference to an Informational RFC: RFC 3325 ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) ** Downref: Normative reference to an Informational RFC: RFC 4190 ** Downref: Normative reference to an Informational RFC: RFC 4504 Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ecrit B. Rosen 3 Internet-Draft NeuStar 4 Expires: December 27, 2006 J. Polk 5 Cisco Systems 6 June 25, 2006 8 Best Current Practice for Communications Services in support of 9 Emergency Calling 10 draft-rosen-sos-phonebcp-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 22 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 December 27, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Requesting help in an emergency using a communications device such as 44 a telephone or mobile is an accepted practice in most of the world. 45 As communications devices increasingly utilize the Internet to 46 interconnect and communicate, users will continue to expect to use 47 such devices to request help, regardless of whether or not they 48 communicate using IP. The emergency response community will have to 49 upgrade their facilities to support the wider range of communications 50 services, but cannot be expected to handle wide variation in device 51 and service capability. The IETF has several efforts targeted at 52 standardizing various aspects of placing emergency calls. This memo 53 describes best current practice on how devices and services should 54 use such standards to reliably make emergency calls 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Which devices and services should support emergency calls . . 4 61 4. Determining Location . . . . . . . . . . . . . . . . . . . . . 4 62 5. Determining an emergency call . . . . . . . . . . . . . . . . 6 63 6. Session Signaling . . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. SIP signaling requirements for User Agents . . . . . . . . 8 65 6.2. Mapping from Location to a PSAP URI . . . . . . . . . . . 9 66 6.3. Routing the call . . . . . . . . . . . . . . . . . . . . . 9 67 6.4. Responding to PSAP signaling . . . . . . . . . . . . . . . 10 68 6.5. Disabling of features . . . . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . . . . 14 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 In this memo, an emergency call refers to a communications session 83 established by a user to a "Public Safety Answering Point" (PSAP) 84 which is a call center established by response agencies to accept 85 emergency calls. We differentiate such calls from other sessions 86 which are created by responders using public communications 87 infrastructure often involving some kind of priority access as 88 defined in Emergency Telecommunications Service (ETS) in IP Telephony 89 [RFC4190]. While current PSAPs are limited to voice sessions, often 90 with the additional capability to serve hearing impaired users with 91 text based "TTY" devices, envisioned upgrades to PSAPs will allow 92 sessions with audio, video, and several kinds of text including 93 interactive text [RFC4103] and Instant Messages. and [I-D.ietf- 94 sipping-toip] 96 Making an emergency call involves the use of location information, 97 referring to the physical location of the caller. Location is used 98 within the emergency calling system to route a call to the correct 99 PSAP, as well as by the PSAP to choose the correct responder, and 100 direct them to the person in need of assistance. 102 The steps involved in an emergency call from an IP based device are 103 (with a rough ordering of operation) 104 1. Device connects to access network, and obtains initial location 105 2. User dials visited location's emergency number 106 3. User device identifies call as emergency call 107 4. User device includes location indication (by value or by 108 reference) in the call set-up messaging 109 5. emergency call set-up is routed to appropriate PSAP based on 110 location of the caller 111 6. call is established with PSAP 112 7. caller's location is presented to PSAP operator for dispatch 114 As a quick overview for a typical Ethernet connected telephone using 115 SIP signaling: 116 o the phone "boots" and connects to its access network 117 o the phone would get location from the DHCP server [or an L7 118 server]. 120 o It would use "urn:service:sos" as the URI of an emergency call. 121 o It would put its location in the SIP INVITE as a PIDF-LO in the 122 body of the INVITE (or a reference to location in a Location 123 header) and forward the call to its first hop proxy. 124 o The proxy recognize the call as an emergency call. 125 o The proxy would determine the PSAP's URI by using the [I-D.ietf- 126 ecrit-lost] mapping server from the location provided in the 127 signaling 128 o The proxy would use a SIP SRV record in the domain of the 129 resulting PSAP URI to determine where to send the call. 131 The (upgraded) PSAP would answer the call as SIP, with location 132 included. 134 [RFC4504] details Best Current Practice for SIP user agents. This 135 memo can be considered an addition to it for endpoints. 137 3. Which devices and services should support emergency calls 139 Although present PSAPs have only support for voice calls placed 140 through PSTN facilities or systems connected to the PSTN, future 141 PSAPs will support Internet connectivity and a wider range of media 142 types. In general, if a user could reasonably expect to be able to 143 call for help with the device, then the device or service should 144 support emergency calling. Certainly, any device or service that 145 looks like and works like a telephone (wired or mobile) should 146 support emergency calling, but increasingly, users have expectations 147 that other devices and services should work. 149 Using current (evolving) standards, devices that create media 150 sessions and exchange audio, video and/or text, and have the 151 capability to establish sessions to a wide variety of addresses, and 152 communicate over private IP networks or the Internet, should support 153 emergency calls. 155 4. Determining Location 157 With Internet based communications services, determining where the 158 caller is located is more problematic than in PSTN and mobile 159 systems. Existing wired phones are tethered with a wire that is 160 connected directly to a call control device, a circuit switch. 161 Cellular phones are tethered via a radio channel to a cell tower, 162 which connects that cell phone to a circuit switch. The primary 163 difficulty with IP based phones is that the connectivity, whether 164 wired or radio channel, is decoupled from the call control device. 165 The communications service may not have any relationship with the 166 access network carrier, and, with NAT and VPN tunnels, may have no 167 way to even find out who the access carrier is. 169 For this reason, standards have been created for endpoints (devices) 170 to obtain location information. The endpoint is a subscriber to both 171 the access network and the communications service, and thus is in a 172 position to obtain its location from the access network, and supply 173 it to the communications service. 175 DHCP [RFC2131] has been enhanced to provide the location of a device. 176 [RFC3825] describes how a geo-location (lat/lon/alt) may be obtained 177 and [I-D.schulzrinne-geopriv-dhcp-civil] describes how a civic 178 (street address) location can be obtained via DHCP. 180 [Placeholder for HELD, LCP or other L7 location determination 181 methods] 183 For devices that operate on a network where the network operator 184 controls the specification of every device connected to that network 185 that could be used for emergency calls, the method by which location 186 is determined need not be an IETF standard, but can be any method 187 that achieves the desired result. Such a method MUST be specified, 188 and every device MUST support it. 190 For devices that operate in a network where the network operator 191 controls the specification of every device connected to that network, 192 but the network attachment supports upstream networks to which 193 communications devices are connected (such as any network that 194 supports Ethernet connected telephones and terminal adapters), the 195 method by which location is determined need not be an IETF standard, 196 but can be any method which achieves the desired result. However, 197 the network attachment MUST support [both] DHCP [AND L7] for upstream 198 communications devices to obtain location. For smaller interior 199 (e.g, LAN) networks, the DHCP [or L7] server should simply repeat the 200 location obtained from the access network. For larger networks, 201 other mechanisms, such as a DHCP Relay Agent [RFC3046] MUST be used 202 to provide more accurate location of endpoints. 204 For devices that operate on a network where the network operator does 205 not control the specification of every device connected to the 206 network, DHCP [or L7] MUST be supported on the network. 208 Note: Self Reported location is generally unacceptable in emergency 209 calls, although it is being used prior to automatic location 210 determination schemes being fielded. Local laws may govern what is 211 acceptable in any country or area. 213 Devices SHOULD get location immediately after obtaining local network 214 configuration information. It is essential for the location to be 215 determined BEFORE any VPN tunnels are established. It is equally 216 essential that this location information is *not* overwritten by any 217 process engaged from establishing a VPN connection. In other words, 218 the established VPN to Chicago from the device in Dallas should not 219 overwrite the location of "Dallas". 221 It is desirable that location information be periodically refreshed. 222 For devices which are not expected to roam, refreshing on the order 223 of once per day is recommended. For devices which roam, refresh of 224 location should be more frequent, with the frequency related to the 225 mobility of the device and the ability of the access network to 226 support the refresh operation. There can be instances in which a 227 device is aware of when it moves, for example when it changes access 228 points. When this type of event occurs, the device SHOULD refresh 229 its location. 231 It is desirable for location information to be requested immediately 232 before placing an emergency call. However, if there is any delay in 233 getting more recent location, the call SHOULD be placed with the most 234 recent location information the device has. It is recommended that 235 the device not wait longer than 500 ms to obtain updated location, 236 and systems should be designed such that the typical response is 237 under 100ms. These numbers are empiracilly derived, but are intended 238 to keep total call signaling time below 2 seconds. There are 239 conflicts between the time it takes to generate location when 240 measuring techniques are used and the desire to route the call 241 quickly. If an accurate location cannot be determined quickly, a 242 rough location SHOULD be returned within 500ms which can be used to 243 route the call. 245 5. Determining an emergency call 247 An emergency call is distinguished by the device (or a downstream 248 element) by an "address", which in most cases for Internet connected 249 devices is still a dialstring, although other user interfaces may be 250 used. 252 Note: It is undesirable to have a single "button" emergency call user 253 interface element. These mechanisms have a very high false call 254 rate. PSAPs prefer devices to use their local emergency call 255 dialstring. 257 While in some countries there is a single 3 digit dialstring that is 258 used for all emergency calls (i.e. 911 in North America), in some 259 countries there are several 3 digit numbers used for different types 260 of calls. For example, in Switzerland, 117 is used to call police, 261 118 is used to call the fire brigade, and 144 is used for emergency 262 medical assistance. In other countries, there are no "short codes" 263 or "service codes" for 3 digit dialing of emergency services and 264 local (PSTN) numbers are used. 266 [I-D.schulzrinne-sipping-service] introduces a universal emergency 267 service URN scheme. On the wire, emergency calls SHOULD include this 268 type of URI (in for example, the To: field of a SIP call). The 269 scheme includes a single emergency URN (urn:service:sos) and 270 responder specific ones (urn:service:sos.police). Using the service 271 sos URN scheme, emergency calls can be recognized as such throughout 272 the Internet. 274 Devices MUST use the service:sos URN scheme to mark emergency calls. 276 To determine which calls are emergency calls, some entity needs to 277 map a user entered dialstring into this URN scheme. A user may 278 "dial" 1-1-2, but the call would be sent to urn:service:sos. This 279 mapping is ideally performed at the endpoint device, but may be 280 performed at an intermediate entity (such as a SIP proxy server). 282 Note: It is strongly RECOMMENDED that devices recognize the emergency 283 dialstring(s) and map to the universal emergency URN. If devices 284 cannot do "dial plan interpretation", then the first signaling aware 285 element (first hop proxy in SIP signaled devices) SHOULD do the 286 mapping. It is important to not require a large number of active 287 elements handle a call before it is recognized as an emergency call 289 In systems that support roaming, there may be a concept of "visited" 290 and "home" networks. Even when there is not a "visited network", the 291 user may be roaming (or nomadic) in a different country from their 292 home. This gives rise to the problem of which dialstring(s) to 293 recognize, the "home" or "visited"? While it is desirable that the 294 "home" dialstrings be recognized, it is required (by law in some 295 countries) that the "visited" dialstrings be recognized. Dial plan 296 interpretation may need to take "visited" emergency dialstrings into 297 account. 299 To give an example of this difference in dialstrings: If the device 300 is from North America, the home and visited emergency dialstring is 301 "9-1-1". If that devices roams to the UK, the home emergency 302 dialstring is still "9-1-1", but the visited emergency dialstring 303 would become "9-9-9". If the device roams to Paris, the home 304 dialstring remains the same, "9-1-1", but the visited dialstring 305 changes from 999 to "1-1-2". 307 The home emergency dialstrings MAY be provisioned into the device (or 308 other element doing dialstring to universal emergency call URN 309 mapping). The visited dialstring MAY be discovered by a lower layer 310 protocol that is used by the access network, such as DHCP, or with a 311 higher layer protocol like SIP (using a REGISTER Request) or HTTP 312 (using a GET Request) once the device learns its location. It could 313 be that the device knows more than one way to learn the visited 314 emergency dialstring, and using the methods in some configured order 315 (until an answer is received). 317 6. Session Signaling 319 SIP signaling [RFC3261] is expected be supported by upgraded PSAPs. 320 Gateways MAY be used between Internet connected devices and older 321 PSAPs. Some countries may support other signaling protocols into 322 PSAPs. 324 6.1. SIP signaling requirements for User Agents 326 Initial signaling Method is INVITE. The Request-URI MUST be a 327 service:sos URN unless the device does not do emergency dialstring 328 interpretation. If the device does not do emergency dialstring 329 interpretation, the expectation is that the Request-URI will be a tel 330 URI with the dialed digits, or a sips uri with the dialed digits and 331 a USER=PHONE parameter (e.g. sips:911@example.com;user=phone). The 332 call would normally be sent to the first hop proxy of the 333 communications service. 334 1. The To: header MUST be present and SHOULD be the same as the 335 Request-URI 336 2. The From: header MUST be present and SHOULD be the AoR of the 337 caller. NOTE: unintialized devices may 338 not have an AoR available 339 3. A Via: header MUST be present and SHOULD include the URI of the 340 device 341 4. A Route header MAY be present if the device has performed a 342 fallback mapping function (see Section 4) 343 5. Either a P-Asserted-Identity [RFC3325] or an Identity header 344 [I-D.ietf-sip-identity], or both, SHOULD be included to identify 345 the sender. 346 6. A Contact header SHOULD be present (which might contain a GRUU 347 [I-D.ietf-sip-gruu]) to permit an immediate call-back to the 348 specific device which placed the emergency call. 349 7. Other headers MAY be included as per normal sip behavior 350 8. A Supported: header MUST be included with the 'location' option 351 tag, unless the device does not understand the concept of SIP 352 Location ; 353 9. If the device's location is by-reference, a Location: header 354 MUST be present containing the URI of the PIDF-LO reference for 355 that device; 357 10. if a device understands the SIP Location Conveyance [I-D.ietf- 358 sip-location-conveyance] extension and has its location 359 available, it MUST include location either by-value or by- 360 reference. If it is by-value, the INVITE contains a Supported 361 header with a "location" option tag, and a "cidURL" indicating 362 which message body part contains the PIDF-LO. If the INVITE 363 contains a location by-reference, it includes the same Supported 364 header with the "location" option tag, and includes the URI of 365 the PIDF-LO on a remote node in a Location header. [I-D.ietf- 366 geopriv-pdif-lo-profile] MUST be used 367 11. If a device understand the SIP Location Conveyance extension and 368 has its location unavailable or unknown to that device, it MUST 369 include a Supported header with a "location" option tag, and not 370 include a Location header, and not include a PIDF-LO message 371 body.; 372 12. A normal SDP offer SHOULD be included in the INVITE. The offer 373 SHOULD NOT include compressed audio codecs, although a wideband 374 codec offer MAY be included. 376 Note: Silence suppression (Voice Activity Detection methods) MUST NOT 377 be used on emergency calls. PSAP call takers sometimes get 378 information on what is happening in the background to determine how 379 to process the call. 381 6.2. Mapping from Location to a PSAP URI 383 To route an emergency call, we make use of the [I-D.ietf-ecrit-lost] 384 mapping service which takes a location expressed by a PIDF-LO and 385 returns one or more PSAP URIs. The request includes the service URN 386 which is used to determine which entity should receive the call. The 387 URI would replace the Request-URI in a SIP INVITE. 389 User agents that can obtain location information MUST perform the 390 mapping from location information to PSAP URI using [I-D.ietf-ecrit- 391 lost]. The mapping is performed whenever the UA acquires new 392 location information that is outside the bounds of the current PSAP 393 coverage region specified in the LoST response or the time-to-live 394 value of that response has expired. 396 To deal with old user agents that predate this specification and with 397 UAs that do not have access to their own location data, proxies that 398 recognize a call as an emergency call that is not marked as such (see 399 Section 5) or where the Request-URI is a service:sos URN MUST also 400 perform this mapping. 402 6.3. Routing the call 404 Normal routing mechanisms for the specified URI should be used. For 405 SIP signaled devices, the domain of the URI should be extracted, and 406 the DNS consulted for a sip (or sips) SRV. The resulting NAPTR, if 407 present, should be used for the FQDN of the server. 409 6.4. Responding to PSAP signaling 411 The PSAP is expected to use normal signaling (e.g. SIP) as per IETF 412 standards. Devices and proxies should expect to: 413 1. Be REFERed to a conference bridge; PSAPs often include 414 dispatchers, responders or specialists on a call. 415 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are 416 not located in the primary PSAP. The call may have to be 417 transferred to another PSAP. Most often this will be an attended 418 transfer, or a bridged transfer. 419 3. (For devices that are Mobile) SUBSCRIBE to the Presence of the 420 AoR (or equivalent for other signaling schemes) to get location 421 updates. 422 4. Support Session Timer (or equivalent) to guard against session 423 corruption 425 Devices MUST NOT send a BYE (or equivalent for other non-SIP 426 signaling). The PSAP must be the only entity that can terminate a 427 call. If the user "hangs up" an emergency call, the device should 428 ring, and when answered, reconnect the caller to the PSAP. 430 There can be a case where the session signaling path is lost, and the 431 user agent does not receive the BYE. If the call is hung up, the 432 session timer expires, and 5 minutes elapses from the last message 433 received by the device from the PSAP, the call may be declared lost. 434 If in the 5 minute interval an incoming call is received from the 435 domain of the PSAP, the device should drop the old call and alert for 436 the (new) incoming call. 438 6.5. Disabling of features 440 The device and/or service should disable outgoing call features such 441 as: 442 o Call Waiting 443 o Call Transfer 444 o Three Way Call 445 o Flash hold 446 o Outbound Call Blocking 448 The emergency dialstrings SHOULD NOT be permitted in Call Forward 449 numbers or speed dial lists. 451 The device and/or service SHOULD disable the following incoming call 452 features on calls from the PSAP: 454 o Call Waiting (all kinds) 455 o Do Not Disturb 456 o Call Forward (all kinds) (if the PSAP calls back within some 457 (30min?) interval) 459 7. Security Considerations 461 There are no new security considerations beyond those in the 462 normative references. This memo does not introduce any new 463 protocols; it specifies use of several of them. Implementers are 464 admonished to ,,, 466 8. Normative References 468 [I-D.ietf-ecrit-lost] 469 Hardie, T., "LoST: A Location-to-Service Translation 470 Protocol", draft-ietf-ecrit-lost-00 (work in progress), 471 June 2006. 473 [I-D.ietf-geopriv-pdif-lo-profile] 474 Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, 475 Considerations and Recommendations", 476 draft-ietf-geopriv-pdif-lo-profile-04 (work in progress), 477 May 2006. 479 [I-D.ietf-sip-gruu] 480 Rosenberg, J., "Obtaining and Using Globally Routable User 481 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 482 (SIP)", draft-ietf-sip-gruu-09 (work in progress), 483 June 2006. 485 [I-D.ietf-sip-identity] 486 Peterson, J. and C. Jennings, "Enhancements for 487 Authenticated Identity Management in the Session 488 Initiation Protocol (SIP)", draft-ietf-sip-identity-06 489 (work in progress), October 2005. 491 [I-D.ietf-sip-location-conveyance] 492 Polk, J. and B. Rosen, "Session Initiation Protocol 493 Location Conveyance", 494 draft-ietf-sip-location-conveyance-02 (work in progress), 495 March 2006. 497 [I-D.ietf-sipping-toip] 498 Wijk, A., "Framework for real-time text over IP using 499 SIP", draft-ietf-sipping-toip-04 (work in progress), 500 March 2006. 502 [I-D.schulzrinne-geopriv-dhcp-civil] 503 Schulzrinne, H., "DHCP Option for Civil Location", 504 draft-schulzrinne-geopriv-dhcp-civil-01 (work in 505 progress), February 2003. 507 [I-D.schulzrinne-sipping-service] 508 Schulzrinne, H., "A Uniform Resource Name (URN) for 509 Services", draft-schulzrinne-sipping-service-01 (work in 510 progress), October 2005. 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 515 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 516 RFC 2131, March 1997. 518 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 519 RFC 3046, January 2001. 521 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 522 A., Peterson, J., Sparks, R., Handley, M., and E. 523 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 524 June 2002. 526 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 527 Extensions to the Session Initiation Protocol (SIP) for 528 Asserted Identity within Trusted Networks", RFC 3325, 529 November 2002. 531 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 532 Configuration Protocol Option for Coordinate-based 533 Location Configuration Information", RFC 3825, July 2004. 535 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 536 Conversation", RFC 4103, June 2005. 538 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 539 Format", RFC 4119, December 2005. 541 [RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for 542 Supporting Emergency Telecommunications Service (ETS) in 543 IP Telephony", RFC 4190, November 2005. 545 [RFC4504] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony 546 Device Requirements and Configuration", RFC 4504, 547 May 2006. 549 Authors' Addresses 551 Brian Rosen 552 NeuStar 553 470 Conrad Dr. 554 Mars, PA 16046 555 US 557 Phone: +1 724 382 1051 558 Email: br@brianrosen.net 560 James M. Polk 561 Cisco Systems 562 3913 Treemont Circle 563 Colleyville, TX 76034 564 US 566 Phone: +1-817-271-3552 567 Email: jmpolk@cisco.com 569 Intellectual Property Statement 571 The IETF takes no position regarding the validity or scope of any 572 Intellectual Property Rights or other rights that might be claimed to 573 pertain to the implementation or use of the technology described in 574 this document or the extent to which any license under such rights 575 might or might not be available; nor does it represent that it has 576 made any independent effort to identify any such rights. Information 577 on the procedures with respect to rights in RFC documents can be 578 found in BCP 78 and BCP 79. 580 Copies of IPR disclosures made to the IETF Secretariat and any 581 assurances of licenses to be made available, or the result of an 582 attempt made to obtain a general license or permission for the use of 583 such proprietary rights by implementers or users of this 584 specification can be obtained from the IETF on-line IPR repository at 585 http://www.ietf.org/ipr. 587 The IETF invites any interested party to bring to its attention any 588 copyrights, patents or patent applications, or other proprietary 589 rights that may cover technology that may be required to implement 590 this standard. Please address the information to the IETF at 591 ietf-ipr@ietf.org. 593 Disclaimer of Validity 595 This document and the information contained herein are provided on an 596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 598 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 599 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 600 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 603 Copyright Statement 605 Copyright (C) The Internet Society (2006). This document is subject 606 to the rights, licenses and restrictions contained in BCP 78, and 607 except as set forth therein, the authors retain all their rights. 609 Acknowledgment 611 Funding for the RFC Editor function is currently provided by the 612 Internet Society.