idnits 2.17.00 (12 Aug 2021) /tmp/idnits58416/draft-winterbottom-ecrit-direct-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 583 has weird spacing: '...ects in emerg...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 26, 2009) is 4589 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 479, but not defined == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-geopriv-held-identity-extensions has been published as RFC 6155 == Outdated reference: draft-ietf-sip-outbound has been published as RFC 5626 == Outdated reference: draft-ietf-sipcore-location-conveyance has been published as RFC 6442 == Outdated reference: A later version (-03) exists of draft-schulzrinne-ecrit-psap-callback-01 ** Downref: Normative reference to an Informational draft: draft-schulzrinne-ecrit-psap-callback (ref. 'I-D.schulzrinne-ecrit-psap-callback') == Outdated reference: A later version (-04) exists of draft-thomson-geopriv-res-gw-lis-discovery-02 ** Downref: Normative reference to an Informational draft: draft-thomson-geopriv-res-gw-lis-discovery (ref. 'I-D.thomson-geopriv-res-gw-lis-discovery') == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: draft-ietf-ecrit-lost-servicelistboundary has been published as RFC 6197 == Outdated reference: A later version (-11) exists of draft-patel-ecrit-sos-parameter-06 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT J. Winterbottom 3 Internet-Draft M. Thomson 4 Intended status: BCP Andrew Corporation 5 Expires: April 29, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 H. Schulzrinne 8 Columbia University 9 October 26, 2009 11 ECRIT Direct Emergency Calling 12 draft-winterbottom-ecrit-direct-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and 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 April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The specified IETF emergency services architecture puts a strong 51 emphasis on emergency call and emergency messaging via the Voice 52 Service Provider (VSP) / Application Service Provider (ASP). There 53 are two reasons for this design decision: The call routing via the 54 VSP/ASP is more natural as it follows the standard communication 55 pattern and transition deployments assume non-updated end hosts. 57 As the deployment of the Location-to-Service Translation protocol 58 progresses there are possibilities for upgraded end devices to 59 directly communicate with the IP-based emergency services network 60 without the need to interact with a VSP/ASP, which simplifies the 61 task of regulators as the involved parties are within the same 62 jurisdiction. 64 This memo describes the procedures and operations of a generic 65 emergency calling client utilizing the available building blocks. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. The Jurisdictional Problem . . . . . . . . . . . . . . . . . . 7 72 4. ESRP Route Determination . . . . . . . . . . . . . . . . . . . 8 73 5. Emergency Client Registration . . . . . . . . . . . . . . . . 9 74 6. Emergency Client Call Intitiation . . . . . . . . . . . . . . 13 75 7. Call Termination Control . . . . . . . . . . . . . . . . . . . 14 76 8. SIP Feature Restrictions . . . . . . . . . . . . . . . . . . . 15 77 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 9.1. Test Registration . . . . . . . . . . . . . . . . . . . . 16 79 9.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . . . 17 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 86 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 The description of the IETF emergency services architecture, found in 92 [I-D.ietf-ecrit-phonebcp] and in [I-D.ietf-ecrit-framework], focuses 93 on devices where emergency calls are routed primarily through the 94 subscriber's home VSP and the direct signaling communication between 95 the end host and the Public Safety Answering Point (PSAP) that 96 contains the IP-based PSAP is only an exception. This is a 97 convenient assumption if one considers the regular communication 98 patterns of the device and the potential proprietary protocol 99 implementations used between the end host and the VSP and the ability 100 to move the interoperability challenges away from the end device and 101 closer to VSPs. There are, however, challenges for regulators to 102 enforce emergency services functionality when the VSP is located in a 103 different jurisdiction. Inclusion of a VSP introduces unnecessary 104 elements into the emergency call path making the overall solution 105 more cumbersome. 107 With the help of the Location-to-Service Translation protocol a PSAP 108 URI is discovered that allows the end device to directly send SIP 109 communication requests towards the PSAP. 111 Note that the information returned by LoST may not necessarily be the 112 address of the PSAP itself but might rather be an entity that gets 113 the emergency call closer to the PSAP by returning the address of an 114 Emergency Services Routing Proxy (ESRP). 116 The intent of this client is that it will be able to use the 117 available ECRIT building blocks to allow any IP enabled device with 118 access to the Internet to make an emergency call without requiring 119 the signaling interaction with the VSP. In fact, there is no 120 assumption or requirement for a VSP subscription to exist. The 121 interacting entities are shown in Figure 1. 123 .... .... 124 ,' ',' ', 125 ; ; 126 +--------+ ; ; +------+ 127 | Device |--->: ISP :----->| ESRP | 128 +--------+ ; ; +------+ 129 `, ,', ,' 130 , , , , 131 ```` ```` 133 Figure 1: Network Configuration 135 Furthermore, a means for call-back in the event of a dropped call is 136 also described. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. The Jurisdictional Problem 146 The jurisdictional problem is illustrated with Figure 2 that 147 highlights that provided the data in the Location Information Server 148 (LIS) and the LoST server are correct, that the caller and the PSAP 149 are assured of being in the same regulatory jurisdiction. This is 150 important, because it shows that it is the access component of the 151 network and not the service component against which reguatory 152 obligations can be imposed with any hope of enforcement. Regulation 153 without the possibility of enforcement is challenging as there is 154 very little coordination between regulators world wide in this area, 155 consequently any emergency calling procedure should ensure that all 156 nodes against which the procedures apply fall within the same 157 regulatory boundary. 159 +-----+ 160 | VSP | 161 | # | 162 +-----+ 164 o-------------o----------------------o-------------o 165 / \ 166 / +---------+ +--------+ \ 167 / | Access \ / ESINet \ \ 168 o | Network \ / \ o 169 | + + + O + | 170 | / O | / interaction to learn 201 about the available emergency services (potentially using the 202 serviceListBoundary extension defined in 203 [I-D.ietf-ecrit-lost-servicelistboundary]). The service options may 204 be presented to the emergency caller in a graphical fashion and once 205 a specific service is selected a LoST query would be initiated 206 (unless a cached mapping is available that makes this request 207 obsolete). The LoST query to obtain the ESRP URI for 208 the selected service is in this example initiated at the time the 209 emergency call setup is performed. It is recommended that ESRP 210 discovery occurs at call time. 212 5. Emergency Client Registration 214 Emergency registration is only necessary when an emergency call 215 procedure is initiated. Immediately prior to making an emergency 216 call, the emergency client performs a SIP emergency registration with 217 the registrar in the ESRP, the ESRP-registrar. The emergency 218 registration is a SIP registration with specific options and headers 219 which are required in order to guard the emergency network and ensure 220 callback should it be required. 222 Each emergency client MUST provide an instance-id, as defined in 223 [I-D.ietf-sip-outbound], this allows the ESRP-registrar to generate a 224 GRUU [RFC5627] that can be used as a callback identifier. A GRUU is 225 necessary as the callback identifier because the emergency client 226 does not provide a longer-term contact address to the ESRP-registrar 227 prior to registration, and the GRUU provides a handle by which the 228 PSAP can identify the calling emergency client. To simplify the 229 emergency client and ESRP-registrar implementations, only public 230 GRUUs are provided by the ESRP-registrar. The public GRUU is 231 guaranteed to be the same for a device regardless of re-registration 232 with a different call-id, which may occur if the device unexpectedly 233 reboots. This is not true for temporary GRUUs, which makes temporary 234 GRUUs undesriable in the scope of this application space. 236 The PSAP is able to define and mandate the time over which callback 237 is possible. This needs to be a reasonable period of time, nominally 238 10s of minutes, as the device may well be transient with regards to 239 network attachment. The ESRP-registrar reflects the regulatory 240 callback period in the expiry value of emergency registration 241 responses. Emergency clients claiming compliance to this 242 specification MUST honour the value in the registration response from 243 the ESRP-registrar, up to a maximum of 60 minutes. An emergency 244 client SHOULD respect a registration expiry of longer than 60 245 minutes, but MAY terminate its registration with and ESRP-registrar 246 at 60 minutes if the expiry value provided by the ESRP-registrar was 247 longer. 249 In the event that a registration is lost by the emergency client 250 prior to reaching registration expiry then the emergency client MUST 251 re-register with the ESRP-registrar and SHOULD use the same call-id. 252 In this circumstance the ESRP-registrar SHOULD match the instance-id 253 and the call-id to recognize that it is a re-registration for a 254 dropped connection, and expiry time in the registration response 255 SHOULD be set to the time remaining when the original registration 256 occurred. 258 [I-D.ietf-sip-outbound] requires a device to support at least 2 259 registrations to different proxies. The emergency client 260 requirements in this memo relax this requirement down to one 261 registration, but more than one is allowed. There are several 262 reasons for relaxing the connection redundancy requirement. Firstly, 263 ESRPs are expected to have inbuilt redundancy, so if a connection is 264 dropped due to a failed proxy in the ESRP, then a new connection or 265 registration will automatically be directed to an active proxy in the 266 ESRP cluster. If the connection dropped because of some other 267 failure along the path from the emergency client to the ESRP, then 268 multiple SIP registrations are unlikely to provide any measurable 269 reliability improvements since single points of failure in this path 270 are inherently likely. Secondly, re-registrations only occur 271 immediately prior to call placement, so any outbound failure will 272 also likely result in the call dropping. If this occurs then the 273 emergency client MUST re-register with the ESRP-registrar, and since 274 instance-id and public GRUU will remain unchanged as a result of 275 this, the emergency client can either receive a callback from the 276 PSAP, or it can initiate a new call to the emergency network. 278 Location information is critical to emergency calling. Providing 279 location information to the calling-entity with sufficient 280 granularity to allow ESRP route determination is crucial. Since this 281 must occur prior to the emergency client registering with the ESRP- 282 registrar, the emergency client must have access to a certain amount 283 of location information (and the amount varies depending on the 284 specific emergency services deployment architecture). 286 The device SHOULD include all the location information it has when 287 registering with the ERSP-registrar. Inclusion of location 288 information in SIP REGISTER messages is specified in 289 [I-D.ietf-sipcore-location-conveyance]. There are three possible 290 execution paths for the ESRP-registrar when receiving a REGISTER 291 message: 293 1. If the REGISTER message does not include location information the 294 ESRP-registrar MUST use HELD identity 295 [I-D.ietf-geopriv-held-identity-extensions] to obtain the 296 location of the device as both a location value and reference. 297 In order to contact the LIS the ESRP-registrar SHOULD determine 298 the LIS address using the mechanism described in 299 [I-D.thomson-geopriv-res-gw-lis-discovery]. The ESRP-registrar 300 MAY use other methods for LIS determination where available. 302 2. If the REGISTER message contains a location URI then the ESRP- 303 registrar MUST dereference it so that it has a location available 304 to route the impending emergency call. The ESRP-registrar MAY 305 validate the LIS address in the location URI with that of the LIS 306 serving the network from which the REGISTER message originated. 308 3. The REGISTER message contains location information by value. Any 309 actions performed by the ESRP-registrar to valid this information 310 are specific to the jurisdiction in which the ESRP operates and 311 are out of the scope of this document. 313 Where location conveyance is used confidentiality protection SHOULD 314 be provided using Transport Layer Security (TLS). 316 Figure 3 show the registration message exchange graphically. 318 +--------+ +-----+ +------+ +------+ 319 | Device | | LIS | | LoST | | ESRP | 320 +--------+ +-----+ +------+ +------+ 321 | | | | 322 +<----LIS Discovery---->+ | | 323 | | | | 324 +----locationRequest--->+ | | 325 | | | | 326 +<---locationResponse---| | | 327 | | | | 328 +------------------findService------------->+ | 329 | | | | 330 +<--------------findServiceResponse---------+ | 331 | | | | 332 +------------------------REGISTER------------------------>+ 333 | | | | 334 | +<------locationRequest-----------+ 335 | | | | 336 | +-------locationResponse--------->+ 337 | | | | 338 +<-------------------------200 OK ------------------------+ 339 | | | | 341 Figure 3: Example Registration Message Flow 343 REGISTER sip:sos.example.com SIP/2.0 344 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7 345 Max-Forwards: 70 346 From: anon ;tag=7F94778B653B 347 To: anon 348 Call-ID: 16CB75F21C70 349 CSeq: 1 REGISTER 350 Geolocation: 351 ;inserted-by="anon@192.0.2.2" 352 ;routing-allowed=yes 353 Geolocation: 354 ;inserted-by="anon@192.0.2.2" 355 ;routing-allowed=no 356 Require: gruu, geolocation 357 Supported: outbound, gruu 358 Contact: 359 ;+sip.instance="" 360 Content-Type: multipart/mixed; boundary=boundary1 361 Content-Length: ... 363 Figure 4: Sample REGISTER message 365 Since the emergency client does not have a domain, it MUST register 366 in the same domain as the ESRP. This is illustrated in the example 367 REGISTER message show in Figure 4. 369 6. Emergency Client Call Intitiation 371 Immediately subsequent to the registration a SIP INVITE request is 372 sent to the ESRP in the following form: 374 1. The Request URI MUST be the service URN [RFC5031] in the "sos" 375 tree. 377 2. The To header MUST be a service URN in the "sos" tree. 379 3. The From header MUST be present and MUST be the public GRUU 380 returned from the registration with the ESRP-registrar. 382 4. A Route header MUST be present with an ESRP URI, obtained from 383 LoST. 385 5. A Contact header MUST be present and contain the public GRUU 386 [RFC5627], and be valid for several minutes following the 387 termination of the call, provided that the UAC remains registered 388 with the same registrar, to permit an immediate call-back to the 389 specific device which placed the emergency call. 391 6. A SDP offer MUST be included in the INVITE. If voice is 392 supported the offer MUST include the G.711 codec, see Section 14 393 of [I-D.ietf-ecrit-phonebcp]. 395 7. SIP Caller Preferences [RFC3841] SHOULD be used to signal how the 396 PSAP should handle the call. For example, a language preference 397 expressed in an Accept-Language header may be used as a hint to 398 cause the PSAP to route the call to a call taker who speaks the 399 requested language. SIP Caller Preferences may also be used to 400 indicate a need to invoke a relay service for communication with 401 people with disabilities in the call. 403 7. Call Termination Control 405 The description in [I-D.rosen-ecrit-premature-disconnect-rqmts] is 406 relevant for this document. 408 8. SIP Feature Restrictions 410 The functionality defined in Section 9.3 in [I-D.ietf-ecrit-phonebcp] 411 regarding disabling of certain features is relevant for this document 412 and an emergency client MUST NOT implement the the features listed in 413 ED-70, and ED-71. 415 9. Testing 417 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] regarding 418 emergency call testing is used by this specification. Since this 419 specification mandates a registration with the ESRP-registrar a 420 similar tagging URI to that described in 421 [I-D.patel-ecrit-sos-parameter] is used to indicate a test 422 registration. 424 Test registrations SHALL be of short durations, but MUST be long 425 enough to allow completion of a "test call" as described in 426 [I-D.ietf-ecrit-phonebcp]. 428 9.1. Test Registration 430 When the emergency client sends a REGISTER request for emergency test 431 registration, the "sos.test" URI parameter MUST be appended to the 432 URI in the Contact header. This indicates to the ESRP-registrar that 433 the request is for emergency test registration. 435 ... 436 Contact: 437 ;+sip.instance="" 438 Content-Type: multipart/mixed; boundary=boundary1 439 Content-Length: ... 441 Figure 5: Test REGISTER Message Fragment 443 Only one Contact header field SHOULD be included in the emergency 444 REGISTER test request. If more than one Contact header is included 445 then the presence of the "sos.test" URI in any of the Contact fields 446 SHALL result in the ESRP-registrar treating the registration as a 447 test registration. 449 9.2. Format 451 The following syntax specification uses the augmented Backus-Naur 452 Form (BNF) as described in [RFC5234]. 454 The "sos.test" URI parameter is a "uri-parameter", as defined by 455 [RFC3261]. 457 uri-parameter =/ sos-param-test 459 sos-param-test = "sos.test" 461 10. PSAP Callback 463 PSAP callback occurs as described in 464 [I-D.schulzrinne-ecrit-psap-callback]. 466 11. Security Considerations 468 TBD 470 12. IANA Considerations 472 This specification defines one new SIP URI parameter, as per the 473 registry created by [RFC3969]. 475 Parameter Name: sos.test 477 Predefined Values: none 479 Reference: [RFCXXXX] 481 [NOTE TO IANA: Please replace XXXX with the RFC number of this 482 specification.] 484 13. Acknowledgements 486 Thanks to Elaine Quah for being a sounding board. 488 14. References 490 14.1. Normative References 492 [I-D.ietf-ecrit-phonebcp] 493 Rosen, B. and J. Polk, "Best Current Practice for 494 Communications Services in support of Emergency Calling", 495 draft-ietf-ecrit-phonebcp-13 (work in progress), 496 July 2009. 498 [I-D.ietf-geopriv-held-identity-extensions] 499 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 500 Barnes, "Use of Device Identity in HTTP-Enabled Location 501 Delivery (HELD)", 502 draft-ietf-geopriv-held-identity-extensions-01 (work in 503 progress), October 2009. 505 [I-D.ietf-sip-outbound] 506 Jennings, C., "Managing Client Initiated Connections in 507 the Session Initiation Protocol (SIP)", 508 draft-ietf-sip-outbound-20 (work in progress), June 2009. 510 [I-D.ietf-sipcore-location-conveyance] 511 Polk, J. and B. Rosen, "Location Conveyance for the 512 Session Initiation Protocol", 513 draft-ietf-sipcore-location-conveyance-01 (work in 514 progress), July 2009. 516 [I-D.schulzrinne-ecrit-psap-callback] 517 Schulzrinne, H., Tschofenig, H., and M. Patel, "Public 518 Safety Answering Point (PSAP) Callbacks", 519 draft-schulzrinne-ecrit-psap-callback-01 (work in 520 progress), October 2009. 522 [I-D.thomson-geopriv-res-gw-lis-discovery] 523 Thomson, M. and R. Bellis, "Location Information Server 524 (LIS) Discovery From Behind Residential Gateways", 525 draft-thomson-geopriv-res-gw-lis-discovery-02 (work in 526 progress), July 2009. 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 532 A., Peterson, J., Sparks, R., Handley, M., and E. 533 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 534 June 2002. 536 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 537 Preferences for the Session Initiation Protocol (SIP)", 538 RFC 3841, August 2004. 540 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 541 (IANA) Uniform Resource Identifier (URI) Parameter 542 Registry for the Session Initiation Protocol (SIP)", 543 BCP 99, RFC 3969, December 2004. 545 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 546 Emergency and Other Well-Known Services", RFC 5031, 547 January 2008. 549 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 550 Tschofenig, "LoST: A Location-to-Service Translation 551 Protocol", RFC 5222, August 2008. 553 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 554 Specifications: ABNF", STD 68, RFC 5234, January 2008. 556 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 557 Agent URIs (GRUUs) in the Session Initiation Protocol 558 (SIP)", RFC 5627, October 2009. 560 14.2. Informative References 562 [I-D.ietf-ecrit-framework] 563 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 564 "Framework for Emergency Calling using Internet 565 Multimedia", draft-ietf-ecrit-framework-10 (work in 566 progress), July 2009. 568 [I-D.ietf-ecrit-lost-servicelistboundary] 569 Wolf, K., "Location-to-Service Translation Protocol (LoST) 570 Extension: ServiceListBoundary", 571 draft-ietf-ecrit-lost-servicelistboundary-00 (work in 572 progress), October 2009. 574 [I-D.patel-ecrit-sos-parameter] 575 Patel, M., "SOS Uniform Resource Identifier (URI) 576 Parameter for Marking of Session Initiation Protocol 577 (SIP) Requests related to Emergency Services", 578 draft-patel-ecrit-sos-parameter-06 (work in progress), 579 May 2009. 581 [I-D.rosen-ecrit-premature-disconnect-rqmts] 582 Rosen, B., "Requirements for handling abandoned calls and 583 premature disconnects in emergency calls on the 584 Internet", draft-rosen-ecrit-premature-disconnect-rqmts-02 585 (work in progress), January 2009. 587 Authors' Addresses 589 James Winterbottom 590 Andrew Corporation 591 Andrew Building (39) 592 University of Wollongong, NSW 2500 593 AU 595 Email: james.winterbottom@andrew.com 597 Martin Thomson 598 Andrew Corporation 599 Andrew Building (39) 600 University of Wollongong, NSW 2500 601 AU 603 Email: martin.thomson@andrew.com 605 Hannes Tschofenig 606 Nokia Siemens Networks 607 Linnoitustie 6 608 Espoo, 02 600 609 Finland 611 Email: Hannes.Tschofenig@gmx.net 613 Henning Schulzrinne 614 Columbia University 615 Department of Computer Science 616 450 Computer Science Building 617 New York, NY 10027 618 US 620 Phone: +1 212 939 7004 621 Email: hgs+ecrit@cs.columbia.edu 622 URI: http://www.cs.columbia.edu