idnits 2.17.1 draft-ietf-sip-manyfolks-resource-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 3) being 60 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 453 has weird spacing: '... recv sendr...' == Line 467 has weird spacing: '...request mand...' == Line 482 has weird spacing: '...reponse send ...' == Line 497 has weird spacing: '...reponse send ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '1' on line 61 looks like a reference -- Missing reference section? '4' on line 111 looks like a reference -- Missing reference section? '5' on line 120 looks like a reference -- Missing reference section? '2' on line 829 looks like a reference -- Missing reference section? '6' on line 171 looks like a reference -- Missing reference section? '7' on line 172 looks like a reference -- Missing reference section? '8' on line 1120 looks like a reference -- Missing reference section? '9' on line 174 looks like a reference -- Missing reference section? '10' on line 228 looks like a reference -- Missing reference section? '11' on line 226 looks like a reference -- Missing reference section? '3' on line 385 looks like a reference -- Missing reference section? '12' on line 1007 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft AT&T 4 Document: 5 K. Ramakrishnan 6 TeraOptic Networks 8 E. Miller 9 G. Russell 10 CableLabs 12 B. Beser 13 Pacific Broadband 15 M. Mannette 16 K. Steinbrenner 17 3Com 19 D. Oran 20 F. Andreasen 21 M. Ramalho 22 Cisco 24 J. Pickens 25 Com21 27 P. Lalwaney 28 Nokia 30 J. Fellows 31 Motorola 33 D. Evans 34 D. R. Evans Consulting 36 K. Kelly 37 NetSpeak 39 A. Roach 40 Ericsson 42 J. Rosenberg 43 D. Willis 44 S. Donovan 45 dynamicsoft 47 H. Schulzrinne 48 Columbia University 50 November, 2000 52 Integration of Resource Management and SIP 54 SIP Working Group Expiration 5/31/01 1 55 SIP Extensions for Resource Management November 2000 57 Status of this Memo 59 This document is an Internet-Draft and is in full conformance with 60 all provisions of Section 10 of RFC2026[1]. 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF), its areas, and its working groups. Note that 64 other groups may also distribute working documents as Internet- 65 Drafts. Internet-Drafts are draft documents valid for a maximum of 66 six months and may be updated, replaced, or obsoleted by other 67 documents at any time. It is inappropriate to use Internet- Drafts 68 as reference material or to cite them other than as "work in 69 progress." 71 The list of current Internet-Drafts can be accessed at 72 http://www.ietf.org/ietf/1id-abstracts.txt 74 The list of Internet-Draft Shadow Directories can be accessed at 75 http://www.ietf.org/shadow.html. 77 The distribution of this memo is unlimited. It is filed as , and expires May 31, 2001. 79 Please send comments to the authors. 81 1. Abstract 83 This document discusses how network QoS and security establishment 84 can be made a precondition to sessions initiated by the Session 85 Initiation Protocol (SIP), and described by SDP. These preconditions 86 require that the participant reserve network resources (or establish 87 a secure media channel) before continuing with the session. We do 88 not define new QoS reservation or security mechanisms; these pre- 89 conditions simply require a participant to use existing resource 90 reservation and security mechanisms before beginning the session. 92 This results in a multi-phase call-setup mechanism, with the 93 resource management protocol interleaved between two phases of call 94 signaling. The objective of such a mechanism is to enable deployment 95 of robust IP Telephony services, by ensuring that resources are made 96 available before the phone rings and the participants of the call 97 are "invited" to participate. 99 This document also proposes an extension to the Session Initiation 100 Protocol (SIP) to add a new COMET method, which is used to confirm 101 the completion of all pre-conditions by the session originator. 103 2. Conventions used in this document 105 SIP Working Group Expiration 5/31/01 2 106 SIP Extensions for Resource Management November 2000 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 110 this document are to be interpreted as described in RFC-2119[4]. 112 3. Introduction 114 For an Internet Telephony service to be successfully used by a large 115 number of subscribers, it must offer few surprises to those 116 accustomed to the behavior of existing telephony services. One 117 expectation is that of connection quality, implying resources must 118 be set aside for each call. 120 A key contribution of the DCS architecture, as described in [5], is 121 a recognition of the need for coordination between call signaling, 122 which controls access to telephony specific services, and resource 123 management, which controls access to network-layer resources. This 124 coordination is designed to meet the user expectations and human 125 factors associated with telephony. 127 While customers may expect, during times of heavy load, to receive a 128 "fast busy" or an announcement saying "all circuits are busy now," 129 the general expectation is that once the destination phone rings 130 that the connection can be made. Blocking a call after ringing the 131 destination is considered a "call defect" and is a very undesirable 132 exception condition. 134 This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions. 135 A "QoS-Assured" session will complete only if all the required 136 resources are available and assigned to the session. A provider may 137 choose to block a call when adequate resources for the call are not 138 available. Public policy demands that the phone system provide 139 adequate quality at least in certain cases: e.g., for emergency 140 communications during times of disasters. Call blocking enables a 141 provider to meet such requirements. 143 A "QoS-Enabled" session allows the endpoints to complete the session 144 establishment either with or without the desired resources. Such 145 session will use dedicated resources if available, and use a best- 146 effort connection as an alternative if resources can not be 147 dedicated. In cases where resources are not available, the 148 originating and/or terminating User Agent might consult with the 149 customer to obtain guidance on whether the session should complete. 151 Coordination between call signaling and resource management is also 152 needed to prevent fraud and theft of service. The coordination 153 between call-signaling and QoS setup protocols ensures that users 154 are authenticated and authorized before receiving access to the 155 enhanced QoS associated with the telephony service. 157 This coordination, referred to in this draft as "preconditions," 158 require that the participant reserve network resources (or establish 159 a secure media channel) before continuing with the session. We do 160 not define new QoS reservation or security mechanisms; these pre- 162 SIP Working Group Expiration 5/31/01 3 163 SIP Extensions for Resource Management November 2000 165 conditions simply require a participant to use existing resource 166 reservation and security mechanisms before beginning the session. 168 In the case of SIP [2], this effectively means that the "phone won't 169 ring" until the preconditions are met. These preconditions are 170 described by new SDP parameters, defined in this document. The 171 parameters can mandate end-to-end QoS reservations based on RSVP [6] 172 or any other end-to-end reservation mechanism (such as YESSIR [7], 173 or PacketCable's Dynamic Quality of Service (D-QoS) [8]), and 174 security based on IPSEC [9]. The preconditions can be defined 175 independently for each media stream. 177 The QoS architecture of the Internet separates QoS signaling from 178 application level signaling. Application layer devices (such as web 179 proxies and SIP servers) are not well suited for participation in 180 network admission control or QoS management, as this is 181 fundamentally a network layer issue, independent of any particular 182 application. In addition, since application devices like SIP servers 183 are almost never on the "bearer path" (i.e., the network path the 184 RTP [10] takes), and since the RTP path and signaling paths can be 185 completely different (even traversing different autonomous systems), 186 these application servers are generally not capable of managing QoS 187 for the media. Keeping QoS out of application signaling also means 188 that there can be a single infrastructure for QoS across all 189 applications. This eliminates duplication of functionality, reducing 190 management and equipment costs. It also means that new applications, 191 with their own unique QoS requirements, can be easily supported. 193 This loose coupling works very well for a wide range of 194 applications. For example, in an interactive game, one can establish 195 the game using an application signaling protocol, and then later on 196 use RSVP to reserve network resources. The separation is also 197 effective for applications which have no explicit signaling. 198 However, certain applications may require tighter coupling. In the 199 case of Internet telephony, the following is an important 200 requirement: 202 When A calls B, B's phone should not ring unless resources 203 have been reserved from A to B, and B to A. 205 This could be achieved without coupling if A knew B's address, port, 206 and codecs before the telephony signaling took place. However, since 207 telephony signaling is used largely to obtain this information in 208 the first place, the coupling cannot be avoided. 210 A similar model exists for security. Rather than inventing new 211 security mechanisms for each new application, common security tools 212 (such as IPSEC) can be used across all applications. As with QoS, a 213 means in application level protocols is needed to indicate that a 214 security association is needed for the application to execute. 216 To solve both of these problems, we propose an extension to SDP 217 which allows indication of pre-conditions for sessions. These 218 preconditions indicate that participation in the session should not 220 SIP Working Group Expiration 5/31/01 4 221 SIP Extensions for Resource Management November 2000 223 proceed until the preconditions are met. The preconditions we define 224 are (1) success of end-to-end resource reservation, and (2) success 225 of end- to-end security establishment. We chose to implement these 226 extensions in SDP, rather than SIP [2] or SAP [11], since they are 227 fundamentally a media session issue. SIP is session agnostic; 228 information about codecs, ports, and RTP [10] are outside the scope 229 of SIP. Since it is the media sessions that the reservations and 230 security refer to, SDP is the appropriate venue for the extensions. 231 Furthermore, placement of the extensions in SDP rather than SIP or 232 SAP allows specification of preconditions for individual media 233 streams. For example, a multimedia lecture might require reservation 234 for the audio, but not the video (which is less important). 236 Our extensions are completely backward compatible. If a recipient 237 does not understand them, normal SIP or SAP processing will occur, 238 at no penalty of call setup latency. 240 3.1 Requirements 242 The basic motivation in this work is to meet and possibly exceed the 243 user expectations and human factors associated with telephony. 245 In this section, we briefly describe the application requirements 246 that led to the set of DCS signaling design principles. In its 247 basic implementation, DCS supports a residential telephone service 248 comparable to the local telephone services offered today. Some of 249 the requirements for resource management, in concert with call 250 signaling, are as follows: 252 The system must minimize call defects. These are situations where 253 either the call never completes, or an error occurs after the 254 destination is alerted. Requirements on call defects are typically 255 far more stringent than call blocking. Note that we expect the 256 provider and the endpoints to attempt to use lower bandwidth CODECs 257 as the first line of defense against limited network capacity, and 258 to avoid blocking calls. 260 The system must minimize the post-dial-delay, which is the time 261 between the user dialing the last digit and receiving positive 262 confirmation from the network. This delay must be short enough that 263 users do not perceive a difference with post-dial delay in the 264 circuit switched network or conclude that the network connectivity 265 no longer exists. 267 Call signaling needs to provide enough information to the resource 268 management protocol so as to enable resources to be allocated in the 269 network. This typically requires most if not all of the components 270 of a packet classifier (source IP, destination IP, source port, 271 destination port, protocol) to be available for resource allocation. 273 3.2 Overview 275 For acceptable interactive voice communication it is important to 276 achieve end-to-end QoS. The end-to-end QoS assurance implies 278 SIP Working Group Expiration 5/31/01 5 279 SIP Extensions for Resource Management November 2000 281 achieving low packet delay and packet loss. End-to-end packet delay 282 must be small enough that it does not interfere with normal voice 283 conversations. The ITU recommends no greater than 300 ms roundtrip 284 delay for telephony service. Packet loss must be small enough to 285 not perceptibly impede voice quality or the performance of fax and 286 voice band modems. 288 If it is found that the network cannot guarantee end-to-end QoS 289 resources, there are two alternatives: either (1) allow call 290 signaling to proceed with high probability of excessive delay and 291 packet loss which could impair any interactive real-time 292 communication between the participants, or (2) block the call prior 293 to the called party being alerted. When calls are blocked because 294 of a lack of resources in a particular segment of the network, it is 295 highly desirable that such blocking occur before the called party 296 picks up. 298 We do expect the endpoints to attempt to use lower bandwidth CODECs, 299 thereby avoiding blocking calls, as the first line of defense 300 against limited network capacity. 302 The call signaling and resource reservation must be achieved in such 303 a way that the post-dial-delay must be minimized without increasing 304 the probability of call defects. This means that the number of 305 round-trip messages must be kept at an absolute minimum and messages 306 must be sent directly end-system to end-system if possible. 308 The general idea behind the extension is simple. We define two new 309 SDP attributes, "qos" and "security". The "qos" attribute indicates 310 whether end-to-end resource reservation is optional or mandatory, 311 and in which direction (send, recv, or sendrecv). When the attribute 312 indicates mandatory, this means that the participant who has 313 received the SDP does not proceed with participation in the session 314 until resource reservation has completed in the direction indicated. 315 In this case, "not proceeding" means that the participant behaves as 316 if they had not received the SDP at all. If the attribute indicates 317 that QoS for the stream is optional, then the participant proceeds 318 normally with the session, but should reserve network resources in 319 the direction indicated, if they are capable. Absence of the "qos" 320 attribute means the participant reserves resources for this stream, 321 and proceeds normally with the session. This behavior is the normal 322 behavior for SDP. 324 Resource reservation takes place using whatever protocols 325 participants must use, based on support by their service provider. 326 If the ISP's of the various participants are using differing 327 resource reservation protocols, translation is necessary, but this 328 is done within the network, without knowledge of the participants. 330 The direction attribute indicates in which direction reservations 331 should be reserved. If "send", it means reservations should be made 332 in the direction of media flow from the session originator to 333 participants. If "recv", it means reservations should be made in the 334 direction of media flow from participants to the session originator. 336 SIP Working Group Expiration 5/31/01 6 337 SIP Extensions for Resource Management November 2000 339 In the case of "sendrecv", it means reservations should be made in 340 both directions. If the direction attribute is "sendrecv" but the 341 endpoints only support a single-direction resource reservation 342 protocol, then both the originator and participants cooperate to 343 ensure the agreed precondition is met. 344 In the case of security, the same attributes are defined - 345 optional/mandatory, and send/recv/sendrecv. Their meaning is 346 identical to the one above, except that a security association 347 should be established in the given direction. The details of the 348 security association are not signaled by SDP; these depend on the 349 Security Policy Database of the participant. 351 Either party can include a "confirm" attribute in the SDP. When the 352 "Confirm" attribute is present, the recipient sends a COMET message 353 to the sender, with SDP attached, telling the status of each 354 precondition as "success" or "failure." If the "confirm" attribute 355 is present in the SDP sent by the session originator to the 356 participant (e.g. in the SIP INVITE message), then the participant 357 sends the COMET message to the originator. If the "confirm" 358 attribute is present in the SDP sent by the recipient to the 359 originator (e.g. in a SIP response message), then the originator 360 sends the COMET message to the participant. 362 When the "Confirm" attribute is present in both the SDP sent by the 363 session originator to the participant (e.g. in the SIP INVITE 364 message), and in the SDP sent by the recipient back to the 365 originator (e.g. in a SIP response message), the session originator 366 would wait for the COMET message with the success/failure 367 notification before responding with a COMET message, and responds 368 instead with a CANCEL if a mandatory precondition is not met, or if 369 a sufficient combination of optional preconditions are not met. The 370 recipient does not wait for the COMET message from the originator 371 before sending its COMET message. 373 The "confirm" attribute is typically used if the direction attribute 374 is "sendrecv" and the originator or participant only supports a 375 single-direction resource reservation protocol. In such a case, the 376 originator (or participant) would reserve resources for one 377 direction of media flow, and send a confirmation with a direction 378 attribute of "send." The participant (or originator) would reserve 379 resources for the other direction. On receipt of the COMET message, 380 they would know that both directions have been reserved, and the 381 precondition is met. 382 4. SDP Extension 384 The formatting of the qos attribute in the Session Description 385 Protocol (SDP)[3] is described by the following BNF: 387 qos-attribute = "a=qos:" strength-tag SP direction-tag 388 [SP confirmation-tag] 389 strength-tag = ("mandatory" | "optional" | "success" | 390 "failure") 391 direction-tag = ("send" | "recv" | "sendrecv") 392 confirmation-tag = "confirm" 394 SIP Working Group Expiration 5/31/01 7 395 SIP Extensions for Resource Management November 2000 397 and the security attribute: 399 security-attribute = "a=secure:" SP strength-tag SP direction-tag 400 [SP confirmation-tag] 402 4.1 SDP Example 404 The following example shows an SDP description carried in a SIP 405 INVITE message from A to B: 407 v=0 408 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 409 s=SDP Seminar 410 i=A Seminar on the session description protocol 411 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 412 e=mjh@isi.edu (Mark Handley) 413 c=IN IP4 224.2.17.12/127 414 t=2873397496 2873404696 415 m=audio 49170 RTP/AVP 0 416 a=qos:mandatory recv confirm 417 m=video 51372 RTP/AVP 31 418 a=secure:mandatory sendrecv 419 m=application 32416 udp wb 420 a=orient:portrait 421 a=qos:optional sendrecv 422 a=secure:optional sendrecv 424 This SDP indicates that B should not continue its involvement in the 425 session until resources for the audio are reserved from B to A, and 426 a bi-directional security association is established for the video. 427 B can join the sessions once these preconditions are met, but should 428 reserve resources and establish a bidirectional security association 429 for the whiteboard. 431 4.2 SDP Allowable Combinations 433 If the recipient of the SDP (e.g. the UAS) is capable and willing to 434 honor the precondition(s), it returns a provisional response 435 containing SDP, along with the qos/security attributes, for each 436 such stream. This SDP MUST be a subset of the preconditions 437 indicated in the INVITE. 439 Table 1 illustrates the allowed values for the direction tag in the 440 response. Each row represents a value of the direction in the SIP 441 INVITE, and each column the value in the response. An entry of N/A 442 means that this combination is not allowed. A value of A->B (B->A) 443 implies that the precondition is for resources reserved (or security 444 established) from A to B (B to A). A value of A<->B means that the 445 precondition is for resource reservation or security establishment 446 in both directions. The value in the response is the one used by 447 both parties. 449 SIP Working Group Expiration 5/31/01 8 450 SIP Extensions for Resource Management November 2000 452 B: response 453 A: request send recv sendrecv none 454 send N/A A->B N/A -- 455 recv B->A N/A N/A -- 456 sendrecv A<-B B<-A A<->B -- 457 none -- -- -- -- 459 Table 1: Allowed values of coupling 461 Table 2 illustrates the allowed values for the strength tag in the 462 request and response. A "Y" means the combination is allowed, and a 463 "N" means it is not. The value in the response is the one used by 464 both parties. 466 B: response 467 A: request mandatory optional none 468 mandatory Y Y Y 469 optional N Y Y 470 none N N Y 472 Table 2: Allowed values of strength parameter 474 Table 3 illustrates the allowed values for the direction tag in a 475 confirmation message (COMET) sent from the originator to a 476 participant, based on the value of the direction tag negotiated in 477 the initial request and response. A "Y" means the combination is 478 allowed, and a "N" means it is not and SHOULD be ignored by the 479 participant. 481 A: confirmation 482 B: reponse send recv sendrecv 483 A->B Y N N 484 A<-B N Y N 485 A<->B Y Y Y 487 Table 3: Allowed values of direction in confirmation from A 489 Table 4 illustrates the allowed values for the direction tag in a 490 confirmation message (COMET) sent from the participant to the 491 originator, based on the value of the direction tag negotiated in 492 the initial request and response. A "Y" means the combination is 493 allowed, and a "N" means it is not and SHOULD be ignored by the 494 originator. 496 B: confirmation 497 B: reponse send recv sendrecv 498 A->B N Y N 499 A<-B Y N N 500 A<->B Y Y Y 502 Table 4: Allowed values of direction in confirmation from B 504 SIP Working Group Expiration 5/31/01 9 505 SIP Extensions for Resource Management November 2000 507 5. SIP Extension: The COMET Method 509 The COMET method is used for communicating successful completion of 510 preconditions from the calling to called user agents. 512 The signaling path for the COMET method is the signaling path 513 established as a result of the call setup. This can be either 514 direct signaling between the calling and called user agents or a 515 signaling path involving SIP proxy servers that were involved in the 516 call setup and added themselves to the Record-Route header on the 517 initial INVITE message. 519 The precondition information is communicated in the message body, 520 which MUST contain an SDP. For every agreed precondition, the 521 strength-tag MUST indicate "success" or "failure". 523 If the initial request contained Record-Route headers, the 524 provisional response MUST contain a copy of those headers, as if the 525 response were a 200 OK to the initial request. Since provisional 526 responses MAY contain Record-Route and Contact headers, the COMET 527 request MUST contain Route headers if the Record-Route headers were 528 present in the provisional response. The Route header is constructed 529 as specified in [2]. The Route header that is constructed from some 530 provisional response MUST NOT be placed in any other request except 531 for the COMET for that provisional response. 533 A UAC MUST NOT insert a Route header into a COMET request if no 534 Record-Route header was present in the response. 536 If the initial request was sent with credentials, the COMET request 537 SHOULD contain those credentials as well. 539 The Call-ID in the COMET MUST match that of the provisional 540 response. The CSeq in this request MUST be larger than the last 541 request sent by this UAC for this call leg. The To, From, and Via 542 headers MUST be present, and MUST be constructed as they would be 543 for a re-INVITE or BYE as specified in [2]. In particular, if the 544 provisional response contained a tag in the To field, this tag MUST 545 be mirrored in the To field of the COMET. 547 Once the COMET request is created, it is sent by the UAC. It is sent 548 as would any other non-INVITE request for a call. In particular, 549 when sent over UDP, the COMET request is retransmitted with an 550 exponentially increasing interval, starting at 500 milliseconds and 551 increasing to 4 seconds. Note that a UAC SHOULD NOT retransmit the 552 COMET request when it receives a retransmission of the provisional 553 response being acknowledged, although doing so does not create a 554 protocol error. As with any other non-INVITE request, the UAC 555 continues to retransmit the COMET request until it receives a final 556 response. 558 SIP Working Group Expiration 5/31/01 10 559 SIP Extensions for Resource Management November 2000 561 A COMET request MAY be cancelled. However, whilst allowed for 562 purposes of generality, usage of CANCEL with COMET is NOT 563 RECOMMENDED. 565 5.1 Header Field Support for COMET Method 567 Tables 3 and 4 are extensions of tables 4 and 5 in the SIP 568 specification[2]. Refer to Section 6 of [2] for a description of 569 the content of the tables. 571 5.2 Responses to the COMET Request Method 573 If a server receives a COMET request it MUST send a final response. 575 A 200 OK response MUST be sent by a UAS for a COMET request if the 576 COMET request was successfully received for an existing call. 577 Beyond that, no additional operations are required. 579 A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a 580 UAS if the COMET request does not match any existing call leg. 582 Header Where COMET 583 ------ ----- ---- 584 Accept R o 585 Accept-Encoding R o 586 Accept-Language R o 587 Allow 200 - 588 Allow 405 o 589 Authorization R o 590 Call-ID gc m 591 Contact R o 592 Contact 1xx - 593 Contact 2xx - 594 Contact 3xx - 595 Contact 485 - 596 Content-Encoding e o 597 Content-Length e o 598 Content-Type e * 599 CSeq gc m 600 Date g o 601 Encryption g o 602 Expires g o 603 From gc m 604 Hide R o 605 Max-Forwards R o 606 Organization g o 607 Table 3 Summary of header fields, A-0 609 SIP Working Group Expiration 5/31/01 11 610 SIP Extensions for Resource Management November 2000 612 Header Where COMET 613 ------ ----- ---- 614 Priority R o 615 Proxy-Authenticate 407 o 616 Proxy-Authorization R o 617 Proxy-Require R o 618 Require R o 619 Retry-After R - 620 Retry-After 404,480,486 o 621 Retry-After 503 o 622 Retry-After 600,603 o 623 Response-Key R o 624 Record-Route R o 625 Record-Route 2xx o 626 Route R o 627 Server r o 628 Subject R o 629 Timestamp g o 630 To gc(1) m 631 Unsupported 420 o 632 User-Agent g o 633 Via gc(2) m 634 Warning r o 635 WWW-Authenticate 401 o 637 Table 4 Summary of header fields, P-Z 639 Other request failure (4xx), Server Failure (5xx) and Global Failure 640 (6xx) responses MAY be sent for the COMET Request. 642 5.3 Message Body Inclusion 644 The COMET request MUST contain a message body. 646 5.4 Behavior of SIP User Agents 648 Unless stated otherwise, the protocol rules for the COMET request 649 governing the usage of tags, Route and Record-Route, retransmission 650 and reliability, CSeq incrementing and message formatting follow 651 those in [2] as defined for the BYE request. 653 A COMET request MAY be cancelled. A UAS receiving a CANCEL for an 654 COMET request SHOULD respond to the COMET with a "487 Request 655 Cancelled" response if a final response has not been sent to the 656 COMET and then behave as if the request were never received. 658 5.5 Behavior of SIP Proxy and Redirect Servers 660 5.5.1 Proxy Server 662 Unless stated otherwise, the protocol rules for the COMET request at 663 a proxy are identical to those for a BYE request as specified in 664 [2]. 666 SIP Working Group Expiration 5/31/01 12 667 SIP Extensions for Resource Management November 2000 669 5.5.2 Forking Proxy Server 671 Unless stated otherwise, the protocol rules for the COMET request at 672 a proxy are identical to those for a BYE request as specified in 673 [2]. 675 5.5.3 Redirection Server 677 Unless stated otherwise, the protocol rules for the COMET request at 678 a proxy are identical to those for a BYE request as specified in 679 [2]. 681 6. SIP Extension: The 580-Precondition-Failure Response 683 An additional error response is defined by this draft, which is 684 returned by a UAS if it is unable to perform the mandatory 685 preconditions for the session. 687 6.1 Status Code and Reason Phrase 689 The following is to be added to Figure 8, Server error status codes 691 Server-Error = "580" ;Precondition-Failure 693 6.2 Status Code Definition 695 The following is to be added to a new section 7.5.7. 697 7.5.7 580 Precondition Failure 699 The server was unable to establish the qos or security association 700 mandated by the SDP precondition. 702 7. SIP Extension: Content-Disposition type 704 An additional type value is defined by this draft, which is returned 705 by a UAS in a provisional response indicating preconditions for the 706 session. 708 The following is to be changed in section 6.15. 710 Disposition-type = "render" | "session" | "icon" | "alert" | 711 "precondition" | disp-extension-token 713 The value "precondition" indicates the body part describes QoS 714 and/or security preconditions that SHOULD be established prior to 715 the start of the session. 717 8. SIP Usage Rules 719 8.1 Overview 721 SIP Working Group Expiration 5/31/01 13 722 SIP Extensions for Resource Management November 2000 724 The session originator (UAC) prepares an SDP message body for the 725 INVITE describing the desired QoS and security preconditions for 726 each media flow, and the desired directions. The token value "send" 727 means the direction of media from originator (whichever entity 728 created the SDP) to recipient (whichever entity received the SDP in 729 a SIP message), and "recv" is from recipient to originator. In an 730 INVITE, the UAC is the originator, and the UAS is the recipient. The 731 roles are reversed in the response. 733 The recipient of the INVITE (UAS) returns a 18x provisional response 734 containing a Content-Disposition of "precondition," and SDP with the 735 qos/security attribute for each stream having a precondition. The 736 UAS would typically include a confirmation request. This SDP is a 737 subset of the preconditions indicated in the INVITE. Unlike normal 738 SIP processing, the UAS MUST NOT alert the called user at this 739 point. The UAS now attempts to reserve the qos resources and 740 establish the security associations. 742 The 18x provisional response is received by the UAC. If the 18x 743 contained SDP with mandatory qos/security parameters, the UAC does 744 not let the session proceed until the mandatory preconditions are 745 met. The UAC attempts to reserve the needed resources and establish 746 the security associations. 748 If either party requests a confirmation, a COMET message is sent to 749 that party. The COMET message contains the success/failure 750 indication for each precondition. For a precondition with a 751 direction value of "sendrecv," the COMET indicates whether the 752 sender is able to confirm both directions or only one direction. 753 Upon receipt of the COMET message, the UAC/UAS continues normal SIP 754 call handling, by (for a UAS) alerting the user and sending e.g. a 755 180-Ringing or 200-OK response. The UAC SIP transaction completes 756 normally. 758 Note that this extension requires usage of reliable provisional 759 responses [12]. This is because the 18x contains SDP with 760 information required for the session originator to initiate 761 reservations from it towards the participant. 763 8.2 Behavior of Originator (UAC) 765 The session originator (UAC) MAY include QoS and security 766 preconditions (including the desired direction) for each media flow 767 in the SDP sent with the INVITE. The token value "send" means the 768 direction of media from originator (whichever entity created the 769 SDP) to recipient (whichever entity received the SDP in a SIP 770 message), and "recv" is from recipient to originator. If 771 preconditions are included in the INVITE request, the UAC MUST 772 indicate support for reliable provisional responses [12]. 774 If the UAC receives a 18x provisional response without a Content- 775 Disposition of "precondition," or without SDP, or with SDP but 776 without any qos/security preconditions in any stream, UAC treats it 777 as an indication that the UAS is unable or unwilling to perform the 779 SIP Working Group Expiration 5/31/01 14 780 SIP Extensions for Resource Management November 2000 782 preconditions requested. As such, the UAC SHOULD proceed with normal 783 call setup procedures. 785 If the 18x provisional response contained a Content-Disposition of 786 "precondition" and contained SDP with mandatory qos/security 787 parameters, the UAC SHOULD NOT let the session proceed until the 788 mandatory preconditions are met. 790 If the 18x provisional response with preconditions requested an 791 acknowledgement (using the methods of [12]), the UAC MUST include an 792 updated SDP in the PRACK if the UAC modified the original SDP based 793 on the response from the UAS. Such a modification MAY be due to 794 negotiation of compatible CODECs, or MAY be due to negotiation of 795 mandatory preconditions. If the provisional response received from 796 the UAS is a 180-Ringing, and the direction value of a mandatory 797 precondition is "sendrecv," and the UAC uses a one-way QoS mechanism 798 (such as RSVP), the updated SDP in the PRACK SHOULD request a 799 confirmation from the UAS so that the bi-directional precondition 800 can be satisfied before performing the requested alerting function. 802 Upon receipt of the 18x provisional response with preconditions, the 803 UAC MUST initiate the qos reservations and establish the security 804 associations to the best of its capabilities. 806 If the UAC had requested confirmation in the initial SDP, it MAY 807 wait for the COMET message from the UAS containing the 808 success/failure status of each precondition. The UAC MAY set a 809 local timer to limit the time waiting for preconditions to complete. 810 The UAC SHOULD merge the success/failure status in the COMET message 811 with its local status. For example, if the COMET message indicated 812 success in the "send" direction, and the UAC was also able to meet 813 the precondition in the "send" direction, they combine to meet the 814 precondition in the "sendrecv" direction. 815 If any of the mandatory preconditions cannot be met, and a 816 confirmation was not requested by the UAS, the UAC MUST send a 817 CANCEL and terminate the session. If any of the optional 818 preconditions cannot be met, the UAC MAY consult with the 819 originating customer for guidance on whether to complete the 820 session. 822 When all the preconditions have either been met or have failed, and 823 the SDP received from the UAS included a confirmation request, the 824 UAC MUST send a COMET message to the UAS with SDP, where each 825 precondition is updated to indicate success/failure and the 826 appropriate direction tag based on local operations performed 827 combined with the received COMET message, if any. 829 The session now completes normally, as per [2]. 831 8.3 Behavior of Destination (UAS) 833 On receipt of an INVITE request containing preconditions, the UAS 834 MUST generate a 18x provisional response containing a subset of the 835 preconditions supported by the UAS. In the response, the token 837 SIP Working Group Expiration 5/31/01 15 838 SIP Extensions for Resource Management November 2000 840 value "send" means the direction of the media from the UAS to the 841 UAC, and "recv" is from the UAC to the UAS. This is reversed from 842 the SDP in the initial INVITE. The 18x provisional response MUST 843 include a Content-Disposition header with parameter "precondition." 844 If the "confirm" attribute is present in the SDP received from the 845 UAC, or if the direction tag of a mandatory QoS precondition is 846 "sendrecv" and the UAS only supports a one-way QoS reservation 847 scheme (e.g. RSVP), then the UAS SHOULD include a "confirm" 848 attribute. 850 If the INVITE request did not contain any preconditions, but did 851 indicate support for reliable provisional responses[12], the UAS MAY 852 include preconditions in a 18x provisional response to the INVITE. 853 The 18x provisional response MUST include a Content-Disposition 854 header with the parameter "precondition." The 18x provisional 855 response MUST request an acknowledgement using the mechanism of 856 [12]. If the PRACK includes an SDP without any preconditions, the 857 UAS MAY complete the session without the preconditions, or MAY 858 reject the INVITE request. 860 The UAS SHOULD request an acknowledgement to the 18x provisional 861 response, using the mechanism of [12]. The UAS SHOULD wait for the 862 PRACK message before initiating resource reservation to allow the 863 resource reservation to reflect 3-way SDP negotiation, or other 864 information available only through receipt of the PRACK. 866 If the INVITE request or PRACK message contained mandatory 867 preconditions, or requested a confirmation of preconditions, the UAS 868 MUST NOT alert the called user. 870 The UAS now attempts to reserve the qos resources and establish the 871 security associations. The UAS MAY set a local timer to limit the 872 time waiting for preconditions to complete. 873 If the UAS is unable to perform any mandatory precondition, and 874 neither the UAC nor UAS requested a confirmation, the UAS MUST send 875 a 580-Precondition-Failure response to the UAC. If the UAS is 876 unable to perform any optional precondition, it MAY consult with the 877 customer to obtain guidance regarding completion of the session. 879 When processing of all preconditions is complete, if a precondition 880 in the initial INVITE specified a confirmation request, the UAS MUST 881 send a COMET message to the UAC containing SDP, along with the 882 qos/security result of success/failure for each precondition. If 883 the direction tag of the precondition was "sendrecv" but the UAS was 884 only able to ensure "send" or "recv," the direction tag in the COMET 885 MUST only indicate what the UAS ensures. The Request-URI, call-leg 886 identification, and other headers of this COMET message are to be 887 constructed identically to a BYE. 889 If the UAS had requested confirmation of a precondition in the 890 response SDP, it SHOULD wait for the COMET message from the 891 originator containing the success/failure indication of each 892 precondition from the originator's point of view. The 893 success/failure indications in the COMET message from the UAC SHOULD 895 SIP Working Group Expiration 5/31/01 16 896 SIP Extensions for Resource Management November 2000 898 be combined with the local status to determine the overall 899 success/failure of the precondition. For example, if the COMET 900 message indicated success in the "send" direction, and the UAS was 901 also able to meet the precondition in the "send" direction, they 902 combine to meet the precondition in the "sendrecv" direction. If 903 that combination indicates a failure for a mandatory precondition, 904 the UAS MUST send a 580-Precondition-Failure response to the UAC. 906 Once the preconditions are met, the UAS alerts the user, and the SIP 907 transaction proceeds normally. 909 The UAS MAY send additional 18x provisional responses with Content- 910 Disposition of "precondition," and the procedures described above 911 are repeated sequentially for each. 913 9. Examples 915 9.1 Basic (Single-Media) Call Flow 917 Figure 1 presents a high-level overview of a basic end-point to end- 918 point (UAC-UAS) call flow. This example is appropriate for a 919 single-media session with a mandatory quality-of-service "sendrecv" 920 precondition, where both the UAC and UAS can only perform a single- 921 direction ("send") resource reservation. 923 The session originator (UAC) prepares an SDP message body for the 924 INVITE describing the desired QoS and security preconditions for 925 each media flow, and the desired direction "sendrecv." This SDP is 926 included in the INVITE message sent through the proxies, and 927 includes an entry "a=qos:mandatory sendrecv." 929 The recipient of the INVITE (UAS), being willing to perform the 930 requested precondition, returns a 183-Session-Progress provisional 931 response containing SDP, along with the qos/security attribute for 932 each stream having a precondition. Since the "sendrecv" direction 933 tag required a cooperative effort of the UAC and UAS, the UAS 934 requests a confirmation when the preconditions are met, with the SDP 935 entry "a=qos:mandatory sendrecv confirm." The UAS now attempts to 936 reserve the qos resources and establish the security associations. 938 The 183-Session-Progress provisional response is sent using the 939 reliability mechanism of [12]. UAC sends the appropriate PRACK and 940 UAS responds with a 200-OK to the PRACK. 942 The 183-Session-Progress is received by the UAC, and the UAC 943 requests the resources needed in its "send" direction, and 944 establishes the security associations. Once the preconditions are 945 met, the UAC sends a COMET message as requested by the confirmation 946 token. This COMET message contains an entry "a=qos:success send" 948 SIP Working Group Expiration 5/31/01 17 949 SIP Extensions for Resource Management November 2000 951 Originating (UAC) Terminating (UAS) 952 | SIP-Proxy(s) | 953 | INVITE | | 954 |---------------------->|---------------------->| 955 | | | 956 | 183 w/SDP | 183 w/SDP | 957 |<----------------------|<----------------------| 958 | | 959 | PRACK | 960 |---------------------------------------------->| 961 | 200 OK (of PRACK) | 962 |<----------------------------------------------| 963 | Reservation Reservation | 964 ===========> <=========== 965 | | 966 | | 967 | COMET | 968 |---------------------------------------------->| 969 | 200 OK (of COMET) | 970 |<----------------------------------------------| 971 | 972 | 973 | SIP-Proxy(s) User Alerted 974 | | | 975 | 180 Ringing | 180 Ringing | 976 |<----------------------|<----------------------| 977 | | 978 | PRACK | 979 |---------------------------------------------->| 980 | 200 OK (of PRACK) | 981 |<----------------------------------------------| 982 | | 983 | User Picks-Up 984 | SIP-Proxy(s) the phone 985 | | | 986 | 200 OK | 200 OK | 987 |<----------------------|<----------------------| 988 | | | 989 | | 990 | ACK | 991 |---------------------------------------------->| 993 Figure 1: Basic Call FLow 995 The UAS successfully performs its resource reservation, in its 996 "send" direction, and waits for the COMET message from the UAC. 998 On receipt of the COMET message, the UAS combines the "send" 999 confirmation in the SDP with its "send" success, and knows all 1000 preconditions have been met. The UAS then continues with session 1001 establishment. At this point it alerts the user, and sends a 180- 1002 Ringing provisional response. This provisional response is also 1004 SIP Working Group Expiration 5/31/01 18 1005 SIP Extensions for Resource Management November 2000 1007 sent using the reliability mechanism of [12], resulting in a PRACK 1008 message and 200-OK of the PRACK. 1010 When the destination party answers, the normal SIP 200-OK final 1011 response is sent through the proxies to the originator, and the 1012 originator responds with an ACK message. 1014 Either party can terminate the call. An endpoint that detects an 1015 "on-hook" (request to terminate the call) releases the QoS resources 1016 held for the connection, and sends a SIP BYE message to the remote 1017 endpoint, which is acknowledged with a 200-OK. 1019 9.2 Advanced (Multiple-Media) Call Flow 1021 Figure 2 presents a high-level overview of an advanced end-point to 1022 end-point (UAC-UAS) call flow. This example is appropriate for a 1023 multiple-media session with some combination of mandatory and 1024 optional quality-of-service precondition. For example, the 1025 originator may suggest five media streams, and be willing to 1026 establish the session if any three of them are satisfied. 1028 The use of reliable provisional responses is assumed, but not shown 1029 in this figure. 1031 The session originator (UAC) prepares an SDP message body for the 1032 INVITE describing the desired QoS and security preconditions for 1033 each media flow, and the desired directions. UAC also requests 1034 confirmation of the preconditions. The UAS receiving the INVITE 1035 message responds with 183-Session-Progress, as in the previous 1036 example. 1038 When the UAS has completed the resource reservations and security 1039 session establishment, it sends a confirmation to the UAC in the 1040 form of a COMET message, with each precondition marked in the SDP as 1041 either success or failure. Note that if UAS was not satisfied with 1042 the combination of successful preconditions, it could instead have 1043 responded with 580-Precondition-Failure, and ended the INVITE 1044 transaction. 1046 If the UAC has satisfied its preconditions, and is satisfied with 1047 the preconditions achieved by the UAS, it responds with the COMET 1048 message. The COMET message contains the SDP with the 1049 success/failure results of each precondition attempted by UAC. If 1050 UAC is not satisfied with the combination of successful 1051 preconditions, it could instead have sent a CANCEL message. 1053 On receipt of the COMET message, UAS examines the combination of 1054 satisfied preconditions reported by UAC, and makes a final decision 1055 whether to proceed with the session. If sufficient preconditions 1056 are not satisfied, the UAS responds with 580-Precondition-Failure. 1057 Otherwise, the session proceeds as in the previous example. 1059 SIP Working Group Expiration 5/31/01 19 1060 SIP Extensions for Resource Management November 2000 1062 Originating (UAC) Terminating (UAS) 1063 | SIP-Proxy(s) | 1064 | INVITE | | 1065 |---------------------->|---------------------->| 1066 | | | 1067 | 183 w/SDP | 183 w/SDP | 1068 |<----------------------|<----------------------| 1069 | | 1070 | Reservation Reservation | 1071 ===========> <=========== 1072 | | 1073 | COMET | 1074 |<----------------------------------------------| 1075 | 200 OK (of COMET) | 1076 |---------------------------------------------->| 1077 | | 1078 | COMET | 1079 |---------------------------------------------->| 1080 | 200 OK (of COMET) | 1081 |<----------------------------------------------| 1082 | 1083 | 1084 | SIP-Proxy(s) User Alerted 1085 | | | 1086 | 180 Ringing | 180 Ringing | 1087 |<----------------------|<----------------------| 1088 | | 1089 | | 1090 | User Picks-Up 1091 | SIP-Proxy(s) the phone 1092 | | | 1093 | 200 OK | 200 OK | 1094 |<----------------------|<----------------------| 1095 | | | 1096 | | 1097 | ACK | 1098 |---------------------------------------------->| 1100 Figure 2: Call Flow with negotiation of optional preconditions 1102 10. Special considerations with Forking Proxies 1104 If a proxy along the signaling path between the UAC and UAS forks 1105 the INVITE request, it results in two or more UASs simultaneously 1106 sending provisional responses with preconditions. The procedures 1107 above result in the UAC handling each independently, reserving 1108 resources and responding with COMET messages as required. 1110 This results in multiple resource reservations from the UAC, only 1111 one of which will be utilized for the final session. While 1112 functionally correct, this has the unfortunate side-effect of 1113 increasing the call blocking probability. 1115 SIP Working Group Expiration 5/31/01 20 1116 SIP Extensions for Resource Management November 2000 1118 Customized resource allocation protocols may be used by the UAC to 1119 reduce this duplicate allocation and prevent excess blocking of 1120 calls. For one such example, see [8]. 1122 11. Advantages of the Proposed Approach 1124 The use of two-phase call signaling makes it possible for SIP to 1125 meet user expectations that come from the telephony services. 1127 The reservation of resources before the user is alerted makes sure 1128 that the network resources are assured before the destination end- 1129 point is informed about the call. 1131 The number of messages and the total delay introduced by these 1132 messages is kept to a minimum without sacrificing compatibility with 1133 SIP servers that do not implement preconditions. 1135 12. Security Considerations 1137 If the contents of the SDP contained in the 183-Session-Progress are 1138 private then end-to-end encryption of the message body can be used 1139 to prevent unauthorized access to the content. 1141 The security considerations given in the SIP specification apply to 1142 the COMET method. No additional security considerations specific to 1143 the COMET method are necessary. 1145 13. Notice Regarding Intellectual Property Rights 1147 AT&T may seek patent or other intellectual property protection for 1148 some or all of the technologies disclosed in the document. If any 1149 standards arising from this disclosure are or become protected by 1150 one or more patents assigned to AT&T, AT&T intends to disclose those 1151 patents and license them on reasonable and non-discriminatory terms. 1152 Future revisions of this draft may contain additional information 1153 regarding specific intellectual property protection sought or 1154 received. 1156 3COM may seek patent or other intellectual property protection for 1157 some or all of the technologies disclosed in the document. If any 1158 standards arising from this disclosure are or become protected by 1159 one or more patents assigned to 3COM, 3COM intends to disclose those 1160 patents and license them on reasonable and non-discriminatory terms. 1161 Future revisions of this draft may contain additional information 1162 regarding specific intellectual property protection sought or 1163 received. 1165 14. References 1167 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1168 9, RFC 2026, October 1996. 1170 SIP Working Group Expiration 5/31/01 21 1171 SIP Extensions for Resource Management November 2000 1173 2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1174 Session Initiation Protocol," RFC 2543, March 1999. 1176 3. M. Handley and V. Jacobson, "SDP: Session Description Protocol," 1177 RFC 2327, April 1998. 1179 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1180 Levels", BCP 14, RFC 2119, March 1997 1182 5. DCS Group, "Architectural Considerations for Providing Carrier 1183 Class Telephony Services Utilizing SIP-based Distributed Call 1184 Control Mechanisms", , November 1185 2000, Work in Progress. 1187 6. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1188 "Resource ReSerVation protocol (RSVP) -- version 1 functional 1189 specification," RFC 2205, September, 1997. 1191 7. P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation 1192 mechanism for the Internet," in Proc. International Workshop on 1193 Network and Operating System Support for Digital Audio and Video 1194 (NOSSDAV), (Cambridge, England), July 1998. Also IBM Research 1195 Technical Report TC20967. Available at 1196 http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz. 1198 8. PacketCable, Dynamic Quality of Service Specification, pkt-sp- 1199 dqos-i01-991201, December 1, 1999. Available at 1200 http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf. 1202 9. S. Kent and R. Atkinson, "Security architecture for the internet 1203 protocol," RFC 2401, November 1998. 1205 10. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1206 a Transport Protocol for Real-Time Applications," RFC 1889, 1207 January 1996. 1209 11. M. Handley, C. Perkins, and E. Whelan, "Session Announcement 1210 Protocol," Internet Draft, , 1211 March 2000, Work in Progress. 1213 12. "Reliability of Provisional Responses in SIP," Internet Draft 1214 , January 2000, Work in Progress. 1216 15. Acknowledgments 1218 The Distributed Call Signaling work in the PacketCable project is 1219 the work of a large number of people, representing many different 1220 companies. The authors would like to recognize and thank the 1221 following for their assistance: John Wheeler, Motorola; David 1222 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, 1223 Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido 1225 SIP Working Group Expiration 5/31/01 22 1226 SIP Extensions for Resource Management November 2000 1228 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 1229 Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, 1230 Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, 1231 AT&T; Telcordia Technologies; and Lucent Cable Communications. 1233 16. Author's Addresses 1235 Bill Marshall 1236 AT&T 1237 Florham Park, NJ 07932 1238 Email: wtm@research.att.com 1240 K. K. Ramakrishnan 1241 TeraOptic Networks 1242 Sunnyvale, CA 1243 Email: kk@teraoptic.com 1245 Ed Miller 1246 CableLabs 1247 Louisville, CO 80027 1248 Email: E.Miller@Cablelabs.com 1250 Glenn Russell 1251 CableLabs 1252 Louisville, CO 80027 1253 Email: G.Russell@Cablelabs.com 1255 Burcak Beser 1256 Pacific Broadband Communications 1257 San Jose, CA 1258 Email: Burcak@pacband.com 1260 Mike Mannette 1261 3Com 1262 Rolling Meadows, IL 60008 1263 Email: Michael_Mannette@3com.com 1265 Kurt Steinbrenner 1266 3Com 1267 Rolling Meadows, IL 60008 1268 Email: Kurt_Steinbrenner@3com.com 1270 Dave Oran 1271 Cisco 1272 Acton, MA 01720 1273 Email: oran@cisco.com 1275 Flemming Andreasen 1276 Cisco 1277 Edison, NJ 1278 Email: fandreas@cisco.com 1280 Michael Ramalho 1282 SIP Working Group Expiration 5/31/01 23 1283 SIP Extensions for Resource Management November 2000 1285 Cisco 1286 Wall Township, NJ 1287 Email: mramalho@cisco.com 1289 John Pickens 1290 Com21 1291 San Jose, CA 1292 Email: jpickens@com21.com 1294 Poornima Lalwaney 1295 Nokia 1296 San Diego, CA 92121 1297 Email: poornima.lalwaney@nokia.com 1299 Jon Fellows 1300 Motorola 1301 San Diego, CA 92121 1302 Email: jfellows@gi.com 1304 Doc Evans 1305 D. R. Evans Consulting 1306 Boulder, CO 80303 1307 Email: n7dr@arrl.net 1309 Keith Kelly 1310 NetSpeak 1311 Boca Raton, FL 33587 1312 Email: keith@netspeak.com 1314 Adam Roach 1315 Ericsson 1316 Richardson, TX 75081 1317 Email: adam.roach@ericsson.com 1319 Jonathan Rosenberg 1320 dynamicsoft 1321 West Orange, NJ 07052 1322 Email: jdrosen@dynamicsoft.com 1324 Dean Willis 1325 dynamicsoft 1326 West Orange, NJ 07052 1327 Email: dwillis@dynamicsoft.com 1329 Steve Donovan 1330 dynamicsoft 1331 West Orange, NJ 07052 1332 Email: sdonovan@dynamicsoft.com 1334 Henning Schulzrinne 1335 Columbia University 1336 New York, NY 1337 Email: schulzrinne@cs.columbia.edu 1339 SIP Working Group Expiration 5/31/01 24 1340 SIP Extensions for Resource Management November 2000 1342 Full Copyright Statement 1344 "Copyright (C) The Internet Society (2000). All Rights Reserved. 1345 This document and translations of it may be copied and furnished to 1346 others, and derivative works that comment on or otherwise explain it 1347 or assist in its implmentation may be prepared, copied, published 1348 and distributed, in whole or in part, without restriction of any 1349 kind, provided that the above copyright notice and this paragraph 1350 are included on all such copies and derivative works. However, this 1351 document itself may not be modified in any way, such as by removing 1352 the copyright notice or references to the Internet Society or other 1353 Internet organizations, except as needed for the purpose of 1354 developing Internet standards in which case the procedures for 1355 copyrights defined in the Internet Standards process must be 1356 followed, or as required to translate it into languages other than 1357 English. The limited permissions granted above are perpetual and 1358 will not be revoked by the Internet Society or its successors or 1359 assigns. This document and the information contained herein is 1360 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1361 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1362 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1363 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1366 Expiration Date This memo is filed as , and expires May 31, 2001. 1369 SIP Working Group Expiration 5/31/01 25