idnits 2.17.1 draft-ietf-sip-call-auth-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 9) being 62 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.) ** There are 112 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 45 looks like a reference -- Missing reference section? '2' on line 78 looks like a reference -- Missing reference section? '3' on line 111 looks like a reference -- Missing reference section? '4' on line 127 looks like a reference -- Missing reference section? '7' on line 182 looks like a reference -- Missing reference section? '5' on line 405 looks like a reference -- Missing reference section? '6' on line 409 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 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 G. Russell 9 CableLabs 11 B. Beser 12 Pacific Broadband 14 M. Mannette 15 K. Steinbrenner 16 3Com 18 D. Oran 19 F. Andreasen 20 Cisco 22 J. Pickens 23 Com21 25 P. Lalwaney 26 Nokia 28 J. Fellows 29 Motorola 31 D. Evans 32 D. R. Evans Consulting 34 K. Kelly 35 NetSpeak 37 November, 2000 39 SIP Extensions for Media Authorization 41 Status of this Memo 43 This document is an Internet-Draft and is in full conformance with all 44 provisions of Section 10 of RFC2026 [1]. 46 Internet-Drafts are working documents of the Internet Engineering Task 47 Force (IETF), its areas, and its working groups. Note that other groups 48 may also distribute working documents as Internet-Drafts. Internet-Drafts 49 are draft documents valid for a maximum of six months and may be updated, 50 replaced, or obsoleted by other documents at any time. It is 51 inappropriate to use Internet- Drafts as reference material or to cite 52 them other than as "work in progress." 54 SIP Working Group Expiration 5/31/01 1 55 SIP Extensions for Media Authorization November 2000 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/ietf/1id-abstracts.txt 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html. 63 The distribution of this memo is unlimited. It is filed as , and expires May 31, 2001. Please send comments to 65 the authors. 67 1. Abstract 69 This document describes the need for call authorization and offers a 70 mechanism for call authorization that can be used for admission control 71 and against denial of service attacks. 73 2. Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC-2119 [2]. 79 3. Background and Motivation 81 The current IP Telephony systems consider a perfect world in which there 82 is unlimited amount of bandwidth and network layer QoS comes free. The 83 reality is that bandwidth is neither unlimited nor free. Enhanced quality 84 of service, as required for high-grade voice communication, needs special 85 authorization for better than 'best-effort' service. Without such a 86 capability, it is possible that a single berserk IP telephony device can 87 cause denial of service to a significant number of others. 89 4. Overview 91 Integration of Media Authorization and Call Signaling architecture 92 consists of User Agents (UAs) which are considered untrusted, and SIP- 93 Proxy which authorizes the call that is initiated by UA. 95 The SIP-Proxy authorizes the Media data flow to/from the UA and returns 96 to the UA a Media-Authorization-Token, which is to be used for 97 authorization when bandwidth is requested for the data-stream. 99 When the UA is ready to send the media data-stream to the other end- 100 point, it first requests bandwidth, using the Authorization-Token it 101 received from its SIP-Proxy. 103 5. Changes to SIP to Support Media Authorization 105 This document extends SIP in support of an authorization scheme. In this 106 architecture the SIP-Proxy supplies the UA an Authorization-Token which 107 is to be used for bandwidth requests. The extension defined allows 108 network resources to be authorized by the SIP-Proxy. 110 The following syntax specification uses the augmented Backus-Naur Form 111 (BNF) as described in RFC-2234 [3]. 112 SIP Working Group Expiration 5/31/01 2 113 SIP Extensions for Media Authorization November 2000 115 5.1 SIP Header Extension 117 The Media-Auth-Token general header conveys an identifier of the local 118 Gate to a UA. This information is used for authorizing the Media Stream. 120 Media-Auth = "Media- Authorization" ":" 121 Media-Authorization-Token 123 Media-Authorization-Token = 1*hex 125 5.2 SIP Procedures 127 This section defines a SIP [4] profile for usage in Media Authorization 128 compatible systems from the point of view of Authorizing Calls. 130 The initial SIP INVITE message, as well as mid-call resource change 131 messages and mid-call changes in call destination should be authorized. 132 These SIP messages are sent through the proxies to receive this 133 authorization. 135 5.2.1. User Agent Client (UAC) 137 The Media-Auth-Token, contained in the Media-Authorization header, is 138 included in the first response message sent by the SIP-Proxy to the UAC. 140 The UAC SHOULD use the Media-Auth-Token when requesting bandwidth for 141 Media data stream during initiation and retaining of the bandwidth. 143 5.2.2. User Agent Server (UAS) 145 The User Agent Server receives the Media-Auth-Token in the INVITE message 146 from SIP-Proxy. 148 The UAS SHOULD use the Media-Auth-Token when requesting bandwidth for 149 media data stream during initiation and retaining of the bandwidth. 151 5.2.3. Originating Proxy (OP) 153 The Originating Proxy (OP) authenticates the caller, and verifies the 154 caller is authorized to receive the requested level of QoS. In 155 cooperation with originating Policy Decision Point (PDP-o), the OP 156 obtains a Media-Auth-Token that contains sufficient information for the 157 UAC to get the authorized bandwidth for the media streams. 159 The Originating Proxy MUST insert the Media-Authorization header in the 160 response message that it sends to UAC. 162 5.2.4. Destination Proxy (DP) 164 The Destination Proxy (DP) authenticates the called party, and verifies 165 the called party is authorized to receive the requested level of QoS. In 166 cooperation with termination Policy Decision Point (PDP-t), the DP 168 SIP Working Group Expiration 5/31/01 3 169 SIP Extensions for Media Authorization November 2000 171 obtains a Media-Auth-Token that contains sufficient information for the 172 destination server to get the authorized bandwidth for the media streams. 174 The Destination Proxy MUST insert the Media-Authorization header in the 175 INVITE message that it sends to the UAS. 177 6. Examples 179 6.1. Requesting Bandwidth via RSVP messaging 181 Resource Reservation Protocol (RSVP) is the end-to-end Layer 3 182 reservation protocol that is widely used [7]. 184 6.1.1. User Agent Client Side 186 Figure 1 presents a high-level overview of a basic call flow with Media 187 Authorization from the viewpoint of the UAC. It is assumed that the SIP- 188 Proxy has a previously established authentication relationship with the 189 client. 191 When a user goes off-hook and dials a telephone number, the UAC collects 192 the dialed digits and sends the initial INVITE message to Originating 193 SIP-Proxy. 195 The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 196 message to the proper SIP-proxy. 198 Assuming that the call is not forwarded, the other end-point sends a 183 199 response to the initial INVITE, forwarded back to OP. Included in this 200 response is the negotiated bandwidth requirement for the connection. 202 When OP receives the 183, it has sufficient information regarding the 203 end-points, bandwidth and characteristics of the media exchange. It 204 initiates a Policy-Setup message to POP-o. 206 The PDP-o stores the authorized Media description in its local store 207 generates an Authorization-Token that points to this description and 208 returns the Authorization-Token to OP. 210 SIP Working Group Expiration 5/31/01 4 211 SIP Extensions for Media Authorization November 2000 213 UAC ER-o PDP-o OP 214 | Invite | | | Client Authentication 215 |------------------------------------------->| and Call Authorization 216 | | | | Invite 217 | | | |--------------> 218 | | | | 180/3 219 | | | Auth. Profile |<-------------- 220 | | |<--------------| 221 | | | Auth. Token | 222 | | |-------------->| Auth. Token put into 223 | | | 180/3 | Media-Authorization header 224 |<-------------------------------------------| extension. 225 |Copies the RSVP policy object | 226 |from the Media-Authorization | 227 | RSVP-PATHo | | | 228 |----------->| REQ | | 229 | |-------------->| Using the Auth-Token and Authorized 230 | | DEC | Profile that is set by the SIP Proxy 231 | |<--------------| the PDP makes the decision 232 | | | | RSVP-PATHo 233 | |------------------------------------------------> 234 | | | | RSVP-PATHt 235 |<-------------------------------------------------------------- 236 |Copies the RSVP policy object | 237 |from the Media-Authorization | 238 | RSVP-RESVt | | | 239 |----------->| REQ | | 240 | |-------------->| Using the Auth-Token and Authorized 241 | | DEC | Profile that is set by the SIP Proxy 242 | |<--------------| the PDP makes the decision 243 | | | | RSVP-RESVt 244 | |---------------------------------------------------> 245 | | | | RSVP-RESVo 246 |<---------------------------------------------------------------- 247 | | | | RSVP-RESVCONFo 248 |----------------------------------------------------------------> 249 | | | | RSVP-RESVCONFt 250 |<---------------------------------------------------------------- 251 | | | | 200 OK 252 |<-------------------------------------------|<------------------ 253 | | | | MEDIA 254 |<===============================================================> 255 | | | | ACK 256 |----------------------------------------------------------------> 258 Figure 1 260 SIP Working Group Expiration 5/31/01 5 261 SIP Extensions for Media Authorization November 2000 263 The OP includes the Authorization-Token in the Media-Auth-Token header 264 extension of the 183 message. 266 The UAC upon reception stores the Media-Authorization-Token inside the 267 Media-Auth-Token header extension. 269 Before sending the Media stream, the UAC requests bandwidth using an 270 RSVP-PATH message which includes the Session info that describes the 271 Media data-stream and TSpec that describes the bandwidth requested along 272 with Authorization information that was stored in Media-Authorization- 273 Token. 275 ERo, upon reception of the RSVP-PATHo message checks the authorization 276 through a PDP-o COPS message exchange. The PDPo checks the authorization 277 using the stored authorized Media description that was linked to 278 Authorization-Token that it returned to OP. If authorization is 279 successful PDPo returns an "install" Decision. 281 ERo checks the admissibility for the call and if admission succeeds, it 282 forwards the RSVP-PATHo message. 284 Once UAC receives the RSVP-PATHt message it sends RSVP-RESVt message to 285 reserve the bandwidth. 287 ERo, upon reception of the RSVP-RESVt message checks the authorization 288 through a PDPo COPS message exchange. The PDPo checks the authorization 289 using the stored authorized Media description that was linked to 290 Authorization-Token that it returned to OP. If authorization is 291 successful PDPo returns an "install" Decision. 293 ERo checks the admissibility for the call and if admission succeeds, it 294 forwards the RSVP-RESVt message. 296 Upon reception of RSVP-RESVo message the UAC sends RSVP-RESVCONFo message 297 to indicate that the reservation completed for one direction. 299 Upon reception of both RSVP-RESVCONFt and 200OK the UAC returns ACK 300 message. 302 6.1.2. User Agent Server Side 304 Figure 2 presents a high-level overview of a call flow with Media 305 Authorization from the viewpoint of the UAS. It is assumed that the SIP- 306 Proxy has a previously established authentication relationship with the 307 client. 309 Since the Destination SIP-Proxy (DP) has sufficient information regarding 310 the end-points, bandwidth and characteristics of the media exchange, it 311 initiates a Policy-Setup message to the termination Policy Decision Point 312 (PDPt). 314 SIP Working Group Expiration 5/31/01 6 315 SIP Extensions for Media Authorization November 2000 317 UAS ERt PDPt DP 318 | | | | Invite 319 | | | |<-------------- 320 | | | | Proxy Authentication 321 | | | Auth. Profile | and Call Authorization 322 | | |<--------------| 323 | | | Auth. Token | 324 | | |-------------->| Auth. Token put into 325 | | | Invite | Media-Authorization header 326 |<------------------------------------------| extension 327 | 180/3 | | | 328 |------------------------------------------>| 180/3 329 |Copies the RSVP policy object |--------------> 330 |from the Media-Authorization | 331 | RSVP-PATHt| | | 332 |---------->| REQ | | 333 | |-------------->| Using the Auth-Token and Authorized 334 | | DEC | Profile that is set by the SIP Proxy 335 | |<--------------| the PDP makes the decision 336 | | | | RSVP-PATHt 337 | |--------------------------------------------------> 338 | | | | RSVP-PATHo 339 |<-------------------------------------------------------------- 340 |Copies the RSVP policy object | 341 |from the Media-Authorization | 342 | RSVP-RESVo| | | 343 |---------->| | | 344 | | REQ | | 345 | |-------------->| Using the Auth-Token and Authorized 346 | | DEC | Profile that is set by the SIP Proxy 347 | |<--------------| the PDP makes the decision 348 | | | | RSVP-RESVo 349 | |---------------------------------------------------> 350 | | | | RSVP-RESVt 351 |<--------------------------------------------------------------- 352 | | | | RSVP-RESVCONFt 353 |---------------------------------------------------------------> 354 | | | | RSVP-RESVCONFo 355 |<--------------------------------------------------------------- 356 | | | | 200 OK 357 |-----------------------------------------> |-------------------> 358 | | | | ACK 359 |<---------------------------------------------------------------- 360 Figure 2 362 SIP Working Group Expiration 5/31/01 7 363 SIP Extensions for Media Authorization November 2000 365 The PDP-t stores the authorized Media description in its local store 366 generates an Authorization-Token that points to this description and 367 returns the Authorization-Token to DP. 369 Assuming that the call is not forwarded, the UAS sends a 183 response to 370 the initial INVITE message, which is forwarded back to UAC. At the same 371 time UAS sends RSVP-PATHt message for Media data-stream that includes the 372 Session info that describes the Media data-stream and TSpec that 373 describes the bandwidth requested along with Authorization information 374 that was stored in Media-Authorization-Token. 376 ERt, upon reception of the RSVP-PATHt message checks the authorization 377 through a PDPt COPS message exchange. The PDPt checks the authorization 378 using the stored authorized Media description that was linked to 379 Authorization-Token that it returned to DP. If authorization is 380 successful PDPt returns an "install" Decision. 382 ERt checks the admissibility for the call and if admission succeeds, it 383 forwards the RSVP-PATHt message. 385 Once the UAS receives the RSVP-PATHo message, it sends RSVP-RESVo message 386 to reserve the bandwidth. 388 ERt, upon reception of the RSVP-RESVo message, checks the authorization 389 through a PDPt COPS message exchange. The PDPt checks the authorization 390 using the stored authorized Media description that was linked to 391 Authorization-Token that it returned to DP. If authorization is 392 successful PDPt returns an "install" Decision. 394 ERt checks the admissibility for the call and if admission succeeds, it 395 forwards the RSVP-RESVo message. 397 Upon reception of RSVP-RESVo message the UAS sends RSVP-RESVCONFt message 398 to indicate that the reservation completed for one direction. 400 Upon reception of both RSVP-RESVCONFo and 200OK the UAS returns ACK 401 message. 403 6.2. Requesting Bandwidth via DOCSIS MAC messaging 405 The DOCSIS MAC layer [5] QoS Set-Up the call flows are different in the 406 sense that the Authorization token is a simple 32bit number [6]. And DSA- 407 REQ, DSA-RSP, and DSA-ACK are layer 2 messages that are specific to and 408 optimized for Cable environment which simplifies/reduces delays for the 409 embedded client implementation [6]. 411 SIP Working Group Expiration 5/31/01 8 412 SIP Extensions for Media Authorization November 2000 414 UAC ER/CMTSo OP 415 | Invite | | 416 |------------------------------------------->| Client Authentication 417 | | |and Call Authorization 418 | | | 419 | | | Invite 420 | | |-----------> 421 | | | 422 | | | 180/3 OK 423 | | |<------------ 424 | | | 425 | | Gate-Setup | 426 | |<--------------------- | 427 | | Gate-Setup-Ack | 428 | |---------------------> | 429 | | | GateID put into 430 | | | Media-Authorization header 431 | | | extension 432 | | 180/3 OK | 433 |<-------------------------------------------| 434 |Copies the GAteID object | 435 |from the Media-Authorization | 436 | | | 437 | DSA-REQ | | 438 |------------------->| | 439 | | Using the GateID and the Profile 440 | | communicated during Gate-Setup 441 | | the CMTS honors the request and creates 442 | DSA-RSP | a scheduler with appropriate settings 443 |<-------------------| | 444 | | | 445 | DSA-ACK | | 446 |------------------->| | 447 | | | 449 Figure 3 451 6.2.1. User Agent Client Side 453 Figure 3 presents a high-level overview of a call flow with Media 454 Authorization from the viewpoint of the UAC. It is assumed that the SIP- 455 Proxy has a previously established authentication relationship with the 456 client. 458 When a user goes off-hook and dials a telephone number, the originating 459 SIP Client (UAC) collects the dialed digits and sends the initial INVITE 460 message to Originating SIP-Proxy. 462 The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 463 message to the proper destination SIP-proxy. 465 Assuming that the call is not forwarded, the other end-point sends a 183 466 response to the initial INVITE, forwarded back to OP. Included in this 467 response is the negotiated bandwidth requirement for the connection. 469 SIP Working Group Expiration 5/31/01 9 470 SIP Extensions for Media Authorization November 2000 472 When OP receives the 183, it has sufficient information regarding the 473 end-points, bandwidth and characteristics of the media exchange. It sends 474 a Gate-Setup message to ER/CMTSo containing Media data-stream description 475 and bandwidth characteristics. The ER/CMTSo returns a 32 bit index value 476 that inside ER/CMTSo points to Media definition that OP send out. 478 UAC sends DSA-REQ message asking for bandwidth, which includes the 32 bit 479 index value. 481 ER/CMTSo, upon reception of the RSA-REQ message uses the index value to 482 find the authorized media description. Checks the requested media link 483 against authorized if the both authorization and admission succeeds it 484 starts a layer 2 link for Media data-stream on the Cable Access link and 485 returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. 487 Upon reception of 200OK the UAC returns ACK message. 489 6.2.2. User Agent Server Side 491 Figure 4 presents a high-level overview of a basic call flow with Media 492 Authorization from the viewpoint of the UAS. It is assumed that the 493 Destination SIP-Proxy (DP) has a previously established authentication 494 relationship with the UAS. 496 When DP receives the INVITE message, it has sufficient information 497 regarding the end-points, bandwidth and characteristics of the media 498 exchange. It sends a Gate-Setup message to ER/CMTSt containing Media 499 data-stream description and bandwidth characteristics. The ER/CMTSt 500 returns a 32 bit index value that inside ER/CMTSt points to Media 501 definition that DP send out. 503 The DP includes the 32 bit index value in the Media-Auth-Token header 504 extension that its including into the INVITE message. 506 The UAS sends a 183 response to the initial INVITE, which is forwarded 507 back to UAC. At the same time UAS sends DSA-REQ message asking for 508 bandwidth which includes the 32 bit index value. 510 ER/CMTSt, upon reception of the RSA-REQ message uses the index value to 511 find the authorized media description. Checks the requested media link 512 against authorized if the both authorization and admission succeeds it 513 starts a layer 2 link for Media data-stream on the Cable Access link and 514 returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. Upon 515 reception of DSA-RSP the UAS returns ACK message. 517 SIP Working Group Expiration 5/31/01 10 518 SIP Extensions for Media Authorization November 2000 520 UAS ER/CMTSt DP 521 | | | 522 | | | Invite 523 | | |<----------- 524 | | | Proxy Authentication 525 | | | and Call Authorization 526 | | Gate-Setup | 527 | |<----------------------| 528 | | Gate-Setup-Ack | 529 | |---------------------->| 530 | | | GateID put into 531 | | | Media-Authorization header 532 | | | extension 533 | Invite | | 534 |<-------------------------------------------| 535 | | | 536 | | 180/3 | 537 |------------------------------------------->| 538 | | | 180/3 539 | | |------------> 540 |Copies the GateID object | 541 |from the Media-Authorization | 542 | | | 543 | DSA-REQ | 544 |------------------->| 545 | | Using the GateID and the Profile 546 | | communicated during Gate-Setup 547 | | the CMTS honors the request and creates 548 | DSA-RSP | a scheduler with appropriate settings 549 |<-------------------| 550 | | 551 | DSA-ACK | | 552 |------------------->| | 553 | | | 554 | | 200 OK | 555 |------------------------------------------->| 556 | | | 200 OK 557 | | |------------> 559 Figure 4 561 SIP Working Group Expiration 5/31/01 11 562 SIP Extensions for Media Authorization November 2000 564 7. Advantages of the Proposed Approach 566 The use of call authorization makes it possible to control the 567 utilization of network resources. This in turn makes IP Telephony more 568 robust against denial of service attacks and various kinds of service 569 frauds. 571 Using the authorization capability, the service provider can control the 572 number of flows, the amount of bandwidth, and the end-point reached 573 making the IP Telephony system dependable in the presence of scarce 574 resources. 576 8. Security Considerations 578 Media Authorization Tokens sent from a SIP-Proxy to a UAC/UAS MUST be 579 protected from eavesdropping, through a mechanism such as IPSec. 581 9. Notice Regarding Intellectual Property Rights 583 AT&T may seek patent or other intellectual property protection for some 584 or all of the technologies disclosed in the document. If any standards 585 arising from this disclosure are or become protected by one or more 586 patents assigned to AT&T, AT&T intends to disclose those patents and 587 license them on reasonable and non-discriminatory terms. Future revisions 588 of this draft may contain additional information regarding specific 589 intellectual property protection sought or received. 591 3COM may seek patent or other intellectual property protection for some 592 or all of the technologies disclosed in the document. If any standards 593 arising from this disclosure are or become protected by one or more 594 patents assigned to 3COM, 3COM intends to disclose those patents and 595 license them on reasonable and non-discriminatory terms. Future revisions 596 of this draft may contain additional information regarding specific 597 intellectual property protection sought or received. 599 10. Reference 601 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 602 RFC 2026, October 1996. 604 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 605 Levels", BCP 14, RFC 2119, March 1997 607 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 608 Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon 609 Internet Ltd., November 1997 611 4 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 612 session initiation protocol,"Request for Comments (Proposed 613 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 615 SIP Working Group Expiration 5/31/01 12 616 SIP Extensions for Media Authorization November 2000 618 5 CableLabs, "Data-Over-Cable Service Interface Specifications, Radio 619 Frequency Interface Specification, SP-RFIv1.1-I04-000407", April 2000. 621 6 PacketCable, Dynamic Quality of Service Specification, pkt-sp-dqos- 622 i01-991201, December 1, 1999. 624 7 Wroclawski, J, RFC 2210, The Use of RSVP with IETF Integrated 625 Services, RFC2210, September 1997. 627 11. Acknowledgments 629 The Distributed Call Signaling work in the PacketCable project is 630 the work of a large number of people, representing many different 631 companies. The authors would like to recognize and thank the 632 following for their assistance: John Wheeler, Motorola; David 633 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 634 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 635 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 636 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 637 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 638 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 639 Cable Communications. 641 13. Author's Addresses 643 Bill Marshall 644 AT&T 645 Florham Park, NJ 07932 646 Email: wtm@research.att.com 648 K. K. Ramakrishnan 649 TeraOptic Networks 650 Summit, NJ 07901 651 Email: kk@teraoptic.com 653 Ed Miller 654 CableLabs 655 Louisville, CO 80027 656 Email: E.Miller@Cablelabs.com 658 Glenn Russell 659 CableLabs 660 Louisville, CO 80027 661 Email: G.Russell@Cablelabs.com 663 Burcak Beser 664 Pacific Broadband Communications 665 San Jose, CA 666 Email: Burcak@pacband.com 668 Mike Mannette 669 3Com 670 SIP Working Group Expiration 5/31/01 13 671 SIP Extensions for Media Authorization November 2000 673 Rolling Meadows, IL 60008 674 Email: Michael_Mannette@3com.com 676 Kurt Steinbrenner 677 3Com 678 Rolling Meadows, IL 60008 679 Email: Kurt_Steinbrenner@3com.com 681 Dave Oran 682 Cisco 683 Acton, MA 01720 684 Email: oran@cisco.com 686 Flemming Andreasen 687 Cisco 688 Edison, NJ 689 Email: fandreas@cisco.com 691 John Pickens 692 Com21 693 San Jose, CA 694 Email: jpickens@com21.com 696 Poornima Lalwaney 697 Nokia 698 San Diego, CA 92121 699 Email: poornima.lalwaney@nokia.com 701 Jon Fellows 702 Motorola 703 San Diego, CA 92121 704 Email: jfellows@gi.com 706 Doc Evans 707 D. R. Evans Consulting 708 Boulder, CO 80303 709 Email: n7dr@arrl.net 711 Keith Kelly 712 NetSpeak 713 Boca Raton, FL 33587 714 Email: keith@netspeak.com 716 SIP Working Group Expiration 5/31/01 14 717 SIP Extensions for Media Authorization November 2000 719 Full Copyright Statement 721 "Copyright (C) The Internet Society (date). All Rights Reserved. 722 This document and translations of it may be copied and furnished to 723 others, and derivative works that comment on or otherwise explain it 724 or assist in its implmentation may be prepared, copied, published 725 and distributed, in whole or in part, without restriction of any 726 kind, provided that the above copyright notice and this paragraph 727 are included on all such copies and derivative works. However, this 728 document itself may not be modified in any way, such as by removing 729 the copyright notice or references to the Internet Society or other 730 Internet organizations, except as needed for the purpose of 731 developing Internet standards in which case the procedures for 732 copyrights defined in the Internet Standards process must be 733 followed, or as required to translate it into languages other than 734 English. The limited permissions granted above are perpetual and 735 will not be revoked by the Internet Society or its successors or 736 assigns. This document and the information contained herein is 737 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 738 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 739 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 740 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 741 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 743 Expiration Date This memo is filed as , and expires May 31, 2001. 746 SIP Working Group Expiration 5/31/01 15