idnits 2.17.1 draft-ietf-sip-manyfolks-resource-01.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 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 43 instances of too long lines in the document, the longest one being 4 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 426 has weird spacing: '... recv sendr...' == Line 440 has weird spacing: '...request mand...' == Line 455 has weird spacing: '...reponse send ...' == Line 470 has weird spacing: '...reponse send ...' == Line 701 has weird spacing: '... where enc e...' == 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 58 looks like a reference -- Missing reference section? '4' on line 104 looks like a reference -- Missing reference section? '2' on line 855 looks like a reference -- Missing reference section? '5' on line 159 looks like a reference -- Missing reference section? '6' on line 160 looks like a reference -- Missing reference section? '7' on line 161 looks like a reference -- Missing reference section? '8' on line 1128 looks like a reference -- Missing reference section? '9' on line 212 looks like a reference -- Missing reference section? '10' on line 210 looks like a reference -- Missing reference section? '3' on line 364 looks like a reference -- Missing reference section? '12' on line 734 looks like a reference -- Missing reference section? '11' on line 1022 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. -------------------------------------------------------------------------------- 1 SIP Working Group W. Marshall 2 Internet Draft AT&T 3 Document: 4 K. Ramakrishnan 5 TeraOptic Networks 7 E. Miller 8 Terayon 10 G. Russell 11 CableLabs 13 B. Beser 14 Pacific Broadband 16 M. Mannette 17 K. Steinbrenner 18 3Com 20 D. Oran 21 F. Andreasen 22 M. Ramalho 23 Cisco 25 J. Pickens 26 Com21 28 P. Lalwaney 29 Nokia 31 J. Fellows 32 Copper Mountain Networks 34 D. Evans 35 D. R. Evans Consulting 37 K. Kelly 38 NetSpeak 40 A. Roach 41 Ericsson 43 J. Rosenberg 44 D. Willis 45 S. Donovan 46 dynamicsoft 48 H. Schulzrinne 49 Columbia University 51 February, 2001 53 Integration of Resource Management and SIP 54 Status of this Memo 56 This document is an Internet-Draft and is in full conformance with 57 all provisions of Section 10 of RFC2026[1]. 59 Internet-Drafts are working documents of the Internet Engineering 60 Task Force (IETF), its areas, and its working groups. Note that 61 other groups may also distribute working documents as Internet- 62 Drafts. Internet-Drafts are draft documents valid for a maximum of 63 six months and may be updated, replaced, or obsoleted by other 64 documents at any time. It is inappropriate to use Internet- Drafts 65 as reference material or to cite them other than as "work in 66 progress." 68 The list of current Internet-Drafts can be accessed at 69 http://www.ietf.org/ietf/1id-abstracts.txt 71 The list of Internet-Draft Shadow Directories can be accessed at 72 http://www.ietf.org/shadow.html. 74 The distribution of this memo is unlimited. It is filed as , and expires August 31, 2001. 76 Please send comments to the authors. 78 1. Abstract 80 This document discusses how network QoS and security establishment 81 can be made a precondition to sessions initiated by the Session 82 Initiation Protocol (SIP), and described by SDP. These preconditions 83 require that the participant reserve network resources (or establish 84 a secure media channel) before continuing with the session. We do 85 not define new QoS reservation or security mechanisms; these pre- 86 conditions simply require a participant to use existing resource 87 reservation and security mechanisms before beginning the session. 89 This results in a multi-phase call-setup mechanism, with the 90 resource management protocol interleaved between two phases of call 91 signaling. The objective of such a mechanism is to enable deployment 92 of robust IP Telephony services, by ensuring that resources are made 93 available before the phone rings and the participants of the call 94 are "invited" to participate. 96 This document also proposes an extension to the Session Initiation 97 Protocol (SIP) to add a new COMET method, which is used to confirm 98 the completion of all pre-conditions by the session originator. 100 2. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in RFC-2119[4]. 105 3. Introduction 107 For an Internet Telephony service to be successfully used by a large 108 number of subscribers, it must offer few surprises to those 109 accustomed to the behavior of existing telephony services. One 110 expectation is that of connection quality, implying resources must 111 be set aside for each call. 113 A key contribution is a recognition of the need for coordination 114 between call signaling, which controls access to telephony specific 115 services, and resource management, which controls access to network- 116 layer resources. This coordination is designed to meet the user 117 expectations and human factors associated with telephony. 119 While customers may expect, during times of heavy load, to receive a 120 "fast busy" or an announcement saying "all circuits are busy now," 121 the general expectation is that once the destination phone rings 122 that the connection can be made. Blocking a call after ringing the 123 destination is considered a "call defect" and is a very undesirable 124 exception condition. 126 This draft addresses both "QoS-Assured" and "QoS-Enabled" sessions. 127 A "QoS-Assured" session will complete only if all the required 128 resources are available and assigned to the session. A provider may 129 choose to block a call when adequate resources for the call are not 130 available. Public policy demands that the phone system provide 131 adequate quality at least in certain cases: e.g., for emergency 132 communications during times of disasters. Call blocking enables a 133 provider to meet such requirements. 135 A "QoS-Enabled" session allows the endpoints to complete the session 136 establishment either with or without the desired resources. Such 137 session will use dedicated resources if available, and use a best- 138 effort connection as an alternative if resources can not be 139 dedicated. In cases where resources are not available, the 140 originating and/or terminating User Agent might consult with the 141 customer to obtain guidance on whether the session should complete. 143 Coordination between call signaling and resource management is also 144 needed to prevent fraud and theft of service. The coordination 145 between call-signaling and QoS setup protocols ensures that users 146 are authenticated and authorized before receiving access to the 147 enhanced QoS associated with the telephony service. 149 This coordination, referred to in this draft as "preconditions," 150 require that the participant reserve network resources (or establish 151 a secure media channel) before continuing with the session. We do 152 not define new QoS reservation or security mechanisms; these pre- 153 conditions simply require a participant to use existing resource 154 reservation and security mechanisms before beginning the session. 156 In the case of SIP [2], this effectively means that the "phone won't 157 ring" until the preconditions are met. These preconditions are 158 described by new SDP parameters, defined in this document. The 159 parameters can mandate end-to-end QoS reservations based on RSVP [5] 160 or any other end-to-end reservation mechanism (such as YESSIR [6], 161 or PacketCable's Dynamic Quality of Service (D-QoS) [7]), and 162 security based on IPSEC [8]. The preconditions can be defined 163 independently for each media stream. 165 The QoS architecture of the Internet separates QoS signaling from 166 application level signaling. Application layer devices (such as web 167 proxies and SIP servers) are not well suited for participation in 168 network admission control or QoS management, as this is 169 fundamentally a network layer issue, independent of any particular 170 application. In addition, since application devices like SIP servers 171 are almost never on the "bearer path" (i.e., the network path the 172 RTP [9] takes), and since the RTP path and signaling paths can be 173 completely different (even traversing different autonomous systems), 174 these application servers are generally not capable of managing QoS 175 for the media. Keeping QoS out of application signaling also means 176 that there can be a single infrastructure for QoS across all 177 applications. This eliminates duplication of functionality, reducing 178 management and equipment costs. It also means that new applications, 179 with their own unique QoS requirements, can be easily supported. 181 This loose coupling works very well for a wide range of 182 applications. For example, in an interactive game, one can establish 183 the game using an application signaling protocol, and then later on 184 use RSVP to reserve network resources. The separation is also 185 effective for applications which have no explicit signaling. 186 However, certain applications may require tighter coupling. In the 187 case of Internet telephony, the following is an important 188 requirement: 190 When A calls B, B's phone should not ring unless resources 191 have been reserved from A to B, and B to A. 193 This could be achieved without coupling if A knew B's address, port, 194 and codecs before the telephony signaling took place. However, since 195 telephony signaling is used largely to obtain this information in 196 the first place, the coupling cannot be avoided. 198 A similar model exists for security. Rather than inventing new 199 security mechanisms for each new application, common security tools 200 (such as IPSEC) can be used across all applications. As with QoS, a 201 means in application level protocols is needed to indicate that a 202 security association is needed for the application to execute. 204 To solve both of these problems, we propose an extension to SDP 205 which allows indication of pre-conditions for sessions. These 206 preconditions indicate that participation in the session should not 207 proceed until the preconditions are met. The preconditions we define 208 are (1) success of end-to-end resource reservation, and (2) success 209 of end- to-end security establishment. We chose to implement these 210 extensions in SDP, rather than SIP [2] or SAP [10], since they are 211 fundamentally a media session issue. SIP is session agnostic; 212 information about codecs, ports, and RTP [9] are outside the scope 213 of SIP. Since it is the media sessions that the reservations and 214 security refer to, SDP is the appropriate venue for the extensions. 215 Furthermore, placement of the extensions in SDP rather than SIP or 216 SAP allows specification of preconditions for individual media 217 streams. For example, a multimedia lecture might require reservation 218 for the audio, but not the video (which is less important). 220 Our extensions are completely backward compatible. If a recipient 221 does not understand them, normal SIP or SAP processing will occur, 222 at no penalty of call setup latency. 224 3.1 Requirements 226 The basic motivation in this work is to meet and possibly exceed the 227 user expectations and human factors associated with telephony. 229 In this section, we briefly describe the application requirements 230 that led to the set of DCS signaling design principles. In its 231 basic implementation, DCS supports a residential telephone service 232 comparable to the local telephone services offered today. Some of 233 the requirements for resource management, in concert with call 234 signaling, are as follows: 236 The system must minimize call defects. These are situations where 237 either the call never completes, or an error occurs after the 238 destination is alerted. Requirements on call defects are typically 239 far more stringent than call blocking. Note that we expect the 240 provider and the endpoints to attempt to use lower bandwidth CODECs 241 as the first line of defense against limited network capacity, and 242 to avoid blocking calls. 244 The system must minimize the post-dial-delay, which is the time 245 between the user dialing the last digit and receiving positive 246 confirmation from the network. This delay must be short enough that 247 users do not perceive a difference with post-dial delay in the 248 circuit switched network or conclude that the network connectivity 249 no longer exists. 251 Call signaling needs to provide enough information to the resource 252 management protocol so as to enable resources to be allocated in the 253 network. This typically requires most if not all of the components 254 of a packet classifier (source IP, destination IP, source port, 255 destination port, protocol) to be available for resource allocation. 257 3.2 Overview 259 For acceptable interactive voice communication it is important to 260 achieve end-to-end QoS. The end-to-end QoS assurance implies 261 achieving low packet delay and packet loss. End-to-end packet delay 262 must be small enough that it does not interfere with normal voice 263 conversations. The ITU recommends no greater than 300 ms roundtrip 264 delay for telephony service. Packet loss must be small enough to 265 not perceptibly impede voice quality or the performance of fax and 266 voice band modems. 268 If it is found that the network cannot guarantee end-to-end QoS 269 resources, there are two alternatives: either (1) allow call 270 signaling to proceed with high probability of excessive delay and 271 packet loss which could impair any interactive real-time 272 communication between the participants, or (2) block the call prior 273 to the called party being alerted. When calls are blocked because 274 of a lack of resources in a particular segment of the network, it is 275 highly desirable that such blocking occur before the called party 276 picks up. 278 We do expect the endpoints to attempt to use lower bandwidth CODECs, 279 thereby avoiding blocking calls, as the first line of defense 280 against limited network capacity. 282 The call signaling and resource reservation must be achieved in such 283 a way that the post-dial-delay must be minimized without increasing 284 the probability of call defects. This means that the number of 285 round-trip messages must be kept at an absolute minimum and messages 286 must be sent directly end-system to end-system if possible. 288 The general idea behind the extension is simple. We define two new 289 SDP attributes, "qos" and "security". The "qos" attribute indicates 290 whether end-to-end resource reservation is optional or mandatory, 291 and in which direction (send, recv, or sendrecv). When the attribute 292 indicates mandatory, this means that the participant who has 293 received the SDP does not proceed with participation in the session 294 until resource reservation has completed in the direction indicated. 295 In this case, "not proceeding" means that the participant behaves as 296 if they had not received the SDP at all. If the attribute indicates 297 that QoS for the stream is optional, then the participant proceeds 298 normally with the session, but should reserve network resources in 299 the direction indicated, if they are capable. Absence of the "qos" 300 attribute means the participant reserves resources for this stream, 301 and proceeds normally with the session. This behavior is the normal 302 behavior for SDP. 304 Resource reservation takes place using whatever protocols 305 participants must use, based on support by their service provider. 306 If the ISP's of the various participants are using differing 307 resource reservation protocols, translation is necessary, but this 308 is done within the network, without knowledge of the participants. 310 The direction attribute indicates in which direction reservations 311 should be reserved. If "send", it means reservations should be made 312 in the direction of media flow from the session originator to 313 participants. If "recv", it means reservations should be made in the 314 direction of media flow from participants to the session originator. 316 In the case of "sendrecv", it means reservations should be made in 317 both directions. If the direction attribute is "sendrecv" but the 318 endpoints only support a single-direction resource reservation 319 protocol, then both the originator and participants cooperate to 320 ensure the agreed precondition is met. 322 In the case of security, the same attributes are defined - 323 optional/mandatory, and send/recv/sendrecv. Their meaning is 324 identical to the one above, except that a security association 325 should be established in the given direction. The details of the 326 security association are not signaled by SDP; these depend on the 327 Security Policy Database of the participant. 329 Either party can include a "confirm" attribute in the SDP. When the 330 "Confirm" attribute is present, the recipient sends a COMET message 331 to the sender, with SDP attached, telling the status of each 332 precondition as "success" or "failure." If the "confirm" attribute 333 is present in the SDP sent by the session originator to the 334 participant (e.g. in the SIP INVITE message), then the participant 335 sends the COMET message to the originator. If the "confirm" 336 attribute is present in the SDP sent by the recipient to the 337 originator (e.g. in a SIP response message), then the originator 338 sends the COMET message to the participant. 340 When the "Confirm" attribute is present in both the SDP sent by the 341 session originator to the participant (e.g. in the SIP INVITE 342 message), and in the SDP sent by the recipient back to the 343 originator (e.g. in a SIP response message), the session originator 344 would wait for the COMET message with the success/failure 345 notification before responding with a COMET message, and responds 346 instead with a CANCEL if a mandatory precondition is not met, or if 347 a sufficient combination of optional preconditions are not met. The 348 recipient does not wait for the COMET message from the originator 349 before sending its COMET message. 351 The "confirm" attribute is typically used if the direction attribute 352 is "sendrecv" and the originator or participant only supports a 353 single-direction resource reservation protocol. In such a case, the 354 originator (or participant) would reserve resources for one 355 direction of media flow, and send a confirmation with a direction 356 attribute of "send." The participant (or originator) would reserve 357 resources for the other direction. On receipt of the COMET message, 358 they would know that both directions have been reserved, and the 359 precondition is met. 361 4. SDP Extension 363 The formatting of the qos attribute in the Session Description 364 Protocol (SDP)[3] is described by the following BNF: 366 qos-attribute = "a=qos:" strength-tag SP direction-tag 367 [SP confirmation-tag] 368 strength-tag = ("mandatory" | "optional" | "success" | 369 "failure") 370 direction-tag = ("send" | "recv" | "sendrecv") 371 confirmation-tag = "confirm" 373 and the security attribute: 375 security-attribute = "a=secure:" SP strength-tag SP direction-tag 376 [SP confirmation-tag] 378 4.1 SDP Example 380 The following example shows an SDP description carried in a SIP 381 INVITE message from A to B: 383 v=0 384 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 385 s=SDP Seminar 386 i=A Seminar on the session description protocol 387 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 388 e=mjh@isi.edu (Mark Handley) 389 c=IN IP4 224.2.17.12/127 390 t=2873397496 2873404696 391 m=audio 49170 RTP/AVP 0 392 a=qos:mandatory recv confirm 393 m=video 51372 RTP/AVP 31 394 a=secure:mandatory sendrecv 395 m=application 32416 udp wb 396 a=orient:portrait 397 a=qos:optional sendrecv 398 a=secure:optional sendrecv 400 This SDP indicates that B should not continue its involvement in the 401 session until resources for the audio are reserved from B to A, and 402 a bi-directional security association is established for the video. 403 B can join the sessions once these preconditions are met, but should 404 reserve resources and establish a bi-directional security 405 association for the whiteboard. 407 4.2 SDP Allowable Combinations 409 If the recipient of the SDP (e.g. the UAS) is capable and willing to 410 honor the precondition(s), it returns a provisional response 411 containing SDP, along with the qos/security attributes, for each 412 such stream. This SDP MUST be a subset of the preconditions 413 indicated in the INVITE. 415 Table 1 illustrates the allowed values for the direction tag in the 416 response. Each row represents a value of the direction in the SIP 417 INVITE, and each column the value in the response. An entry of N/A 418 means that this combination is not allowed. A value of A->B (B->A) 419 implies that the precondition is for resources reserved (or security 420 established) from A to B (B to A). A value of A<->B means that the 421 precondition is for resource reservation or security establishment 422 in both directions. The value in the response is the one used by 423 both parties. 425 B: response 426 A: request send recv sendrecv none 427 send N/A A->B N/A -- 428 recv B->A N/A N/A -- 429 sendrecv A<-B B<-A A<->B -- 430 none -- -- -- -- 432 Table 1: Allowed values of coupling 434 Table 2 illustrates the allowed values for the strength tag in the 435 request and response. A "Y" means the combination is allowed, and a 436 "N" means it is not. The value in the response is the one used by 437 both parties. 439 B: response 440 A: request mandatory optional none 441 mandatory Y Y Y 442 optional N Y Y 443 none N N Y 445 Table 2: Allowed values of strength parameter 447 Table 3 illustrates the allowed values for the direction tag in a 448 confirmation message (COMET) sent from the originator to a 449 participant, based on the value of the direction tag negotiated in 450 the initial request and response. A "Y" means the combination is 451 allowed, and a "N" means it is not and SHOULD be ignored by the 452 participant. 454 A: confirmation 455 B: reponse send recv sendrecv 456 A->B Y N N 457 A<-B N Y N 458 A<->B Y Y Y 460 Table 3: Allowed values of direction in confirmation from A 462 Table 4 illustrates the allowed values for the direction tag in a 463 confirmation message (COMET) sent from the participant to the 464 originator, based on the value of the direction tag negotiated in 465 the initial request and response. A "Y" means the combination is 466 allowed, and a "N" means it is not and SHOULD be ignored by the 467 originator. 469 B: confirmation 470 B: reponse send recv sendrecv 471 A->B N Y N 472 A<-B Y N N 473 A<->B Y Y Y 475 Table 4: Allowed values of direction in confirmation from B 476 5. SIP Extension: The COMET Method 478 The COMET method is used for communicating successful completion of 479 preconditions between the user agents. 481 The signaling path for the COMET method is the signaling path 482 established as a result of the call setup. This can be either 483 direct signaling between the calling and called user agents or a 484 signaling path involving SIP proxy servers that were involved in the 485 call setup and added themselves to the Record-Route header on the 486 initial INVITE message. 488 The precondition information is communicated in the message body, 489 which MUST contain an SDP. For every agreed precondition, the 490 strength-tag MUST indicate "success" or "failure". 492 If the initial request contained Record-Route headers, the 493 provisional response MUST contain a copy of those headers, as if the 494 response were a 200 OK to the initial request. Since provisional 495 responses MAY contain Record-Route and Contact headers, the COMET 496 request MUST contain Route headers if the Record-Route headers were 497 present in the provisional response. The Route header is constructed 498 as specified in [2]. The Route header that is constructed from some 499 provisional response MUST NOT be placed in any other request except 500 for the COMET for that provisional response. 502 A UAC MUST NOT insert a Route header into a COMET request if no 503 Record-Route header was present in the response. 505 If the initial request was sent with credentials, the COMET request 506 SHOULD contain those credentials as well. 508 The Call-ID in the COMET MUST match that of the provisional 509 response. The CSeq in this request MUST be larger than the last 510 request sent by this UAC for this call leg. The To, From, and Via 511 headers MUST be present, and MUST be constructed as they would be 512 for a re-INVITE or BYE as specified in [2]. In particular, if the 513 provisional response contained a tag in the To field, this tag MUST 514 be mirrored in the To field of the COMET. 516 Once the COMET request is created, it is sent by the UAC. It is sent 517 as would any other non-INVITE request for a call. In particular, 518 when sent over UDP, the COMET request is retransmitted with an 519 exponentially increasing interval, starting at 500 milliseconds and 520 increasing to 4 seconds. Note that a UAC SHOULD NOT retransmit the 521 COMET request when it receives a retransmission of the provisional 522 response being acknowledged, although doing so does not create a 523 protocol error. As with any other non-INVITE request, the UAC 524 continues to retransmit the COMET request until it receives a final 525 response. 527 A COMET request MAY be cancelled. However, whilst allowed for 528 purposes of generality, usage of CANCEL with COMET is NOT 529 RECOMMENDED. 531 5.1 Header Field Support for COMET Method 533 Tables 3 and 4 are extensions of tables 4 and 5 in the SIP 534 specification[2]. Refer to Section 6 of [2] for a description of 535 the content of the tables. 537 5.2 Responses to the COMET Request Method 539 If a server receives a COMET request it MUST send a final response. 541 A 200 OK response MUST be sent by a UAS for a COMET request if the 542 COMET request was successfully received for an existing call. 543 Beyond that, no additional operations are required. 545 A 481 Call Leg/Transaction Does Not Exist message MUST be sent by a 546 UAS if the COMET request does not match any existing call leg. 548 Header Where COMET 549 ------ ----- ---- 550 Accept R o 551 Accept-Encoding R o 552 Accept-Language R o 553 Allow 200 - 554 Allow 405 o 555 Authorization R o 556 Call-ID gc m 557 Contact R o 558 Contact 1xx - 559 Contact 2xx - 560 Contact 3xx - 561 Contact 485 - 562 Content-Encoding e o 563 Content-Length e o 564 Content-Type e * 565 CSeq gc m 566 Date g o 567 Encryption g o 568 Expires g o 569 From gc m 570 Hide R o 571 Max-Forwards R o 572 Organization g o 573 Table 3 Summary of header fields, A-0 574 Header Where COMET 575 ------ ----- ---- 576 Priority R o 577 Proxy-Authenticate 407 o 578 Proxy-Authorization R o 579 Proxy-Require R o 580 Require R o 581 Retry-After R - 582 Retry-After 404,480,486 o 583 Retry-After 503 o 584 Retry-After 600,603 o 585 Response-Key R o 586 Record-Route R o 587 Record-Route 2xx o 588 Route R o 589 Server r o 590 Subject R o 591 Timestamp g o 592 To gc(1) m 593 Unsupported 420 o 594 User-Agent g o 595 Via gc(2) m 596 Warning r o 597 WWW-Authenticate 401 o 599 Table 4 Summary of header fields, P-Z 601 Other request failure (4xx), Server Failure (5xx) and Global Failure 602 (6xx) responses MAY be sent for the COMET Request. 604 5.3 Message Body Inclusion 606 The COMET request MUST contain a message body. 608 5.4 Behavior of SIP User Agents 610 Unless stated otherwise, the protocol rules for the COMET request 611 governing the usage of tags, Route and Record-Route, retransmission 612 and reliability, CSeq incrementing and message formatting follow 613 those in [2] as defined for the BYE request. 615 A COMET request MAY be cancelled. A UAS receiving a CANCEL for a 616 COMET request SHOULD respond to the COMET with a "487 Request 617 Cancelled" response if a final response has not been sent to the 618 COMET and then behave as if the request were never received. 620 5.5 Behavior of SIP Proxy and Redirect Servers 622 5.5.1 Proxy Server 624 Unless stated otherwise, the protocol rules for the COMET request at 625 a proxy are identical to those for a BYE request as specified in 626 [2]. 628 5.5.2 Forking Proxy Server 630 Unless stated otherwise, the protocol rules for the COMET request at 631 a proxy are identical to those for a BYE request as specified in 632 [2]. 634 5.5.3 Redirection Server 636 Unless stated otherwise, the protocol rules for the COMET request at 637 a proxy are identical to those for a BYE request as specified in 638 [2]. 640 6. SIP Extension: The 183-Session-Progress Response 642 An additional provisional response is defined by this draft, which 643 is returned by a UAS to convey information not otherwise classified. 645 6.1 Status Code and Reason Phrase 647 The following is to be added to Figure 4 in Section 5.1.1, 648 Informational and success Status codes. 650 Informational = "183" ;Session-Progress 652 6.2 Status Code Definition 654 The following is to be added to a new section 7.1.5 656 7.1.5 183 Session Progress 658 The 183 (Session Progress) response is used to convey information 659 about the progress of the call which is not otherwise classified. 660 The Reason-Phrase MAY be used to convey more details about the call 661 progress. 663 The Session Progress response MAY contain a message body. If so, it 664 MUST contain a "Content-Disposition" header indicating the proper 665 treatment of the message body. 667 7. SIP Extension: The 580-Precondition-Failure Response 669 An additional error response is defined by this draft, which is 670 returned by a UAS if it is unable to perform the mandatory 671 preconditions for the session. 673 7.1 Status Code and Reason Phrase 675 The following is to be added to Figure 8, Server error status codes 677 Server-Error = "580" ;Precondition-Failure 679 7.2 Status Code Definition 681 The following is to be added to a new section 7.5.7. 683 7.5.7 580 Precondition Failure 685 The server was unable to establish the qos or security association 686 mandated by the SDP precondition. 688 8. SIP Extension: Content-Disposition header 690 An additional entity header is defined by this draft, which is 691 returned by a UAS in a provisional response indicating preconditions 692 for the session. 694 The following is to be added to Table 3, SIP headers, in Section 3. 696 Entity-header = Content-Disposition ; Section 6.14a 698 The following entry is to be added to Table 4, Summary of header 699 fields, A-O, in Section 6. 701 where enc e-e ACK BYE CAN INV OPT REG 702 Content-Disposition e e o o - o o o 704 The following is to be added to a new section after 6.14. 706 6.14a Content-Disposition 708 Content-disposition = "Content-Disposition" ":" 709 Disposition-type *( ";" disp-param) 710 Disposition-type = "precondition" | disp-extension-token 711 Disp-extension-token = token 712 Disp-param = "handling" "=" "optional" | "required" 713 | other-handling 714 Other-handling = token 716 The Content-Disposition header field describes how the message body 717 is to be interpreted by the UAC or UAS. 719 The value "precondition" indicates the body part describes QoS 720 and/or security preconditions that SHOULD be established prior to 721 the start of the session. 723 The handling parameter, disp-param, describes how the UAC or UAS 724 should react if it receives a message body whose content type or 725 disposition type it does not understand. If the parameter has the 726 value "optional" the UAS MUST ignore the message body; if it has the 727 value "required" the UAS MUST return 415 (Unsupported Media Type). 728 If the handling parameter is missing, the value "required" is to be 729 assumed. 731 9. Option tag for Requires and Supported headers 733 This draft defines the option tag "precondition" for use in the 734 Require and Supported headers [12]. 736 A UAS that supports this extension MUST respond to an OPTION request 737 with a Supported header that includes the "precondition" tag. 739 A UAC MAY include a "Require: precondition" in an INVITE request if 740 it wants the session initiation to fail if the UAS does not support 741 this feature. 743 Presence of the precondition entries in the SDP message body of an 744 INVITE request or response indicates support of this feature. The 745 UAC or UAS MAY in addition include a "Supported: precondition" 746 header in the request or response. 748 10. SIP Usage Rules 750 10.1 Overview 752 The session originator (UAC) prepares an SDP message body for the 753 INVITE describing the desired QoS and security preconditions for 754 each media flow, and the desired directions. The token value "send" 755 means the direction of media from originator (whichever entity 756 created the SDP) to recipient (whichever entity received the SDP in 757 a SIP message), and "recv" is from recipient to originator. In an 758 INVITE, the UAC is the originator, and the UAS is the recipient. The 759 roles are reversed in the response. 761 The recipient of the INVITE (UAS) returns a 18x provisional response 762 containing a Content-Disposition of "precondition," and SDP with the 763 qos/security attribute for each stream having a precondition. The 764 UAS would typically include a confirmation request. This SDP is a 765 subset of the preconditions indicated in the INVITE. Unlike normal 766 SIP processing, the UAS MUST NOT alert the called user at this 767 point. The UAS now attempts to reserve the qos resources and 768 establish the security associations. 770 The 18x provisional response is received by the UAC. If the 18x 771 contained SDP with mandatory qos/security parameters, the UAC does 772 not let the session proceed until the mandatory preconditions are 773 met. The UAC attempts to reserve the needed resources and establish 774 the security associations. 776 If either party requests a confirmation, a COMET message is sent to 777 that party. The COMET message contains the success/failure 778 indication for each precondition. For a precondition with a 779 direction value of "sendrecv," the COMET indicates whether the 780 sender is able to confirm both directions or only one direction. 781 Upon receipt of the COMET message, the UAC/UAS continues normal SIP 782 call handling. For a UAS this includes alerting the user and 783 sending a 180-Ringing or 200-OK response. The UAC SIP transaction 784 completes normally. 786 Note that this extension requires usage of reliable provisional 787 responses [11]. This is because the 18x contains SDP with 788 information required for the session originator to initiate 789 reservations towards the participant. 791 10.2 Behavior of Originator (UAC) 793 The session originator (UAC) MAY include QoS and security 794 preconditions (including the desired direction) for each media flow 795 in the SDP sent with the INVITE. The token value "send" means the 796 direction of media from originator (whichever entity created the 797 SDP) to recipient (whichever entity received the SDP in a SIP 798 message). The token value "recv" means the direction of media from 799 recipient to originator. If preconditions are included in the 800 INVITE request, the UAC MUST indicate support for reliable 801 provisional responses [11]. 803 If the UAC receives a 18x provisional response without a Content- 804 Disposition of "precondition," or without SDP, or with SDP but 805 without any qos/security preconditions in any stream, UAC treats it 806 as an indication that the UAS is unable or unwilling to perform the 807 preconditions requested. As such, the UAC SHOULD proceed with normal 808 call setup procedures. 810 If the 18x provisional response contained a Content-Disposition of 811 "precondition" and contained SDP with mandatory qos/security 812 parameters, the UAC SHOULD NOT let the session proceed until the 813 mandatory preconditions are met. 815 If the 18x provisional response with preconditions requested an 816 acknowledgement (using the methods of [11]), the UAC MUST include an 817 updated SDP in the PRACK if the UAC modified the original SDP based 818 on the response from the UAS. Such a modification MAY be due to 819 negotiation of compatible CODECs, or MAY be due to negotiation of 820 mandatory preconditions. If the provisional response received from 821 the UAS is a 180-Ringing, and the direction value of a mandatory 822 precondition is "sendrecv," and the UAC uses a one-way QoS mechanism 823 (such as RSVP), the updated SDP in the PRACK SHOULD request a 824 confirmation from the UAS so that the bi-directional precondition 825 can be satisfied before performing the requested alerting function. 827 Upon receipt of the 18x provisional response with preconditions, the 828 UAC MUST initiate the qos reservations and establish the security 829 associations to the best of its capabilities. 831 If the UAC had requested confirmation in the initial SDP, it MAY 832 wait for the COMET message from the UAS containing the 833 success/failure status of each precondition. The UAC MAY set a 834 local timer to limit the time waiting for preconditions to complete. 835 The UAC SHOULD merge the success/failure status in the COMET message 836 with its local status. For example, if the COMET message indicated 837 success in the "send" direction, and the UAC was also able to meet 838 the precondition in the "send" direction, they combine to meet the 839 precondition in the "sendrecv" direction. 841 If any of the mandatory preconditions cannot be met, and a 842 confirmation was not requested by the UAS, the UAC MUST send a 843 CANCEL and terminate the session. If any of the optional 844 preconditions cannot be met, the UAC MAY consult with the 845 originating customer for guidance on whether to complete the 846 session. 848 When all the preconditions have either been met or have failed, and 849 the SDP received from the UAS included a confirmation request, the 850 UAC MUST send a COMET message to the UAS with SDP. Each 851 precondition is updated to indicate success/failure and the 852 appropriate direction tag is updated based on local operations 853 performed combined with the received COMET message, if any. 855 The session now completes normally, as per [2]. 857 10.3 Behavior of Destination (UAS) 859 On receipt of an INVITE request containing preconditions, the UAS 860 MUST generate a 18x provisional response containing a subset of the 861 preconditions supported by the UAS. In the response, the token 862 value "send" means the direction of the media from the UAS to the 863 UAC, and "recv" is from the UAC to the UAS. This is reversed from 864 the SDP in the initial INVITE. The 18x provisional response MUST 865 include a Content-Disposition header with parameter "precondition." 866 If the "confirm" attribute is present in the SDP received from the 867 UAC, or if the direction tag of a mandatory QoS precondition is 868 "sendrecv" and the UAS only supports a one-way QoS reservation 869 scheme (e.g. RSVP), then the UAS SHOULD include a "confirm" 870 attribute. If the UAS is able to satisfy the preconditions 871 immediately, and no confirmation is requested by the UAC, then a 872 180-Ringing response is appropriate. Otherwise a 183-Session- 873 Progress response SHOULD be used. 875 If the INVITE request did not contain any preconditions, but did 876 indicate support for reliable provisional responses[11], the UAS MAY 877 include preconditions in a 18x provisional response to the INVITE. 878 The 18x provisional response MUST include a Content-Disposition 879 header with the parameter "precondition." The 18x provisional 880 response MUST request an acknowledgement using the mechanism of 881 [11]. If the PRACK includes an SDP without any preconditions, the 882 UAS MAY complete the session without the preconditions, or MAY 883 reject the INVITE request. 885 The UAS SHOULD request an acknowledgement to the 18x provisional 886 response, using the mechanism of [11]. The UAS SHOULD wait for the 887 PRACK message before initiating resource reservation to allow the 888 resource reservation to reflect 3-way SDP negotiation, or other 889 information available only through receipt of the PRACK. 891 If the INVITE request or PRACK message contained mandatory 892 preconditions, or requested a confirmation of preconditions, the UAS 893 MUST NOT alert the called user. 895 The UAS now attempts to reserve the qos resources and establish the 896 security associations. The UAS MAY set a local timer to limit the 897 time waiting for preconditions to complete. 899 If the UAS is unable to perform any mandatory precondition, and 900 neither the UAC nor UAS requested a confirmation, the UAS MUST send 901 a 580-Precondition-Failure response to the UAC. If the UAS is 902 unable to perform any optional precondition, it MAY consult with the 903 customer to obtain guidance regarding completion of the session. 905 When processing of all preconditions is complete, if a precondition 906 in the initial INVITE specified a confirmation request, the UAS MUST 907 send a COMET message to the UAC containing SDP, along with the 908 qos/security result of success/failure for each precondition. If 909 the direction tag of the precondition was "sendrecv" but the UAS was 910 only able to ensure "send" or "recv," the direction tag in the COMET 911 MUST only indicate what the UAS ensures. The Request-URI, call-leg 912 identification, and other headers of this COMET message are to be 913 constructed identically to a BYE. 915 If the UAS had requested confirmation of a precondition in the 916 response SDP, it SHOULD wait for the COMET message from the 917 originator containing the success/failure indication of each 918 precondition from the originator's point of view. The 919 success/failure indications in the COMET message from the UAC SHOULD 920 be combined with the local status to determine the overall 921 success/failure of the precondition. For example, if the COMET 922 message indicated success in the "send" direction, and the UAS was 923 also able to meet the precondition in the "send" direction, they 924 combine to meet the precondition in the "sendrecv" direction. If 925 that combination indicates a failure for a mandatory precondition, 926 the UAS MUST send a 580-Precondition-Failure response to the UAC. 928 Once the preconditions are met, the UAS alerts the user, and the SIP 929 transaction proceeds normally. 931 The UAS MAY send additional 18x provisional responses with Content- 932 Disposition of "precondition," and the procedures described above 933 are repeated sequentially for each. 935 11. Examples 937 11.1 Single Media Call Flow 939 Figure 1 presents a high-level overview of a basic end-point to end- 940 point (UAC-UAS) call flow. This example is appropriate for a 941 single-media session with a mandatory quality-of-service "sendrecv" 942 precondition, where both the UAC and UAS can only perform a single- 943 direction ("send") resource reservation. 945 The session originator (UAC) prepares an SDP message body for the 946 INVITE describing the desired QoS and security preconditions for 947 each media flow, and the desired direction "sendrecv." This SDP is 948 included in the INVITE message sent through the proxies, and 949 includes an entry "a=qos:mandatory sendrecv." 950 The recipient of the INVITE (UAS), being willing to perform the 951 requested precondition, returns a 183-Session-Progress provisional 952 response containing SDP, along with the qos/security attribute for 953 each stream having a precondition. Since the "sendrecv" direction 954 tag required a cooperative effort of the UAC and UAS, the UAS 955 requests a confirmation when the preconditions are met, with the SDP 956 entry "a=qos:mandatory sendrecv confirm." The UAS now attempts to 957 reserve the qos resources and establish the security associations. 959 The 183-Session-Progress provisional response is sent using the 960 reliability mechanism of [11]. UAC sends the appropriate PRACK and 961 UAS responds with a 200-OK to the PRACK. 963 The 183-Session-Progress is received by the UAC, and the UAC 964 requests the resources needed in its "send" direction, and 965 establishes the security associations. Once the preconditions are 966 met, the UAC sends a COMET message as requested by the confirmation 967 token. This COMET message contains an entry "a=qos:success send" 968 Originating (UAC) Terminating (UAS) 969 | SIP-Proxy(s) | 970 | INVITE | | 971 |---------------------->|---------------------->| 972 | | | 973 | 183 w/SDP | 183 w/SDP | 974 |<----------------------|<----------------------| 975 | | 976 | PRACK | 977 |---------------------------------------------->| 978 | 200 OK (of PRACK) | 979 |<----------------------------------------------| 980 | Reservation Reservation | 981 ===========> <=========== 982 | | 983 | | 984 | COMET | 985 |---------------------------------------------->| 986 | 200 OK (of COMET) | 987 |<----------------------------------------------| 988 | 989 | 990 | SIP-Proxy(s) User Alerted 991 | | | 992 | 180 Ringing | 180 Ringing | 993 |<----------------------|<----------------------| 994 | | 995 | PRACK | 996 |---------------------------------------------->| 997 | 200 OK (of PRACK) | 998 |<----------------------------------------------| 999 | | 1000 | User Picks-Up 1001 | SIP-Proxy(s) the phone 1002 | | | 1003 | 200 OK | 200 OK | 1004 |<----------------------|<----------------------| 1005 | | | 1006 | | 1007 | ACK | 1008 |---------------------------------------------->| 1010 Figure 1: Basic Call FLow 1012 The UAS successfully performs its resource reservation, in its 1013 "send" direction, and waits for the COMET message from the UAC. 1015 On receipt of the COMET message, the UAS processes the "send" 1016 confirmation contained in the COMET SDP. The "send" confirmation 1017 from the UAC coupled with its own "send" success, allows the UAS to 1018 determine that all preconditions have been met. The UAS then 1019 continues with session establishment. At this point it alerts the 1020 user, and sends a 180-Ringing provisional response. This 1021 provisional response is also sent using the reliability mechanism of 1022 [11], resulting in a PRACK message and 200-OK of the PRACK. 1024 When the destination party answers, the normal SIP 200-OK final 1025 response is sent through the proxies to the originator, and the 1026 originator responds with an ACK message. 1028 Either party can terminate the call. An endpoint that detects an 1029 "on-hook" (request to terminate the call) releases the QoS resources 1030 held for the connection, and sends a SIP BYE message to the remote 1031 endpoint, which is acknowledged with a 200-OK. 1033 11.2 Multiple Media Call Flow 1035 Figure 2 presents a high-level overview of an advanced end-point to 1036 end-point (UAC-UAS) call flow. This example is appropriate for a 1037 multiple-media session with some combination of mandatory and 1038 optional quality-of-service precondition. For example, the 1039 originator may suggest five media streams, and be willing to 1040 establish the session if any three of them are satisfied. 1042 The use of reliable provisional responses is assumed, but not shown 1043 in this figure. 1045 The session originator (UAC) prepares an SDP message body for the 1046 INVITE describing the desired QoS and security preconditions for 1047 each media flow, and the desired directions. UAC also requests 1048 confirmation of the preconditions. The UAS receiving the INVITE 1049 message responds with 183-Session-Progress, as in the previous 1050 example. 1052 When the UAS has completed the resource reservations and security 1053 session establishment, it sends a confirmation to the UAC in the 1054 form of a COMET message, with each precondition marked in the SDP as 1055 either success or failure. Note that if UAS was not satisfied with 1056 the combination of successful preconditions, it could instead have 1057 responded with 580-Precondition-Failure, and ended the INVITE 1058 transaction. 1060 If the UAC has satisfied its preconditions, and is satisfied with 1061 the preconditions achieved by the UAS, it responds with the COMET 1062 message. The COMET message contains the SDP with the 1063 success/failure results of each precondition attempted by UAC. If 1064 UAC is not satisfied with the combination of successful 1065 preconditions, it could instead have sent a CANCEL message. 1067 On receipt of the COMET message, UAS examines the combination of 1068 satisfied preconditions reported by UAC, and makes a final decision 1069 whether to proceed with the session. If sufficient preconditions 1070 are not satisfied, the UAS responds with 580-Precondition-Failure. 1071 Otherwise, the session proceeds as in the previous example. 1073 Originating (UAC) Terminating (UAS) 1074 | SIP-Proxy(s) | 1075 | INVITE | | 1076 |---------------------->|---------------------->| 1077 | | | 1078 | 183 w/SDP | 183 w/SDP | 1079 |<----------------------|<----------------------| 1080 | | 1081 | Reservation Reservation | 1082 ===========> <=========== 1083 | | 1084 | COMET | 1085 |<----------------------------------------------| 1086 | 200 OK (of COMET) | 1087 |---------------------------------------------->| 1088 | | 1089 | COMET | 1090 |---------------------------------------------->| 1091 | 200 OK (of COMET) | 1092 |<----------------------------------------------| 1093 | 1094 | 1095 | SIP-Proxy(s) User Alerted 1096 | | | 1097 | 180 Ringing | 180 Ringing | 1098 |<----------------------|<----------------------| 1099 | | 1100 | | 1101 | User Picks-Up 1102 | SIP-Proxy(s) the phone 1103 | | | 1104 | 200 OK | 200 OK | 1105 |<----------------------|<----------------------| 1106 | | | 1107 | | 1108 | ACK | 1109 |---------------------------------------------->| 1111 Figure 2: Call Flow with negotiation of optional preconditions 1113 12. Special considerations with Forking Proxies 1115 If a proxy along the signaling path between the UAC and UAS forks 1116 the INVITE request, it results in two or more UASs simultaneously 1117 sending provisional responses with preconditions. The procedures 1118 above result in the UAC handling each independently, reserving 1119 resources and responding with COMET messages as required. 1121 This results in multiple resource reservations from the UAC, only 1122 one of which will be utilized for the final session. While 1123 functionally correct, this has the unfortunate side-effect of 1124 increasing the call blocking probability. 1126 Customized resource allocation protocols may be used by the UAC to 1127 reduce this duplicate allocation and prevent excess blocking of 1128 calls. For one such example, see [8]. 1130 13. Advantages of the Proposed Approach 1132 The use of two-phase call signaling makes it possible for SIP to 1133 meet user expectations that come from the telephony services. 1135 The reservation of resources before the user is alerted makes sure 1136 that the network resources are assured before the destination end- 1137 point is informed about the call. 1139 The number of messages and the total delay introduced by these 1140 messages is kept to a minimum without sacrificing compatibility with 1141 SIP servers that do not implement preconditions. 1143 14. Security Considerations 1145 If the contents of the SDP contained in the 183-Session-Progress are 1146 private then end-to-end encryption of the message body can be used 1147 to prevent unauthorized access to the content. 1149 The security considerations given in the SIP specification apply to 1150 the COMET method. No additional security considerations specific to 1151 the COMET method are necessary. 1153 15. Notice Regarding Intellectual Property Rights 1155 AT&T may seek patent or other intellectual property protection for 1156 some or all of the technologies disclosed in the document. If any 1157 standards arising from this disclosure are or become protected by 1158 one or more patents assigned to AT&T, AT&T intends to disclose those 1159 patents and license them on reasonable and non-discriminatory terms. 1160 Future revisions of this draft may contain additional information 1161 regarding specific intellectual property protection sought or 1162 received. 1164 3COM may seek patent or other intellectual property protection for 1165 some or all of the technologies disclosed in the document. If any 1166 standards arising from this disclosure are or become protected by 1167 one or more patents assigned to 3COM, 3COM intends to disclose those 1168 patents and license them on reasonable and non-discriminatory terms. 1169 Future revisions of this draft may contain additional information 1170 regarding specific intellectual property protection sought or 1171 received. 1173 16. References 1175 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1176 9, RFC 2026, October 1996. 1178 2. M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1179 Session Initiation Protocol," RFC 2543, March 1999. 1181 3. M. Handley and V. Jacobson, "SDP: Session Description Protocol," 1182 RFC 2327, April 1998. 1184 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement 1185 Levels", BCP 14, RFC 2119, March 1997 1187 5. 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 6. 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 7. 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 8. S. Kent and R. Atkinson, "Security architecture for the internet 1203 protocol," RFC 2401, November 1998. 1205 9. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 1206 Transport Protocol for Real-Time Applications," RFC 1889, January 1207 1996. 1209 10. M. Handley, C. Perkins, and E. Whelan, "Session Announcement 1210 Protocol," RFC2974, October, 2000. 1212 11. "Reliability of Provisional Responses in SIP," RFC pending. 1214 12. "The SIP Supported Header," RFC pending. 1216 17. 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 1224 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 1225 Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, 1226 Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, 1227 AT&T; Telcordia Technologies; and Lucent Cable Communications. 1229 18. Author's Addresses 1231 Bill Marshall 1232 AT&T 1233 Florham Park, NJ 07932 1234 Email: wtm@research.att.com 1236 K. K. Ramakrishnan 1237 TeraOptic Networks 1238 Sunnyvale, CA 1239 Email: kk@teraoptic.com 1241 Ed Miller 1242 Terayon 1243 Louisville, CO 80027 1244 Email: E.Miller@terayon.com 1246 Glenn Russell 1247 CableLabs 1248 Louisville, CO 80027 1249 Email: G.Russell@Cablelabs.com 1251 Burcak Beser 1252 Pacific Broadband Communications 1253 San Jose, CA 1254 Email: Burcak@pacband.com 1256 Mike Mannette 1257 3Com 1258 Rolling Meadows, IL 60008 1259 Email: Michael_Mannette@3com.com 1261 Kurt Steinbrenner 1262 3Com 1263 Rolling Meadows, IL 60008 1264 Email: Kurt_Steinbrenner@3com.com 1266 Dave Oran 1267 Cisco 1268 Acton, MA 01720 1269 Email: oran@cisco.com 1271 Flemming Andreasen 1272 Cisco 1273 Edison, NJ 1274 Email: fandreas@cisco.com 1276 Michael Ramalho 1277 Cisco 1278 Wall Township, NJ 1279 Email: mramalho@cisco.com 1281 John Pickens 1282 Com21 1283 San Jose, CA 1284 Email: jpickens@com21.com 1286 Poornima Lalwaney 1287 Nokia 1288 San Diego, CA 92121 1289 Email: poornima.lalwaney@nokia.com 1291 Jon Fellows 1292 Copper Mountain Networks 1293 San Diego, CA 92121 1294 Email: jfellows@coppermountain.com 1296 Doc Evans 1297 D. R. Evans Consulting 1298 Boulder, CO 80303 1299 Email: n7dr@arrl.net 1301 Keith Kelly 1302 NetSpeak 1303 Boca Raton, FL 33587 1304 Email: keith@netspeak.com 1306 Adam Roach 1307 Ericsson 1308 Richardson, TX 75081 1309 Email: adam.roach@ericsson.com 1311 Jonathan Rosenberg 1312 dynamicsoft 1313 West Orange, NJ 07052 1314 Email: jdrosen@dynamicsoft.com 1316 Dean Willis 1317 dynamicsoft 1318 West Orange, NJ 07052 1319 Email: dwillis@dynamicsoft.com 1321 Steve Donovan 1322 dynamicsoft 1323 West Orange, NJ 07052 1324 Email: sdonovan@dynamicsoft.com 1326 Henning Schulzrinne 1327 Columbia University 1328 New York, NY 1329 Email: schulzrinne@cs.columbia.edu 1330 Full Copyright Statement 1332 "Copyright (C) The Internet Society (2000). All Rights Reserved. 1333 This document and translations of it may be copied and furnished to 1334 others, and derivative works that comment on or otherwise explain it 1335 or assist in its implmentation may be prepared, copied, published 1336 and distributed, in whole or in part, without restriction of any 1337 kind, provided that the above copyright notice and this paragraph 1338 are included on all such copies and derivative works. However, this 1339 document itself may not be modified in any way, such as by removing 1340 the copyright notice or references to the Internet Society or other 1341 Internet organizations, except as needed for the purpose of 1342 developing Internet standards in which case the procedures for 1343 copyrights defined in the Internet Standards process must be 1344 followed, or as required to translate it into languages other than 1345 English. The limited permissions granted above are perpetual and 1346 will not be revoked by the Internet Society or its successors or 1347 assigns. This document and the information contained herein is 1348 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1349 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1350 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1351 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1352 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1354 Expiration Date This memo is filed as , and expires August 31, 2001.