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