idnits 2.17.1 draft-ietf-sip-manyfolks-resource-03.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 2) being 59 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 500 has weird spacing: '... recv sendr...' == Line 514 has weird spacing: '...request mand...' == Line 529 has weird spacing: '...reponse send ...' == Line 544 has weird spacing: '...reponse send ...' == Line 791 has weird spacing: '... where enc e...' -- 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 63 looks like a reference -- Missing reference section? '4' on line 113 looks like a reference -- Missing reference section? '2' on line 1272 looks like a reference -- Missing reference section? '5' on line 216 looks like a reference -- Missing reference section? '6' on line 217 looks like a reference -- Missing reference section? '7' on line 222 looks like a reference -- Missing reference section? '8' on line 1268 looks like a reference -- Missing reference section? '9' on line 273 looks like a reference -- Missing reference section? '10' on line 271 looks like a reference -- Missing reference section? '3' on line 434 looks like a reference -- Missing reference section? '12' on line 827 looks like a reference -- Missing reference section? '11' on line 1156 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 8 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 Terayon 11 G. Russell 12 CableLabs 14 B. Beser 15 Pacific Broadband 17 M. Mannette 18 K. Steinbrenner 19 3Com 21 D. Oran 22 F. Andreasen 23 M. Ramalho 24 Cisco 26 J. Pickens 27 Com21 29 P. Lalwaney 30 Nokia 32 J. Fellows 33 Copper Mountain Networks 35 D. Evans 36 D. R. Evans Consulting 38 K. Kelly 39 NetSpeak 41 A. Roach 42 Ericsson 44 J. Rosenberg 45 D. Willis 46 S. Donovan 47 dynamicsoft 49 H. Schulzrinne 50 Columbia University 52 November, 2001 54 Integration of Resource Management and SIP 56 SIP Working Group Expiration 5/31/02 1 57 SIP Extensions for Resource Management November 2001 59 Status of this Memo 61 This document is an Internet-Draft and is in full conformance with 62 all provisions of Section 10 of RFC2026[1]. 64 Internet-Drafts are working documents of the Internet Engineering 65 Task Force (IETF), its areas, and its working groups. Note that 66 other groups may also distribute working documents as Internet- 67 Drafts. Internet-Drafts are draft documents valid for a maximum of 68 six months and may be updated, replaced, or obsoleted by other 69 documents at any time. It is inappropriate to use Internet- Drafts 70 as reference material or to cite them other than as "work in 71 progress." 73 The list of current Internet-Drafts can be accessed at 74 http://www.ietf.org/ietf/1id-abstracts.txt 76 The list of Internet-Draft Shadow Directories can be accessed at 77 http://www.ietf.org/shadow.html. 79 The distribution of this memo is unlimited. It is filed as , and expires May 31, 2002. 81 Please send comments to the authors. 83 1. Abstract 85 This document discusses how network QoS and security establishment 86 can be made a precondition to sessions initiated by the Session 87 Initiation Protocol (SIP), and described by SDP. These preconditions 88 require that the participant reserve network resources (or establish 89 a secure media channel) before continuing with the session. We do 90 not define new QoS reservation or security mechanisms; these pre- 91 conditions simply require a participant to use existing resource 92 reservation and security mechanisms before beginning the session. 94 This results in a multi-phase call-setup mechanism, with the 95 resource management protocol interleaved between two phases of call 96 signaling. The objective of such a mechanism is to enable deployment 97 of robust IP Telephony services, by ensuring that resources are made 98 available before the phone rings and the participants of the call 99 are "invited" to participate. 101 This document also proposes an extension to the Session Initiation 102 Protocol (SIP) to add a new COMET method, which is used to confirm 103 the completion of all pre-conditions by the session originator. 105 2. Conventions used in this document 107 SIP Working Group Expiration 5/31/02 2 108 SIP Extensions for Resource Management November 2001 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 112 this document are to be interpreted as described in RFC-2119[4]. 114 3. Table of Contents 116 Status of this Memo................................................2 117 1. Abstract........................................................2 118 2. Conventions used in this document...............................2 119 3. Table of Contents...............................................3 120 4. Introduction....................................................3 121 4.1 Requirements...................................................6 122 4.2 Overview.......................................................6 123 5. SDP Extension...................................................8 124 5.1 SDP Example....................................................9 125 5.2 SDP Allowable Combinations.....................................9 126 6. SIP Extension: The COMET Method................................11 127 6.1 Header Field Support for COMET Method.........................11 128 6.2 Responses to the COMET Request Method.........................12 129 6.3 Message Body Inclusion........................................13 130 6.4 Behavior of SIP User Agents...................................13 131 6.5 Behavior of SIP Proxy and Redirect Servers....................13 132 6.5.1 Proxy Server................................................13 133 6.5.2 Forking Proxy Server........................................14 134 6.5.3 Redirection Server..........................................14 135 7. SIP Extension: The 183-Session-Progress Response...............14 136 7.1 Status Code and Reason Phrase.................................14 137 7.2 Status Code Definition........................................14 138 8. SIP Extension: The 580-Precondition-Failure Response...........14 139 8.1 Status Code and Reason Phrase.................................14 140 8.2 Status Code Definition........................................14 141 9. SIP Extension: Content-Disposition header......................15 142 10. Option tag for Requires and Supported headers.................16 143 11. SIP Usage Rules...............................................16 144 11.1 Overview.....................................................16 145 11.2 Behavior of Originator (UAC).................................17 146 11.3 Behavior of Destination (UAS)................................18 147 12. Examples......................................................20 148 12.1 Single Media Call Flow.......................................20 149 12.2 Multiple Media Call Flow.....................................22 150 13. Special considerations with Forking Proxies...................23 151 14. Advantages of the Proposed Approach...........................24 152 15. Security Considerations.......................................24 153 16. Notice Regarding Intellectual Property Rights.................24 154 17. References....................................................24 155 18. Acknowledgments...............................................25 156 19. Author's Addresses............................................25 157 Full Copyright Statement..........................................28 159 4. Introduction 161 SIP Working Group Expiration 5/31/02 3 162 SIP Extensions for Resource Management November 2001 164 For an Internet Telephony service to be successfully used by a large 165 number of subscribers, it must offer few surprises to those 166 accustomed to the behavior of existing telephony services. One 167 expectation is that of connection quality, implying resources must 168 be set aside for each call. 170 A key contribution is a recognition of the need for coordination 171 between call signaling, which controls access to telephony specific 172 services, and resource management, which controls access to network- 173 layer resources. This coordination is designed to meet the user 174 expectations and human factors associated with telephony. 176 While customers may expect, during times of heavy load, to receive a 177 "fast busy" or an announcement saying "all circuits are busy now," 178 the general expectation is that once the destination phone rings 179 that the connection can be made. Blocking a call after ringing the 180 destination is considered a "call defect" and is a very undesirable 181 exception condition. 183 This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions. 184 A "QoS-Assured" session will complete only if all the required 185 resources are available and assigned to the session. A provider may 186 choose to block a call when adequate resources for the call are not 187 available. Public policy demands that the phone system provide 188 adequate quality at least in certain cases: e.g., for emergency 189 communications during times of disasters. Call blocking enables a 190 provider to meet such requirements. 192 A "QoS-Enabled" session allows the endpoints to complete the session 193 establishment either with or without the desired resources. Such 194 session will use dedicated resources if available, and use a best- 195 effort connection as an alternative if resources can not be 196 dedicated. In cases where resources are not available, the 197 originating and/or terminating User Agent might consult with the 198 customer to obtain guidance on whether the session should complete. 200 Coordination between call signaling and resource management is also 201 needed to prevent fraud and theft of service. The coordination 202 between call-signaling and QoS setup protocols ensures that users 203 are authenticated and authorized before receiving access to the 204 enhanced QoS associated with the telephony service. 206 This coordination, referred to in this draft as "preconditions," 207 require that the participant reserve network resources (or establish 208 a secure media channel) before continuing with the session. We do 209 not define new QoS reservation or security mechanisms; these pre- 210 conditions simply require a participant to use existing resource 211 reservation and security mechanisms before beginning the session. 213 In the case of SIP [2], this effectively means that the "phone won't 214 ring" until the preconditions are met. These preconditions are 215 described by new SDP parameters, defined in this document. The 216 parameters can mandate end-to-end QoS reservations based on RSVP [5] 217 or any other end-to-end reservation mechanism (such as YESSIR [6], 219 SIP Working Group Expiration 5/31/02 4 220 SIP Extensions for Resource Management November 2001 222 or PacketCable's Dynamic Quality of Service (D-QoS) [7]), and 223 security based on IPSEC [8]. The preconditions can be defined 224 independently for each media stream. 226 The QoS architecture of the Internet separates QoS signaling from 227 application level signaling. Application layer devices (such as web 228 proxies and SIP servers) are not well suited for participation in 229 network admission control or QoS management, as this is 230 fundamentally a network layer issue, independent of any particular 231 application. In addition, since application devices like SIP servers 232 are almost never on the "bearer path" (i.e., the network path the 233 RTP [9] takes), and since the RTP path and signaling paths can be 234 completely different (even traversing different autonomous systems), 235 these application servers are generally not capable of managing QoS 236 for the media. Keeping QoS out of application signaling also means 237 that there can be a single infrastructure for QoS across all 238 applications. This eliminates duplication of functionality, reducing 239 management and equipment costs. It also means that new applications, 240 with their own unique QoS requirements, can be easily supported. 242 This loose coupling works very well for a wide range of 243 applications. For example, in an interactive game, one can establish 244 the game using an application signaling protocol, and then later on 245 use RSVP to reserve network resources. The separation is also 246 effective for applications which have no explicit signaling. 247 However, certain applications may require tighter coupling. In the 248 case of Internet telephony, the following is an important 249 requirement: 251 When A calls B, B's phone should not ring unless resources 252 have been reserved from A to B, and B to A. 254 This could be achieved without coupling if A knew B's address, port, 255 and codecs before the telephony signaling took place. However, since 256 telephony signaling is used largely to obtain this information in 257 the first place, the coupling cannot be avoided. 259 A similar model exists for security. Rather than inventing new 260 security mechanisms for each new application, common security tools 261 (such as IPSEC) can be used across all applications. As with QoS, a 262 means in application level protocols is needed to indicate that a 263 security association is needed for the application to execute. 265 To solve both of these problems, we propose an extension to SDP 266 which allows indication of pre-conditions for sessions. These 267 preconditions indicate that participation in the session should not 268 proceed until the preconditions are met. The preconditions we define 269 are (1) success of end-to-end resource reservation, and (2) success 270 of end- to-end security establishment. We chose to implement these 271 extensions in SDP, rather than SIP [2] or SAP [10], since they are 272 fundamentally a media session issue. SIP is session agnostic; 273 information about codecs, ports, and RTP [9] are outside the scope 274 of SIP. Since it is the media sessions that the reservations and 275 security refer to, SDP is the appropriate venue for the extensions. 277 SIP Working Group Expiration 5/31/02 5 278 SIP Extensions for Resource Management November 2001 280 Furthermore, placement of the extensions in SDP rather than SIP or 281 SAP allows specification of preconditions for individual media 282 streams. For example, a multimedia lecture might require reservation 283 for the audio, but not the video (which is less important). 285 Our extensions are completely backward compatible. If a recipient 286 does not understand them, normal SIP or SAP processing will occur, 287 at no penalty of call setup latency. 289 4.1 Requirements 291 The basic motivation in this work is to meet and possibly exceed the 292 user expectations and human factors associated with telephony. 294 In this section, we briefly describe the application requirements 295 that led to the set of DCS signaling design principles. In its 296 basic implementation, DCS supports a residential telephone service 297 comparable to the local telephone services offered today. Some of 298 the requirements for resource management, in concert with call 299 signaling, are as follows: 301 The system must minimize call defects. These are situations where 302 either the call never completes, or an error occurs after the 303 destination is alerted. Requirements on call defects are typically 304 far more stringent than call blocking. Note that we expect the 305 provider and the endpoints to attempt to use lower bandwidth codecs 306 as the first line of defense against limited network capacity, and 307 to avoid blocking calls. 309 The system must minimize the post-dial-delay, which is the time 310 between the user dialing the last digit and receiving positive 311 confirmation from the network. This delay must be short enough that 312 users do not perceive a difference with post-dial delay in the 313 circuit switched network or conclude that the network connectivity 314 no longer exists. 316 Call signaling needs to provide enough information to the resource 317 management protocol so as to enable resources to be allocated in the 318 network. This typically requires most if not all of the components 319 of a packet classifier (source IP, destination IP, source port, 320 destination port, protocol) to be available for resource allocation. 322 4.2 Overview 324 For acceptable interactive voice communication it is important to 325 achieve end-to-end QoS. The end-to-end QoS assurance implies 326 achieving low packet delay and packet loss. End-to-end packet delay 327 must be small enough that it does not interfere with normal voice 328 conversations. The ITU recommends no greater than 300 ms roundtrip 329 delay for telephony service. Packet loss must be small enough to 330 not perceptibly impede voice quality or the performance of fax and 331 voice band modems. 333 SIP Working Group Expiration 5/31/02 6 334 SIP Extensions for Resource Management November 2001 336 If it is found that the network cannot guarantee end-to-end QoS 337 resources, there are two alternatives: either (1) allow call 338 signaling to proceed with high probability of excessive delay and 339 packet loss which could impair any interactive real-time 340 communication between the participants, or (2) block the call prior 341 to the called party being alerted. When calls are blocked because 342 of a lack of resources in a particular segment of the network, it is 343 highly desirable that such blocking occur before the called party 344 picks up. 346 We do expect the endpoints to attempt to use lower bandwidth codecs, 347 thereby avoiding blocking calls, as the first line of defense 348 against limited network capacity. 350 The call signaling and resource reservation must be achieved in such 351 a way that the post-dial-delay must be minimized without increasing 352 the probability of call defects. This means that the number of 353 round-trip messages must be kept at an absolute minimum and messages 354 must be sent directly end-system to end-system if possible. 356 The general idea behind the extension is simple. We define two new 357 SDP attributes, "qos" and "security". The "qos" attribute indicates 358 whether end-to-end resource reservation is optional or mandatory, 359 and in which direction (send, recv, or sendrecv). When the attribute 360 indicates mandatory, this means that the participant who has 361 received the SDP does not proceed with participation in the session 362 until resource reservation has completed in the direction indicated. 363 In this case, "not proceeding" means that the participant behaves as 364 if they had not received the SDP at all. If the attribute indicates 365 that QoS for the stream is optional, then the participant proceeds 366 normally with the session, but should reserve network resources in 367 the direction indicated, if they are capable. Absence of the "qos" 368 attribute means the participant reserves resources for this stream, 369 and proceeds normally with the session. This behavior is the normal 370 behavior for SDP. 372 Resource reservation takes place using whatever protocols 373 participants must use, based on support by their service provider. 374 If the ISP's of the various participants are using differing 375 resource reservation protocols, translation is necessary, but this 376 is done within the network, without knowledge of the participants. 378 The direction attribute indicates in which direction reservations 379 should be reserved. If "send", it means reservations should be made 380 in the direction of media flow from the session originator to 381 participants. If "recv", it means reservations should be made in the 382 direction of media flow from participants to the session originator. 383 In the case of "sendrecv", it means reservations should be made in 384 both directions. If the direction attribute is "sendrecv" but the 385 endpoints only support a single-direction resource reservation 386 protocol, then both the originator and participants cooperate to 387 ensure the agreed precondition is met. 389 SIP Working Group Expiration 5/31/02 7 390 SIP Extensions for Resource Management November 2001 392 In the case of security, the same attributes are defined - 393 optional/mandatory, and send/recv/sendrecv. Their meaning is 394 identical to the one above, except that a security association 395 should be established in the given direction. The details of the 396 security association are not signaled by SDP; these depend on the 397 Security Policy Database of the participant. 399 Either party can include a "confirm" attribute in the SDP. When the 400 "Confirm" attribute is present, the recipient sends a COMET message 401 to the sender, with SDP attached, telling the status of each 402 precondition as "success" or "failure." If the "confirm" attribute 403 is present in the SDP sent by the session originator to the 404 participant (e.g. in the SIP INVITE message), then the participant 405 sends the COMET message to the originator. If the "confirm" 406 attribute is present in the SDP sent by the recipient to the 407 originator (e.g. in a SIP response message), then the originator 408 sends the COMET message to the participant. 410 When the "Confirm" attribute is present in both the SDP sent by the 411 session originator to the participant (e.g. in the SIP INVITE 412 message), and in the SDP sent by the recipient back to the 413 originator (e.g. in a SIP response message), the session originator 414 would wait for the COMET message with the success/failure 415 notification before responding with a COMET message, and responds 416 instead with a CANCEL if a mandatory precondition is not met, or if 417 a sufficient combination of optional preconditions are not met. The 418 recipient does not wait for the COMET message from the originator 419 before sending its COMET message. 421 The "confirm" attribute is typically used if the direction attribute 422 is "sendrecv" and the originator or participant only supports a 423 single-direction resource reservation protocol. In such a case, the 424 originator (or participant) would reserve resources for one 425 direction of media flow, and send a confirmation with a direction 426 attribute of "send." The participant (or originator) would reserve 427 resources for the other direction. On receipt of the COMET message, 428 they would know that both directions have been reserved, and the 429 precondition is met. 431 5. SDP Extension 433 The formatting of the qos attribute in the Session Description 434 Protocol (SDP)[3] is described by the following BNF: 436 qos-attribute = "a=qos:" strength-tag SP direction-tag 437 [SP confirmation-tag] 438 strength-tag = ("mandatory" | "optional" | "success" | 439 "failure") 440 direction-tag = ("send" | "recv" | "sendrecv") 441 confirmation-tag = "confirm" 443 and the security attribute: 445 security-attribute = "a=secure:" SP strength-tag SP direction-tag 447 SIP Working Group Expiration 5/31/02 8 448 SIP Extensions for Resource Management November 2001 450 [SP confirmation-tag] 452 5.1 SDP Example 454 The following example shows an SDP description carried in a SIP 455 INVITE message from A to B: 457 v=0 458 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 459 s=SDP Seminar 460 c=IN IP4 224.2.17.12/127 461 t=2873397496 2873404696 462 m=audio 49170 RTP/AVP 0 463 a=qos:mandatory recv confirm 464 m=video 51372 RTP/AVP 31 465 a=secure:mandatory sendrecv 466 m=application 32416 udp wb 467 a=orient:portrait 468 a=qos:optional sendrecv 469 a=secure:optional sendrecv 471 This SDP indicates that B should not continue its involvement in the 472 session until resources for the audio are reserved from B to A, and 473 a bi-directional security association is established for the video. 474 B can join the sessions once these preconditions are met, but should 475 reserve resources and establish a bi-directional security 476 association for the whiteboard. 478 5.2 SDP Allowable Combinations 480 If the recipient of the SDP (e.g. the UAS) is capable and willing to 481 honor the precondition(s), it returns a provisional response 482 containing SDP, along with the qos/security attributes, for each 483 such stream. This SDP MUST be a subset of the preconditions 484 indicated in the INVITE. 486 Table 1 illustrates the allowed values for the direction tag in the 487 response. Each row represents a value of the direction in the SIP 488 INVITE, and each column the value in the response. An entry of N/A 489 means that this combination is not allowed. A value of A->B (B->A) 490 implies that the precondition is for resources reserved (or security 491 established) from A to B (B to A). A value of A<->B means that the 492 precondition is for resource reservation or security establishment 493 in both directions. The value in the response is the one used by 494 both parties. 496 SIP Working Group Expiration 5/31/02 9 497 SIP Extensions for Resource Management November 2001 499 B: response 500 A: request send recv sendrecv none 501 send N/A A->B N/A -- 502 recv B->A N/A N/A -- 503 sendrecv A<-B B<-A A<->B -- 504 none -- -- -- -- 506 Table 1: Allowed values of coupling 508 Table 2 illustrates the allowed values for the strength tag in the 509 request and response. A "Y" means the combination is allowed, and a 510 "N" means it is not. The value in the response is the one used by 511 both parties. 513 B: response 514 A: request mandatory optional none 515 mandatory Y Y Y 516 optional N Y Y 517 none N N Y 519 Table 2: Allowed values of strength parameter 521 Table 3 illustrates the allowed values for the direction tag in a 522 confirmation message (COMET) sent from the originator to a 523 participant, based on the value of the direction tag negotiated in 524 the initial request and response. A "Y" means the combination is 525 allowed, and a "N" means it is not and SHOULD be ignored by the 526 participant. 528 A: confirmation 529 B: reponse send recv sendrecv 530 A->B Y N N 531 A<-B N Y N 532 A<->B Y Y Y 534 Table 3: Allowed values of direction in confirmation from A 536 Table 4 illustrates the allowed values for the direction tag in a 537 confirmation message (COMET) sent from the participant to the 538 originator, based on the value of the direction tag negotiated in 539 the initial request and response. A "Y" means the combination is 540 allowed, and a "N" means it is not and SHOULD be ignored by the 541 originator. 543 B: confirmation 544 B: reponse send recv sendrecv 545 A->B N Y N 546 A<-B Y N N 547 A<->B Y Y Y 549 Table 4: Allowed values of direction in confirmation from B 551 SIP Working Group Expiration 5/31/02 10 552 SIP Extensions for Resource Management November 2001 554 6. SIP Extension: The COMET Method 556 The COMET method is used for communicating successful completion of 557 preconditions between the user agents. 559 The signaling path for the COMET method is the signaling path 560 established as a result of the call setup. This can be either 561 direct signaling between the calling and called user agents or a 562 signaling path involving SIP proxy servers that were involved in the 563 call setup and added themselves to the Record-Route header on the 564 initial INVITE message. 566 The precondition information is communicated in the message body, 567 which MUST contain an SDP. For every agreed precondition, the 568 strength-tag MUST indicate "success" or "failure". 570 If the initial request contained Record-Route headers, the 571 provisional response MUST contain a copy of those headers, as if the 572 response were a 200 OK to the initial request. Since provisional 573 responses MAY contain Record-Route and Contact headers, the COMET 574 request MUST contain Route headers, constructed as specified in [2], 575 if the Record-Route headers were present in the provisional 576 response. 578 A UAC MUST NOT insert a Route header into a COMET request if no 579 Record-Route header was present in the response. 581 If the initial request was sent with credentials, the COMET request 582 SHOULD contain those credentials as well. 584 The Call-ID in the COMET MUST match that of the provisional 585 response. The CSeq in this request MUST be larger than the last 586 request sent by this UAC for this call leg. The To, From, and Via 587 headers MUST be present, and MUST be constructed as they would be 588 for a re-INVITE or BYE as specified in [2]. In particular, if the 589 provisional response contained a tag in the To field, this tag MUST 590 be mirrored in the To field of the COMET. 592 Once the COMET request is created, it is sent by the UAC. It is sent 593 as would any other non-INVITE request for a call. In particular, 594 when sent over UDP, the COMET request is retransmitted as specified 595 in [2]. Note that a UAC SHOULD NOT retransmit the COMET request 596 when it receives a retransmission of the provisional response being 597 acknowledged, although doing so does not create a protocol error. As 598 with any other non-INVITE request, the UAC continues to retransmit 599 the COMET request until it receives a final response. 601 Use of CANCEL of a COMET is as specified in [2]. 603 6.1 Header Field Support for COMET Method 605 SIP Working Group Expiration 5/31/02 11 606 SIP Extensions for Resource Management November 2001 608 Tables 5 and 6 are extensions of tables 4 and 5 in the SIP 609 specification[2]. Refer to Section 6 of [2] for a description of 610 the content of the tables. 612 6.2 Responses to the COMET Request Method 614 If a server receives a COMET request it MUST send a final response. 616 A 200 OK response MUST be sent by a UAS for a COMET request if the 617 COMET request was successfully received for an existing call. 618 Beyond that, no additional operations are required. 620 A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a 621 UAS if the COMET request does not match any existing call leg. 623 Header Where COMET 624 ------ ----- ---- 625 Accept R o 626 Accept-Encoding R o 627 Accept-Language R o 628 Allow 200 - 629 Allow 405 o 630 Authorization R o 631 Call-ID gc m 632 Contact R o 633 Contact 1xx - 634 Contact 2xx - 635 Contact 3xx - 636 Contact 485 - 637 Content-Encoding e o 638 Content-Length e o 639 Content-Type e * 640 CSeq gc m 641 Date g o 642 Encryption g o 643 Expires g o 644 From gc m 645 Hide R o 646 Max-Forwards R o 647 Organization g o 648 Table 5 Summary of header fields, A-0 650 SIP Working Group Expiration 5/31/02 12 651 SIP Extensions for Resource Management November 2001 653 Header Where COMET 654 ------ ----- ---- 655 Priority R - 656 Proxy-Authenticate 407 o 657 Proxy-Authorization R o 658 Proxy-Require R o 659 Record-Route R o 660 Record-Route 2xx o 661 Require R o 662 Response-Key R o 663 Retry-After R - 664 Retry-After 404,480,486 o 665 Retry-After 503 o 666 Retry-After 600,603 o 667 Route R o 668 Server r o 669 Subject R o 670 Timestamp g o 671 To gc(1) m 672 Unsupported 420 o 673 User-Agent g o 674 Via gc(2) m 675 Warning r o 676 WWW-Authenticate 401 o 678 Table 6 Summary of header fields, P-Z 680 Other request failure (4xx), Server Failure (5xx) and Global Failure 681 (6xx) responses MAY be sent for the COMET Request. 683 6.3 Message Body Inclusion 685 The COMET request MUST contain a message body, with Content-type 686 "application/sdp". 688 6.4 Behavior of SIP User Agents 690 Unless stated otherwise, the protocol rules for the COMET request 691 governing the usage of tags, Route and Record-Route, retransmission 692 and reliability, CSeq incrementing and message formatting follow 693 those in [2] as defined for the BYE request. 695 A COMET request MAY be cancelled. A UAS receiving a CANCEL for a 696 COMET request SHOULD respond to the COMET with a "487 Request 697 Cancelled" response if a final response has not been sent to the 698 COMET and then behave as if the request were never received. 700 6.5 Behavior of SIP Proxy and Redirect Servers 702 6.5.1 Proxy Server 704 Unless stated otherwise, the protocol rules for the COMET request at 705 a proxy are identical to those for a BYE request as specified in 706 [2]. 708 SIP Working Group Expiration 5/31/02 13 709 SIP Extensions for Resource Management November 2001 711 6.5.2 Forking Proxy Server 713 Unless stated otherwise, the protocol rules for the COMET request at 714 a proxy are identical to those for a BYE request as specified in 715 [2]. 717 6.5.3 Redirection Server 719 Unless stated otherwise, the protocol rules for the COMET request at 720 a proxy are identical to those for a BYE request as specified in 721 [2]. 723 7. SIP Extension: The 183-Session-Progress Response 725 An additional provisional response is defined by this draft, which 726 is returned by a UAS to convey information not otherwise classified. 728 7.1 Status Code and Reason Phrase 730 The following is to be added to Figure 4 in Section 5.1.1, 731 Informational and success Status codes. 733 Informational = "183" ;Session-Progress 735 7.2 Status Code Definition 737 The following is to be added to a new section 7.1.5 739 7.1.5 183 Session Progress 741 The 183 (Session Progress) response is used to convey information 742 about the progress of the call which is not otherwise classified. 743 The Reason-Phrase MAY be used to convey more details about the call 744 progress. 746 The Session Progress response MAY contain a message body. If so, it 747 MUST contain a "Content-Disposition" header indicating the proper 748 treatment of the message body. 750 8. SIP Extension: The 580-Precondition-Failure Response 752 An additional error response is defined by this draft, which is 753 returned by a UAS if it is unable to perform the mandatory 754 preconditions for the session. 756 8.1 Status Code and Reason Phrase 758 The following is to be added to Figure 8, Server error status codes 760 Server-Error = "580" ;Precondition-Failure 762 8.2 Status Code Definition 764 SIP Working Group Expiration 5/31/02 14 765 SIP Extensions for Resource Management November 2001 767 The following is to be added to a new section 7.5.7. 769 7.5.7 580 Precondition Failure 771 The server was unable to establish the qos or security association 772 mandated by the SDP precondition. 774 The Precondition Failure response MUST contain a message body, with 775 Content-Type "application/sdp", giving the specifics of the 776 precondition that could not be met. 778 9. SIP Extension: Content-Disposition header 780 An additional entity header is defined by this draft, which is 781 returned by a UAS in a provisional response indicating preconditions 782 for the session. 784 The following is to be added to Table 3, SIP headers, in Section 3. 786 Entity-header = Content-Disposition ; Section 6.14a 788 The following entry is to be added to Table 4, Summary of header 789 fields, A-O, in Section 6. 791 where enc e-e ACK BYE CAN INV OPT REG 792 Content-Disposition e e o o - o o o 794 The following is to be added to a new section after 6.14. 796 6.14a Content-Disposition 798 Content-disposition = "Content-Disposition" ":" 799 Disposition-type *( ";" disp-param) 800 Disposition-type = "precondition" | disp-extension-token 801 Disp-extension-token = token 802 Disp-param = "handling" "=" "optional" | "required" 803 | other-handling 804 Other-handling = token 806 The Content-Disposition header field describes how the message body 807 is to be interpreted by the UAC or UAS. 809 The value "precondition" indicates the body part describes QoS 810 and/or security preconditions that SHOULD be established prior to 811 the start of the session. 813 The handling parameter, disp-param, describes how the UAC or UAS 814 should react if it receives a message body whose content type or 815 disposition type it does not understand. If the parameter has the 816 value "optional" the UAS MUST ignore the message body; if it has the 817 value "required" the UAS MUST return 415 (Unsupported Media Type). 818 If the handling parameter is missing, the value "required" is to be 819 assumed. 821 SIP Working Group Expiration 5/31/02 15 822 SIP Extensions for Resource Management November 2001 824 10. Option tag for Requires and Supported headers 826 This draft defines the option tag "precondition" for use in the 827 Require and Supported headers [12]. 829 A UAS that supports this extension MUST respond to an OPTION request 830 with a Supported header that includes the "precondition" tag. 832 A UAC MAY include a "Require: precondition" in an INVITE request if 833 it wants the session initiation to fail if the UAS does not support 834 this feature. A UAC that would respond to a failed session (if due 835 to lack of precondition support) by immediately retrying the session 836 without the preconditions, SHOULD NOT include this Require tag 837 value. 839 Presence of the precondition entries in the SDP message body of an 840 INVITE request or response indicates support of this feature. The 841 UAC or UAS MAY in addition include a "Supported: precondition" 842 header in the request or response. 844 11. SIP Usage Rules 846 11.1 Overview 848 The session originator (UAC) prepares an SDP message body for the 849 INVITE describing the desired QoS and security preconditions for 850 each media flow, and the desired directions. The token value "send" 851 means the direction of media from originator (whichever entity 852 created the SDP) to recipient (whichever entity received the SDP in 853 a SIP message), and "recv" is from recipient to originator. In an 854 INVITE, the UAC is the originator, and the UAS is the recipient. The 855 roles are reversed in the response. 857 A User Agent with an active session that desires to change the media 858 flows prepares an SDP message body for the re-INVITE describing the 859 desired QoS and security preconditions for the revised media flows 860 and the desired directions. The procedures for the re-INVITE, and 861 the subsequent message exchanges, are identical to those of an 862 initial INVITE. 864 The recipient of the INVITE (UAS) returns a 18x provisional response 865 containing a Content-Disposition of "precondition," and SDP with the 866 qos/security attribute for each stream having a precondition. The 867 preconditions in this SDP (i.e. strength tag and direction tag) are 868 equal to, or a subset of, the preconditions indicated in the INVITE. 869 The UAS would typically include a confirmation request in this SDP. 870 Unlike normal SIP processing, the UAS MUST NOT alert the called user 871 at this point. The UAS now attempts to reserve the qos resources 872 and establish the security associations. 874 The 18x provisional response is received by the UAC. If the 18x 875 contained SDP with mandatory qos/security parameters, the UAC does 876 not let the session proceed until the mandatory preconditions are 878 SIP Working Group Expiration 5/31/02 16 879 SIP Extensions for Resource Management November 2001 881 met. The UAC attempts to reserve the needed resources and establish 882 the security associations. 884 If either party requests a confirmation, a COMET message is sent to 885 that party. The COMET message contains the success/failure 886 indication for each precondition. For a precondition with a 887 direction value of "sendrecv," the COMET indicates whether the 888 sender is able to confirm both directions or only one direction. 889 Upon receipt of the COMET message, the UAC/UAS continues normal SIP 890 call handling. For a UAS this includes alerting the user and 891 sending a 180-Ringing or 200-OK response. The UAC SIP transaction 892 completes normally. 894 Note that this extension requires usage of reliable provisional 895 responses [11]. This is because the 18x contains SDP with 896 information required for the session originator to initiate 897 reservations towards the participant. 899 11.2 Behavior of Originator (UAC) 901 The session originator (UAC) MAY include QoS and security 902 preconditions (including the desired direction) for each media flow 903 in the SDP sent with the INVITE. The token value "send" means the 904 direction of media from originator (whichever entity created the 905 SDP) to recipient (whichever entity received the SDP in a SIP 906 message). The token value "recv" means the direction of media from 907 recipient to originator. If preconditions are included in the 908 INVITE request, the UAC MUST indicate support for reliable 909 provisional responses [11]. 911 If the UAC receives a 18x provisional response without a Content- 912 Disposition of "precondition," or without SDP, or with SDP but 913 without any qos/security preconditions in any stream, UAC treats it 914 as an indication that the UAS is unable or unwilling to perform the 915 preconditions requested. As such, the UAC SHOULD proceed with normal 916 call setup procedures. 918 If the 18x provisional response contained a Content-Disposition of 919 "precondition" and contained SDP with mandatory qos/security 920 parameters, the UAC SHOULD NOT let the session proceed until the 921 mandatory preconditions are met. 923 If the 18x provisional response with preconditions requested an 924 acknowledgement (using the methods of [11]), the UAC MUST include an 925 updated SDP in the PRACK if the UAC modified the original SDP based 926 on the response from the UAS. Such a modification MAY be due to 927 negotiation of compatible codecs, or MAY be due to negotiation of 928 mandatory preconditions. If the provisional response received from 929 the UAS is a 180-Ringing, and the direction value of a mandatory 930 precondition is "sendrecv," and the UAC uses a one-way QoS mechanism 931 (such as RSVP), the updated SDP in the PRACK SHOULD request a 932 confirmation from the UAS so that the bi-directional precondition 933 can be satisfied before performing the requested alerting function. 935 SIP Working Group Expiration 5/31/02 17 936 SIP Extensions for Resource Management November 2001 938 Upon receipt of the 18x provisional response with preconditions, the 939 UAC MUST initiate the qos reservations and establish the security 940 associations to the best of its capabilities. 942 If the UAC had requested confirmation in the initial SDP, it MAY 943 wait for the COMET message from the UAS containing the 944 success/failure status of each precondition. The UAC MAY set a 945 local timer to limit the time waiting for preconditions to complete. 946 The UAC SHOULD merge the success/failure status in the COMET message 947 with its local status. For example, if the COMET message indicated 948 success in the "send" direction, and the UAC was also able to meet 949 the precondition in the "send" direction, they combine to meet the 950 precondition in the "sendrecv" direction. 952 If any of the mandatory preconditions cannot be met, and a 953 confirmation was not requested by the UAS, the UAC MUST send a 954 CANCEL and terminate the session. If any of the optional 955 preconditions cannot be met, the UAC MAY consult with the 956 originating customer for guidance on whether to complete the 957 session. 959 When all the preconditions have either been met or have failed, and 960 the SDP received from the UAS included a confirmation request, the 961 UAC MUST send a COMET message to the UAS with SDP. Each 962 precondition is updated to indicate success/failure and the 963 appropriate direction tag is updated based on local operations 964 performed combined with the received COMET message, if any. 966 The session now completes normally, as per [2]. Any SDP included in 967 subsequent requests in this transaction MUST NOT change the agreed 968 media definitions (e.g. all lines in the SDP description other than 969 the precondition lines). 971 11.3 Behavior of Destination (UAS) 973 On receipt of an INVITE request containing preconditions, the UAS 974 MUST generate a 18x provisional response containing a subset of the 975 preconditions supported by the UAS. In the response, the token 976 value "send" means the direction of the media from the UAS to the 977 UAC, and "recv" is from the UAC to the UAS. This is reversed from 978 the SDP in the initial INVITE. The 18x provisional response MUST 979 include a Content-Disposition header with parameter "precondition." 980 If the "confirm" attribute is present in the SDP received from the 981 UAC, or if the direction tag of a mandatory QoS precondition is 982 "sendrecv" and the UAS only supports a one-way QoS reservation 983 scheme (e.g. RSVP), then the UAS SHOULD include a "confirm" 984 attribute. If the UAS is able to satisfy the preconditions 985 immediately, and no confirmation is requested by the UAC, then a 986 180-Ringing response is appropriate. Otherwise a 183-Session- 987 Progress response SHOULD be used. 989 If the INVITE request did not contain any preconditions, but did 990 indicate support for reliable provisional responses[11], the UAS MAY 991 include preconditions in a 18x provisional response to the INVITE. 993 SIP Working Group Expiration 5/31/02 18 994 SIP Extensions for Resource Management November 2001 996 The 18x provisional response MUST include a Content-Disposition 997 header with the parameter "precondition." The 18x provisional 998 response MUST request an acknowledgement using the mechanism of 999 [11]. If the PRACK includes an SDP without any preconditions, the 1000 UAS MAY complete the session without the preconditions, or MAY 1001 reject the INVITE request. 1003 The UAS SHOULD request an acknowledgement to the 18x provisional 1004 response, using the mechanism of [11]. The UAS SHOULD wait for the 1005 PRACK message before initiating resource reservation to allow the 1006 resource reservation to reflect 3-way SDP negotiation, or other 1007 information available only through receipt of the PRACK. 1009 If the INVITE request or PRACK message contained mandatory 1010 preconditions, or requested a confirmation of preconditions, the UAS 1011 MUST NOT alert the called user. 1013 The UAS now attempts to reserve the qos resources and establish the 1014 security associations. The UAS MAY set a local timer to limit the 1015 time waiting for preconditions to complete. 1017 If the UAS is unable to perform any mandatory precondition, and 1018 neither the UAC nor UAS requested a confirmation, the UAS MUST send 1019 a 580-Precondition-Failure response to the UAC. If the UAS is 1020 unable to perform any optional precondition, it MAY consult with the 1021 customer to obtain guidance regarding completion of the session. 1023 When processing of all preconditions is complete, if a precondition 1024 in the SDP specified a confirmation request, the UAS MUST send a 1025 COMET message to the UAC containing SDP, along with the qos/security 1026 result of success/failure for each precondition. If the direction 1027 tag of the precondition was "sendrecv" but the UAS was only able to 1028 ensure "send" or "recv," the direction tag in the COMET MUST only 1029 indicate what the UAS ensures. The Request-URI, call-leg 1030 identification, and other headers of this COMET message are to be 1031 constructed identically to a BYE. 1033 If the UAS had requested confirmation of a precondition in the 1034 response SDP, it SHOULD wait for the COMET message from the 1035 originator containing the success/failure indication of each 1036 precondition from the originator's point of view. The 1037 success/failure indications in the COMET message from the UAC SHOULD 1038 be combined with the local status to determine the overall 1039 success/failure of the precondition. For example, if the COMET 1040 message indicated success in the "send" direction, and the UAS was 1041 also able to meet the precondition in the "send" direction, they 1042 combine to meet the precondition in the "sendrecv" direction. If 1043 that combination indicates a failure for a mandatory precondition, 1044 the UAS MUST send a 580-Precondition-Failure response to the UAC. 1046 Once the preconditions are met, the UAS alerts the user, and the SIP 1047 transaction proceeds normally. 1049 SIP Working Group Expiration 5/31/02 19 1050 SIP Extensions for Resource Management November 2001 1052 The UAS MAY send additional 18x provisional responses with Content- 1053 Disposition of "precondition," and the procedures described above 1054 are repeated sequentially for each. 1056 Any SDP included in subsequent requests and responses in this 1057 transaction MUST NOT change the agreed media definitions (e.g. all 1058 lines in the SDP description other than the precondition lines). 1060 12. Examples 1062 12.1 Single Media Call Flow 1064 Figure 1 presents a high-level overview of a basic end-point to end- 1065 point (UAC-UAS) call flow. This example is appropriate for a 1066 single-media session with a mandatory quality-of-service "sendrecv" 1067 precondition, where both the UAC and UAS can only perform a single- 1068 direction ("send") resource reservation. 1070 The session originator (UAC) prepares an SDP message body for the 1071 INVITE describing the desired QoS and security preconditions for 1072 each media flow, and the desired direction "sendrecv." This SDP is 1073 included in the INVITE message sent through the proxies, and 1074 includes an entry "a=qos:mandatory sendrecv." 1076 The recipient of the INVITE (UAS), being willing to perform the 1077 requested precondition, returns a 183-Session-Progress provisional 1078 response containing SDP, along with the qos/security attribute for 1079 each stream having a precondition. Since the "sendrecv" direction 1080 tag required a cooperative effort of the UAC and UAS, the UAS 1081 requests a confirmation when the preconditions are met, with the SDP 1082 entry "a=qos:mandatory sendrecv confirm." The UAS now attempts to 1083 reserve the qos resources and establish the security associations. 1085 The 183-Session-Progress provisional response is sent using the 1086 reliability mechanism of [11]. UAC sends the appropriate PRACK and 1087 UAS responds with a 200-OK to the PRACK. 1089 The 183-Session-Progress is received by the UAC, and the UAC 1090 requests the resources needed in its "send" direction, and 1091 establishes the security associations. Once the preconditions are 1092 met, the UAC sends a COMET message as requested by the confirmation 1093 token. This COMET message contains an entry "a=qos:success send" 1095 SIP Working Group Expiration 5/31/02 20 1096 SIP Extensions for Resource Management November 2001 1098 Originating (UAC) Terminating (UAS) 1099 | SIP-Proxy(s) | 1100 | INVITE | | 1101 |---------------------->|---------------------->| 1102 | | | 1103 | 183 w/SDP | 183 w/SDP | 1104 |<----------------------|<----------------------| 1105 | | 1106 | PRACK | 1107 |---------------------------------------------->| 1108 | 200 OK (of PRACK) | 1109 |<----------------------------------------------| 1110 | Reservation Reservation | 1111 ===========> <=========== 1112 | | 1113 | | 1114 | COMET | 1115 |---------------------------------------------->| 1116 | 200 OK (of COMET) | 1117 |<----------------------------------------------| 1118 | 1119 | 1120 | SIP-Proxy(s) User Alerted 1121 | | | 1122 | 180 Ringing | 180 Ringing | 1123 |<----------------------|<----------------------| 1124 | | 1125 | PRACK | 1126 |---------------------------------------------->| 1127 | 200 OK (of PRACK) | 1128 |<----------------------------------------------| 1129 | | 1130 | User Picks-Up 1131 | SIP-Proxy(s) the phone 1132 | | | 1133 | 200 OK | 200 OK | 1134 |<----------------------|<----------------------| 1135 | | | 1136 | | 1137 | ACK | 1138 |---------------------------------------------->| 1140 Figure 1: Basic Call Flow 1142 The UAS successfully performs its resource reservation, in its 1143 "send" direction, and waits for the COMET message from the UAC. 1145 On receipt of the COMET message, the UAS processes the "send" 1146 confirmation contained in the COMET SDP. The "send" confirmation 1147 from the UAC coupled with its own "send" success, allows the UAS to 1148 determine that all preconditions have been met. The UAS then 1149 continues with session establishment. At this point it alerts the 1151 SIP Working Group Expiration 5/31/02 21 1152 SIP Extensions for Resource Management November 2001 1154 user, and sends a 180-Ringing provisional response. This 1155 provisional response is also sent using the reliability mechanism of 1156 [11], resulting in a PRACK message and 200-OK of the PRACK. 1158 When the destination party answers, the normal SIP 200-OK final 1159 response is sent through the proxies to the originator, and the 1160 originator responds with an ACK message. 1162 Either party can terminate the call. An endpoint that detects an 1163 "on-hook" (request to terminate the call) releases the QoS resources 1164 held for the connection, and sends a SIP BYE message to the remote 1165 endpoint, which is acknowledged with a 200-OK. 1167 12.2 Multiple Media Call Flow 1169 Figure 2 presents a high-level overview of an advanced end-point to 1170 end-point (UAC-UAS) call flow. This example is appropriate for a 1171 multiple-media session with some combination of mandatory and 1172 optional quality-of-service precondition. For example, the 1173 originator may suggest five media streams, and be willing to 1174 establish the session if any three of them are satisfied. 1176 The use of reliable provisional responses is assumed, but not shown 1177 in this figure. 1179 The session originator (UAC) prepares an SDP message body for the 1180 INVITE describing the desired QoS and security preconditions for 1181 each media flow, and the desired directions. UAC also requests 1182 confirmation of the preconditions. The UAS receiving the INVITE 1183 message responds with 183-Session-Progress, as in the previous 1184 example. 1186 When the UAS has completed the resource reservations and security 1187 session establishment, it sends a confirmation to the UAC in the 1188 form of a COMET message, with each precondition marked in the SDP as 1189 either success or failure. Note that if UAS was not satisfied with 1190 the combination of successful preconditions, it could instead have 1191 responded with 580-Precondition-Failure, and ended the INVITE 1192 transaction. 1194 If the UAC has satisfied its preconditions, and is satisfied with 1195 the preconditions achieved by the UAS, it responds with the COMET 1196 message. The COMET message contains the SDP with the 1197 success/failure results of each precondition attempted by UAC. If 1198 UAC is not satisfied with the combination of successful 1199 preconditions, it could instead have sent a CANCEL message. 1201 On receipt of the COMET message, UAS examines the combination of 1202 satisfied preconditions reported by UAC, and makes a final decision 1203 whether to proceed with the session. If sufficient preconditions 1204 are not satisfied, the UAS responds with 580-Precondition-Failure. 1205 Otherwise, the session proceeds as in the previous example. 1207 SIP Working Group Expiration 5/31/02 22 1208 SIP Extensions for Resource Management November 2001 1210 Originating (UAC) Terminating (UAS) 1211 | SIP-Proxy(s) | 1212 | INVITE | | 1213 |---------------------->|---------------------->| 1214 | | | 1215 | 183 w/SDP | 183 w/SDP | 1216 |<----------------------|<----------------------| 1217 | | 1218 | Reservation Reservation | 1219 ===========> <=========== 1220 | | 1221 | COMET | 1222 |<----------------------------------------------| 1223 | 200 OK (of COMET) | 1224 |---------------------------------------------->| 1225 | | 1226 | COMET | 1227 |---------------------------------------------->| 1228 | 200 OK (of COMET) | 1229 |<----------------------------------------------| 1230 | 1231 | 1232 | SIP-Proxy(s) User Alerted 1233 | | | 1234 | 180 Ringing | 180 Ringing | 1235 |<----------------------|<----------------------| 1236 | | 1237 | | 1238 | User Picks-Up 1239 | SIP-Proxy(s) the phone 1240 | | | 1241 | 200 OK | 200 OK | 1242 |<----------------------|<----------------------| 1243 | | | 1244 | | 1245 | ACK | 1246 |---------------------------------------------->| 1248 Figure 2: Call Flow with negotiation of optional preconditions 1250 13. Special considerations with Forking Proxies 1252 If a proxy along the signaling path between the UAC and UAS forks 1253 the INVITE request, it results in two or more UASs simultaneously 1254 sending provisional responses with preconditions. The procedures 1255 above result in the UAC handling each independently, reserving 1256 resources and responding with COMET messages as required. 1258 This results in multiple resource reservations from the UAC, only 1259 one of which will be utilized for the final session. While 1260 functionally correct, this has the unfortunate side-effect of 1261 increasing the call blocking probability. 1263 SIP Working Group Expiration 5/31/02 23 1264 SIP Extensions for Resource Management November 2001 1266 Customized resource allocation protocols may be used by the UAC to 1267 reduce this duplicate allocation and prevent excess blocking of 1268 calls. For one such example, see [8]. 1270 Other procedures which the UAC has available to handle multiple 1271 simultaneously active transactions (e.g. CANCEL, and BYE) are as 1272 given in [2]. 1274 14. Advantages of the Proposed Approach 1276 The use of two-phase call signaling makes it possible for SIP to 1277 meet user expectations that come from the telephony services. 1279 The reservation of resources before the user is alerted makes sure 1280 that the network resources are assured before the destination end- 1281 point is informed about the call. 1283 The number of messages and the total delay introduced by these 1284 messages is kept to a minimum without sacrificing compatibility with 1285 SIP servers that do not implement preconditions. 1287 15. Security Considerations 1289 If the contents of the SDP contained in the 183-Session-Progress are 1290 private then end-to-end encryption of the message body can be used 1291 to prevent unauthorized access to the content. 1293 The security considerations given in the SIP specification apply to 1294 the COMET method. No additional security considerations specific to 1295 the COMET method are necessary. 1297 16. Notice Regarding Intellectual Property Rights 1299 The IETF has been notified of intellectual property rights claimed 1300 in regard to some or all of the specification contained in this 1301 document. For more information consult the online list of claimed 1302 rights. 1304 17. References 1306 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1307 9, RFC 2026, October 1996. 1309 2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1310 Session Initiation Protocol," RFC 2543, March 1999. 1312 3. M. Handley and V. Jacobson, "SDP: Session Description Protocol," 1313 RFC 2327, April 1998. 1315 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1316 Levels", BCP 14, RFC 2119, March 1997 1318 SIP Working Group Expiration 5/31/02 24 1319 SIP Extensions for Resource Management November 2001 1321 5. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1322 "Resource ReSerVation protocol (RSVP) -- version 1 functional 1323 specification," RFC 2205, September, 1997. 1325 6. P. P. Pan and H. Schulzrinne, "YESSIR: A simple reservation 1326 mechanism for the Internet," in Proc. International Workshop on 1327 Network and Operating System Support for Digital Audio and Video 1328 (NOSSDAV), (Cambridge, England), July 1998. Also IBM Research 1329 Technical Report TC20967. Available at 1330 http://www.cs.columbia.edu/~hgs/papers/Pan98_YESSIR.ps.gz. 1332 7. PacketCable, Dynamic Quality of Service Specification, pkt-sp- 1333 dqos-i01-991201, December 1, 1999. Available at 1334 http://www.packetcable.com/specs/pkt-sp-dqos-i01-991202.pdf. 1336 8. S. Kent and R. Atkinson, "Security architecture for the internet 1337 protocol," RFC 2401, November 1998. 1339 9. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 1340 Transport Protocol for Real-Time Applications," RFC 1889, January 1341 1996. 1343 10. M. Handley, C. Perkins, and E. Whelan, "Session Announcement 1344 Protocol," RFC2974, October, 2000. 1346 11. "Reliability of Provisional Responses in SIP," RFC pending. 1348 12. "The SIP Supported Header," RFC pending. 1350 18. Acknowledgments 1352 The Distributed Call Signaling work in the PacketCable project is 1353 the work of a large number of people, representing many different 1354 companies. The authors would like to recognize and thank the 1355 following for their assistance: John Wheeler, Motorola; David 1356 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, 1357 Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido 1358 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 1359 Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, 1360 Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, 1361 AT&T; Telcordia Technologies; and Lucent Cable Communications. 1363 19. Author's Addresses 1365 Bill Marshall 1366 AT&T 1367 Florham Park, NJ 07932 1368 Email: wtm@research.att.com 1370 K. K. Ramakrishnan 1372 SIP Working Group Expiration 5/31/02 25 1373 SIP Extensions for Resource Management November 2001 1375 TeraOptic Networks 1376 Sunnyvale, CA 1377 Email: kk@teraoptic.com 1379 Ed Miller 1380 Terayon 1381 Louisville, CO 80027 1382 Email: E.Miller@terayon.com 1384 Glenn Russell 1385 CableLabs 1386 Louisville, CO 80027 1387 Email: G.Russell@Cablelabs.com 1389 Burcak Beser 1390 Pacific Broadband Communications 1391 San Jose, CA 1392 Email: Burcak@pacband.com 1394 Mike Mannette 1395 3Com 1396 Rolling Meadows, IL 60008 1397 Email: Michael_Mannette@3com.com 1399 Kurt Steinbrenner 1400 3Com 1401 Rolling Meadows, IL 60008 1402 Email: Kurt_Steinbrenner@3com.com 1404 Dave Oran 1405 Cisco 1406 Acton, MA 01720 1407 Email: oran@cisco.com 1409 Flemming Andreasen 1410 Cisco 1411 Edison, NJ 1412 Email: fandreas@cisco.com 1414 Michael Ramalho 1415 Cisco 1416 Wall Township, NJ 1417 Email: mramalho@cisco.com 1419 John Pickens 1420 Com21 1421 San Jose, CA 1422 Email: jpickens@com21.com 1424 Poornima Lalwaney 1425 Nokia 1426 San Diego, CA 92121 1427 Email: poornima.lalwaney@nokia.com 1429 SIP Working Group Expiration 5/31/02 26 1430 SIP Extensions for Resource Management November 2001 1432 Jon Fellows 1433 Copper Mountain Networks 1434 San Diego, CA 92121 1435 Email: jfellows@coppermountain.com 1437 Doc Evans 1438 D. R. Evans Consulting 1439 Boulder, CO 80303 1440 Email: n7dr@arrl.net 1442 Keith Kelly 1443 NetSpeak 1444 Boca Raton, FL 33587 1445 Email: keith@netspeak.com 1447 Adam Roach 1448 Ericsson 1449 Richardson, TX 75081 1450 Email: adam.roach@ericsson.com 1452 Jonathan Rosenberg 1453 dynamicsoft 1454 West Orange, NJ 07052 1455 Email: jdrosen@dynamicsoft.com 1457 Dean Willis 1458 dynamicsoft 1459 West Orange, NJ 07052 1460 Email: dwillis@dynamicsoft.com 1462 Steve Donovan 1463 dynamicsoft 1464 West Orange, NJ 07052 1465 Email: sdonovan@dynamicsoft.com 1467 Henning Schulzrinne 1468 Columbia University 1469 New York, NY 1470 Email: schulzrinne@cs.columbia.edu 1472 SIP Working Group Expiration 5/31/02 27 1473 SIP Extensions for Resource Management November 2001 1475 Full Copyright Statement 1477 "Copyright (C) The Internet Society (2000). All Rights Reserved. 1478 This document and translations of it may be copied and furnished to 1479 others, and derivative works that comment on or otherwise explain it 1480 or assist in its implementation may be prepared, copied, published 1481 and distributed, in whole or in part, without restriction of any 1482 kind, provided that the above copyright notice and this paragraph 1483 are included on all such copies and derivative works. However, this 1484 document itself may not be modified in any way, such as by removing 1485 the copyright notice or references to the Internet Society or other 1486 Internet organizations, except as needed for the purpose of 1487 developing Internet standards in which case the procedures for 1488 copyrights defined in the Internet Standards process must be 1489 followed, or as required to translate it into languages other than 1490 English. The limited permissions granted above are perpetual and 1491 will not be revoked by the Internet Society or its successors or 1492 assigns. This document and the information contained herein is 1493 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1494 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1495 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1496 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1499 Expiration Date This memo is filed as , and expires May 31, 2002. 1502 SIP Working Group Expiration 5/31/02 28