idnits 2.17.1 draft-winterbottom-ecrit-direct-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 581 has weird spacing: '...ects in emerg...' -- The document date (March 4, 2010) is 5159 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 478, but not defined == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-14 == Outdated reference: A later version (-06) exists of draft-ietf-geopriv-held-identity-extensions-03 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-location-conveyance-02 == 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-03 ** 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: A later version (-13) exists of draft-ietf-ecrit-framework-10 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-lost-servicelistboundary-03 == Outdated reference: A later version (-11) exists of draft-patel-ecrit-sos-parameter-08 Summary: 3 errors (**), 0 flaws (~~), 11 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: September 5, 2010 H. Tschofenig 6 Nokia Siemens Networks 7 H. Schulzrinne 8 Columbia University 9 March 4, 2010 11 ECRIT Direct Emergency Calling 12 draft-winterbottom-ecrit-direct-02.txt 14 Abstract 16 The specified IETF emergency services architecture puts a strong 17 emphasis on emergency call and emergency messaging via the Voice 18 Service Provider (VSP) / Application Service Provider (ASP). There 19 are two reasons for this design decision: The call routing via the 20 VSP/ASP is more natural as it follows the standard communication 21 pattern and transition deployments assume non-updated end hosts. 23 As the deployment of the Location-to-Service Translation protocol 24 progresses there are possibilities for upgraded end devices to 25 directly communicate with the IP-based emergency services network 26 without the need to interact with a VSP/ASP, which simplifies the 27 task of regulators as the involved parties are within the same 28 jurisdiction. 30 This memo describes the procedures and operations of a generic 31 emergency calling client utilizing the available building blocks. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on September 5, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. The Jurisdictional Problem . . . . . . . . . . . . . . . . . . 7 76 4. ESRP Route Determination . . . . . . . . . . . . . . . . . . . 8 77 5. Emergency Client Registration . . . . . . . . . . . . . . . . 9 78 6. Emergency Client Call Intitiation . . . . . . . . . . . . . . 13 79 7. Call Termination Control . . . . . . . . . . . . . . . . . . . 14 80 8. SIP Feature Restrictions . . . . . . . . . . . . . . . . . . . 15 81 9. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9.1. Test Registration . . . . . . . . . . . . . . . . . . . . 16 83 9.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 10. PSAP Callback . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 The description of the IETF emergency services architecture, found in 96 [I-D.ietf-ecrit-phonebcp] and in [I-D.ietf-ecrit-framework], focuses 97 on devices where emergency calls are routed primarily through the 98 subscriber's home VSP and the direct signaling communication between 99 the end host and the Public Safety Answering Point (PSAP) that 100 contains the IP-based PSAP is only an exception. This is a 101 convenient assumption if one considers the regular communication 102 patterns of the device and the potential proprietary protocol 103 implementations used between the end host and the VSP and the ability 104 to move the interoperability challenges away from the end device and 105 closer to VSPs. There are, however, challenges for regulators to 106 enforce emergency services functionality when the VSP is located in a 107 different jurisdiction. Inclusion of a VSP introduces unnecessary 108 elements into the emergency call path making the overall solution 109 more cumbersome. 111 With the help of the Location-to-Service Translation protocol a PSAP 112 URI is discovered that allows the end device to directly send SIP 113 communication requests towards the PSAP. 115 Note that the information returned by LoST may not necessarily be the 116 address of the PSAP itself but might rather be an entity that gets 117 the emergency call closer to the PSAP by returning the address of an 118 Emergency Services Routing Proxy (ESRP). 120 The intent of this client is that it will be able to use the 121 available ECRIT building blocks to allow any IP enabled device with 122 access to the Internet to make an emergency call without requiring 123 the signaling interaction with the VSP. In fact, there is no 124 assumption or requirement for a VSP subscription to exist. The 125 interacting entities are shown in Figure 1. 127 .... .... 128 ,' ',' ', 129 ; ; 130 +--------+ ; ; +------+ 131 | Device |--->: ISP :----->| ESRP | 132 +--------+ ; ; +------+ 133 `, ,', ,' 134 , , , , 135 ```` ```` 137 Figure 1: Network Configuration 139 Furthermore, a means for call-back in the event of a dropped call is 140 also described. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 3. The Jurisdictional Problem 150 The jurisdictional problem is illustrated with Figure 2 that 151 highlights that provided the data in the Location Information Server 152 (LIS) and the LoST server are correct, that the caller and the PSAP 153 are assured of being in the same regulatory jurisdiction. This is 154 important, because it shows that it is the access component of the 155 network and not the service component against which reguatory 156 obligations can be imposed with any hope of enforcement. Regulation 157 without the possibility of enforcement is challenging as there is 158 very little coordination between regulators world wide in this area, 159 consequently any emergency calling procedure should ensure that all 160 nodes against which the procedures apply fall within the same 161 regulatory boundary. 163 +-----+ 164 | VSP | 165 | # | 166 +-----+ 168 o-------------o----------------------o-------------o 169 / \ 170 / +---------+ +--------+ \ 171 / | Access \ / ESINet \ \ 172 o | Network \ / \ o 173 | + + + O + | 174 | / O | / interaction to learn 205 about the available emergency services (potentially using the 206 serviceListBoundary extension defined in 207 [I-D.ietf-ecrit-lost-servicelistboundary]). The service options may 208 be presented to the emergency caller in a graphical fashion and once 209 a specific service is selected a LoST query would be initiated 210 (unless a cached mapping is available that makes this request 211 obsolete). The LoST query to obtain the ESRP URI for 212 the selected service is in this example initiated at the time the 213 emergency call setup is performed. It is recommended that ESRP 214 discovery occurs at call time. 216 5. Emergency Client Registration 218 Emergency registration is only necessary when an emergency call 219 procedure is initiated. Immediately prior to making an emergency 220 call, the emergency client performs a SIP emergency registration with 221 the registrar in the ESRP, the ESRP-registrar. The emergency 222 registration is a SIP registration with specific options and headers 223 which are required in order to guard the emergency network and ensure 224 callback should it be required. 226 Each emergency client MUST provide an instance-id, as defined in 227 [I-D.ietf-sip-outbound], this allows the ESRP-registrar to generate a 228 GRUU [RFC5627] that can be used as a callback identifier. A GRUU is 229 necessary as the callback identifier because the emergency client 230 does not provide a longer-term contact address to the ESRP-registrar 231 prior to registration, and the GRUU provides a handle by which the 232 PSAP can identify the calling emergency client. To simplify the 233 emergency client and ESRP-registrar implementations, only public 234 GRUUs are provided by the ESRP-registrar. The public GRUU is 235 guaranteed to be the same for a device regardless of re-registration 236 with a different call-id, which may occur if the device unexpectedly 237 reboots. This is not true for temporary GRUUs, which makes temporary 238 GRUUs undesriable in the scope of this application space. 240 The PSAP is able to define and mandate the time over which callback 241 is possible. This needs to be a reasonable period of time, nominally 242 10s of minutes, as the device may well be transient with regards to 243 network attachment. The ESRP-registrar selects a registration period 244 based on local policy. The emergency client MUST accept a 245 registration for at least 60 minutes, but MAY accept longer 246 registrations based on its own policy. 248 In the event that a registration is lost by the emergency client 249 prior to reaching registration expiry then the emergency client MUST 250 re-register with the ESRP-registrar and SHOULD use the same call-id. 251 In this circumstance the ESRP-registrar SHOULD match the instance-id 252 and the call-id to recognize that it is a re-registration for a 253 dropped connection, and expiry time in the registration response 254 SHOULD be set to the time remaining when the original registration 255 occurred. 257 [I-D.ietf-sip-outbound] requires a device to support at least 2 258 registrations to different proxies. The emergency client 259 requirements in this memo relax this requirement down to one 260 registration, but more than one is allowed. There are several 261 reasons for relaxing the connection redundancy requirement. Firstly, 262 ESRPs are expected to have inbuilt redundancy, so if a connection is 263 dropped due to a failed proxy in the ESRP, then a new connection or 264 registration will automatically be directed to an active proxy in the 265 ESRP cluster. If the connection dropped because of some other 266 failure along the path from the emergency client to the ESRP, then 267 multiple SIP registrations are unlikely to provide any measurable 268 reliability improvements since single points of failure in this path 269 are inherently likely. Secondly, re-registrations only occur 270 immediately prior to call placement, so any outbound failure will 271 also likely result in the call dropping. If this occurs then the 272 emergency client MUST re-register with the ESRP-registrar, and since 273 instance-id and public GRUU will remain unchanged as a result of 274 this, the emergency client can either receive a callback from the 275 PSAP, or it can initiate a new call to the emergency network. 277 Location information is critical to emergency calling. Providing 278 location information to the calling-entity with sufficient 279 granularity to allow ESRP route determination is crucial. Since this 280 must occur prior to the emergency client registering with the ESRP- 281 registrar, the emergency client must have access to a certain amount 282 of location information (and the amount varies depending on the 283 specific emergency services deployment architecture). 285 The device SHOULD include all the location information it has when 286 registering with the ERSP-registrar. Inclusion of location 287 information in SIP REGISTER messages is specified in 288 [I-D.ietf-sipcore-location-conveyance]. There are three possible 289 execution paths for the ESRP-registrar when receiving a REGISTER 290 message: 292 1. If the REGISTER message does not include location information the 293 ESRP-registrar MUST use HELD identity 294 [I-D.ietf-geopriv-held-identity-extensions] to obtain the 295 location of the device as both a location value and reference. 296 In order to contact the LIS the ESRP-registrar SHOULD determine 297 the LIS address using the mechanism described in 298 [I-D.thomson-geopriv-res-gw-lis-discovery]. The ESRP-registrar 299 MAY use other methods for LIS determination where available. 301 2. If the REGISTER message contains a location URI then the ESRP- 302 registrar MUST dereference it so that it has a location available 303 to route the impending emergency call. The ESRP-registrar MAY 304 validate the LIS address in the location URI with that of the LIS 305 serving the network from which the REGISTER message originated. 307 3. The REGISTER message contains location information by value. Any 308 actions performed by the ESRP-registrar to valid this information 309 are specific to the jurisdiction in which the ESRP operates and 310 are out of the scope of this document. 312 Where location conveyance is used confidentiality protection SHOULD 313 be provided using Transport Layer Security (TLS). 315 Figure 3 show the registration message exchange graphically. 317 +--------+ +-----+ +------+ +------+ 318 | Device | | LIS | | LoST | | ESRP | 319 +--------+ +-----+ +------+ +------+ 320 | | | | 321 +<----LIS Discovery---->+ | | 322 | | | | 323 +----locationRequest--->+ | | 324 | | | | 325 +<---locationResponse---| | | 326 | | | | 327 +------------------findService------------->+ | 328 | | | | 329 +<--------------findServiceResponse---------+ | 330 | | | | 331 +------------------------REGISTER------------------------>+ 332 | | | | 333 | +<------locationRequest-----------+ 334 | | | | 335 | +-------locationResponse--------->+ 336 | | | | 337 +<-------------------------200 OK ------------------------+ 338 | | | | 340 Figure 3: Example Registration Message Flow 342 REGISTER sip:sos.example.com SIP/2.0 343 Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7 344 Max-Forwards: 70 345 From: anon ;tag=7F94778B653B 346 To: anon 347 Call-ID: 16CB75F21C70 348 CSeq: 1 REGISTER 349 Geolocation: 350 ;inserted-by="anon@192.0.2.2" 351 ;routing-allowed=yes 352 Geolocation: 353 ;inserted-by="anon@192.0.2.2" 354 ;routing-allowed=no 355 Require: gruu, geolocation 356 Supported: outbound, gruu 357 Contact: 358 ;+sip.instance="" 359 Content-Type: multipart/mixed; boundary=boundary1 360 Content-Length: ... 362 Figure 4: Sample REGISTER message 364 Since the emergency client does not have a domain, it MUST register 365 in the same domain as the ESRP. This is illustrated in the example 366 REGISTER message show in Figure 4. 368 6. Emergency Client Call Intitiation 370 Immediately subsequent to the registration a SIP INVITE request is 371 sent to the ESRP in the following form: 373 1. The Request URI MUST be the service URN [RFC5031] in the "sos" 374 tree. 376 2. The To header MUST be a service URN in the "sos" tree. 378 3. The From header MUST be present and MUST be the public GRUU 379 returned from the registration with the ESRP-registrar. 381 4. A Route header MUST be present with an ESRP URI, obtained from 382 LoST. 384 5. A Contact header MUST be present and contain the public GRUU 385 [RFC5627], and be valid for several minutes following the 386 termination of the call, provided that the UAC remains registered 387 with the same registrar, to permit an immediate call-back to the 388 specific device which placed the emergency call. 390 6. A SDP offer MUST be included in the INVITE. If voice is 391 supported the offer MUST include the G.711 codec, see Section 14 392 of [I-D.ietf-ecrit-phonebcp]. 394 7. SIP Caller Preferences [RFC3841] SHOULD be used to signal how the 395 PSAP should handle the call. For example, a language preference 396 expressed in an Accept-Language header may be used as a hint to 397 cause the PSAP to route the call to a call taker who speaks the 398 requested language. SIP Caller Preferences may also be used to 399 indicate a need to invoke a relay service for communication with 400 people with disabilities in the call. 402 7. Call Termination Control 404 The description in [I-D.rosen-ecrit-premature-disconnect-rqmts] is 405 relevant for this document. 407 8. SIP Feature Restrictions 409 The functionality defined in Section 9.3 in [I-D.ietf-ecrit-phonebcp] 410 regarding disabling of certain features is relevant for this document 411 and an emergency client MUST NOT implement the the features listed in 412 ED-70, and ED-71. 414 9. Testing 416 The description in Section 15 of [I-D.ietf-ecrit-phonebcp] regarding 417 emergency call testing is used by this specification. Since this 418 specification mandates a registration with the ESRP-registrar a 419 similar tagging URI to that described in 420 [I-D.patel-ecrit-sos-parameter] is used to indicate a test 421 registration. 423 Test registrations SHALL be of short durations, but MUST be long 424 enough to allow completion of a "test call" as described in 425 [I-D.ietf-ecrit-phonebcp]. 427 9.1. Test Registration 429 When the emergency client sends a REGISTER request for emergency test 430 registration, the "sos.test" URI parameter MUST be appended to the 431 URI in the Contact header. This indicates to the ESRP-registrar that 432 the request is for emergency test registration. 434 ... 435 Contact: 436 ;+sip.instance="" 437 Content-Type: multipart/mixed; boundary=boundary1 438 Content-Length: ... 440 Figure 5: Test REGISTER Message Fragment 442 Only one Contact header field SHOULD be included in the emergency 443 REGISTER test request. If more than one Contact header is included 444 then the presence of the "sos.test" URI in any of the Contact fields 445 SHALL result in the ESRP-registrar treating the registration as a 446 test registration. 448 9.2. Format 450 The following syntax specification uses the augmented Backus-Naur 451 Form (BNF) as described in [RFC5234]. 453 The "sos.test" URI parameter is a "uri-parameter", as defined by 454 [RFC3261]. 456 uri-parameter =/ sos-param-test 458 sos-param-test = "sos.test" 460 10. PSAP Callback 462 PSAP callback occurs as described in 463 [I-D.schulzrinne-ecrit-psap-callback]. 465 11. Security Considerations 467 TBD 469 12. IANA Considerations 471 This specification defines one new SIP URI parameter, as per the 472 registry created by [RFC3969]. 474 Parameter Name: sos.test 476 Predefined Values: none 478 Reference: [RFCXXXX] 480 [NOTE TO IANA: Please replace XXXX with the RFC number of this 481 specification.] 483 13. Acknowledgements 485 Thanks to Elaine Quah for being a sounding board. 487 14. References 489 14.1. Normative References 491 [I-D.ietf-ecrit-phonebcp] 492 Rosen, B. and J. Polk, "Best Current Practice for 493 Communications Services in support of Emergency Calling", 494 draft-ietf-ecrit-phonebcp-14 (work in progress), 495 January 2010. 497 [I-D.ietf-geopriv-held-identity-extensions] 498 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 499 Barnes, "Use of Device Identity in HTTP-Enabled Location 500 Delivery (HELD)", 501 draft-ietf-geopriv-held-identity-extensions-03 (work in 502 progress), February 2010. 504 [I-D.ietf-sip-outbound] 505 Jennings, C., "Managing Client Initiated Connections in 506 the Session Initiation Protocol (SIP)", 507 draft-ietf-sip-outbound-20 (work in progress), June 2009. 509 [I-D.ietf-sipcore-location-conveyance] 510 Polk, J. and B. Rosen, "Location Conveyance for the 511 Session Initiation Protocol", 512 draft-ietf-sipcore-location-conveyance-02 (work in 513 progress), February 2010. 515 [I-D.schulzrinne-ecrit-psap-callback] 516 Schulzrinne, H., Tschofenig, H., and M. Patel, "Public 517 Safety Answering Point (PSAP) Callbacks", 518 draft-schulzrinne-ecrit-psap-callback-01 (work in 519 progress), October 2009. 521 [I-D.thomson-geopriv-res-gw-lis-discovery] 522 Thomson, M. and R. Bellis, "Location Information Server 523 (LIS) Discovery using IP address and Reverse DNS", 524 draft-thomson-geopriv-res-gw-lis-discovery-03 (work in 525 progress), January 2010. 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, March 1997. 530 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 531 A., Peterson, J., Sparks, R., Handley, M., and E. 532 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 533 June 2002. 535 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 536 Preferences for the Session Initiation Protocol (SIP)", 537 RFC 3841, August 2004. 539 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 540 (IANA) Uniform Resource Identifier (URI) Parameter 541 Registry for the Session Initiation Protocol (SIP)", 542 BCP 99, RFC 3969, December 2004. 544 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 545 Emergency and Other Well-Known Services", RFC 5031, 546 January 2008. 548 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 549 Tschofenig, "LoST: A Location-to-Service Translation 550 Protocol", RFC 5222, August 2008. 552 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 553 Specifications: ABNF", STD 68, RFC 5234, January 2008. 555 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 556 Agent URIs (GRUUs) in the Session Initiation Protocol 557 (SIP)", RFC 5627, October 2009. 559 14.2. Informative References 561 [I-D.ietf-ecrit-framework] 562 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 563 "Framework for Emergency Calling using Internet 564 Multimedia", draft-ietf-ecrit-framework-10 (work in 565 progress), July 2009. 567 [I-D.ietf-ecrit-lost-servicelistboundary] 568 Wolf, K., "LoST Service List Boundary Extension", 569 draft-ietf-ecrit-lost-servicelistboundary-03 (work in 570 progress), February 2010. 572 [I-D.patel-ecrit-sos-parameter] 573 Patel, M., "SOS Uniform Resource Identifier (URI) 574 Parameter for Marking of Session Initiation Protocol (SIP) 575 Requests related to Emergency Services", 576 draft-patel-ecrit-sos-parameter-08 (work in progress), 577 February 2010. 579 [I-D.rosen-ecrit-premature-disconnect-rqmts] 580 Rosen, B., "Requirements for handling abandoned calls and 581 premature disconnects in emergency calls on the 582 Internet", draft-rosen-ecrit-premature-disconnect-rqmts-02 583 (work in progress), January 2009. 585 Authors' Addresses 587 James Winterbottom 588 Andrew Corporation 589 Andrew Building (39) 590 University of Wollongong, NSW 2500 591 AU 593 Email: james.winterbottom@andrew.com 595 Martin Thomson 596 Andrew Corporation 597 Andrew Building (39) 598 University of Wollongong, NSW 2500 599 AU 601 Email: martin.thomson@andrew.com 603 Hannes Tschofenig 604 Nokia Siemens Networks 605 Linnoitustie 6 606 Espoo, 02 600 607 Finland 609 Email: Hannes.Tschofenig@gmx.net 611 Henning Schulzrinne 612 Columbia University 613 Department of Computer Science 614 450 Computer Science Building 615 New York, NY 10027 616 US 618 Phone: +1 212 939 7004 619 Email: hgs+ecrit@cs.columbia.edu 620 URI: http://www.cs.columbia.edu