idnits 2.17.1 draft-ietf-sip-call-auth-02.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 11 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 110 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 47 looks like a reference -- Missing reference section? '2' on line 79 looks like a reference -- Missing reference section? '3' on line 115 looks like a reference -- Missing reference section? '4' on line 129 looks like a reference -- Missing reference section? '8' on line 188 looks like a reference -- Missing reference section? '7' on line 199 looks like a reference -- Missing reference section? '5' on line 421 looks like a reference -- Missing reference section? '6' on line 425 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 Cisco 24 J. Pickens 25 Com21 27 P. Lalwaney 28 Nokia 30 J. Fellows 31 Copper Mountain Networks 33 D. Evans 34 D. R. Evans Consulting 36 K. Kelly 37 NetSpeak 39 August, 2001 41 SIP Extensions for Media Authorization 43 Status of this Memo 45 This document is an Internet-Draft and is in full conformance with all 46 provisions of Section 10 of RFC2026 [1]. 48 Internet-Drafts are working documents of the Internet Engineering Task 49 Force (IETF), its areas, and its working groups. Note that other groups 50 may also distribute working documents as Internet-Drafts. Internet-Drafts 51 are draft documents valid for a maximum of six months and may be updated, 52 replaced, or obsoleted by other documents at any time. It is 53 inappropriate to use Internet- Drafts as reference material or to cite 54 them other than as "work in progress." 55 SIP Working Group Expiration 2/28/02 1 56 SIP Extensions for Media Authorization August 2001 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html. 64 The distribution of this memo is unlimited. It is filed as , and expires February 28, 2002. Please send 66 comments to the authors. 68 1. Abstract 70 This document describes the need for call authorization and offers a 71 mechanism for call authorization that can be used for admission control 72 and against denial of service attacks. 74 2. Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC-2119 [2]. 80 3. Background and Motivation 82 The current IP Telephony systems consider a perfect world in which there 83 is unlimited amount of bandwidth and network layer QoS comes free. The 84 reality is that bandwidth is neither unlimited nor free. Enhanced quality 85 of service, as required for high-grade voice communication, needs special 86 authorization for better than 'best-effort' service. Without such a 87 capability, it is possible that a single berserk IP telephony device can 88 cause denial of service to a significant number of others. 90 4. Overview 92 Integration of Media Authorization and Call Signaling architecture 93 consists of User Agents (UAs) which are considered untrusted, and SIP- 94 Proxy which authorizes the call that is initiated by UA. 96 The SIP-Proxy authorizes the Media data flow to/from the UA and returns 97 to the UA a Media-Authorization-Token, which is to be used for 98 authorization when bandwidth is requested for the data-stream. 100 When the UA is ready to send the media data-stream to the other end- 101 point, it first requests bandwidth, using the Authorization-Token it 102 received from its SIP-Proxy. 104 5. Changes to SIP to Support Media Authorization 106 This document extends SIP in support of an authorization scheme. In this 107 architecture the SIP-Proxy supplies the UA an Authorization-Token which 108 is to be used for bandwidth requests. The extension defined allows 109 network resources to be authorized by the SIP-Proxy. 111 SIP Working Group Expiration 2/28/02 2 112 SIP Extensions for Media Authorization August 2001 114 The following syntax specification uses the augmented Backus-Naur Form 115 (BNF) as described in RFC-2234 [3]. 117 5.1 SIP Header Extension 119 The Media-Auth-Token general header conveys an identifier of the local 120 Gate to a UA. This information is used for authorizing the Media Stream. 122 Media-Auth = "Media-Authorization" ":" 123 Media-Authorization-Token 125 Media-Authorization-Token = 1*hex 127 5.2 SIP Procedures 129 This section defines a SIP [4] profile for usage in Media Authorization 130 compatible systems from the point of view of Authorizing Calls. 132 The initial SIP INVITE message, as well as mid-call resource change 133 messages and mid-call changes in call destination should be authorized. 134 These SIP messages are sent through the proxies to receive this 135 authorization. 137 5.2.1. User Agent Client (UAC) 139 The Media-Auth-Token, contained in the Media-Authorization header, is 140 included in the first response message sent by the SIP-Proxy to the UAC. 142 The UAC SHOULD use the Media-Authorization-Token when requesting 143 bandwidth for Media data stream during initiation and retaining of the 144 bandwidth. The UAC converts the string of hex digits into binary, and 145 utilizes the result as a Policy-Element as defined in RFC2750[8]. This 146 Policy-Element would typically contain the authorizing entity and 147 credentials, and be used in an RSVP request for media data stream 148 resources. 150 5.2.2. User Agent Server (UAS) 152 The User Agent Server receives the Media-Authorization-Token in the 153 INVITE message from SIP-Proxy. 155 The UAS SHOULD use the Media-Authorization-Token when requesting 156 bandwidth for media data stream during initiation and retaining of the 157 bandwidth. The UAS converts the string of hex digits into binary, and 158 utilizes the result as a Policy-Element as defined in RFC2750[8]. This 159 Policy-Element would typically contain the authorizing entity and 160 credentials, and be used in an RSVP request for media data stream 161 resources. 163 5.2.3. Originating Proxy (OP) 165 The Originating Proxy (OP) authenticates the caller, and verifies the 166 caller is authorized to receive the requested level of QoS. In 167 cooperation with originating Policy Decision Point (PDP-o), the OP 168 obtains and/or generates a Media-Authorization-Token that contains 169 SIP Working Group Expiration 2/28/02 3 170 SIP Extensions for Media Authorization August 2001 172 sufficient information for the UAC to get the authorized bandwidth for 173 the media streams. The Media-Authorization-Token is formatted as a 174 Policy-Element, as defined in RFC2750[8], and converted to a string of 175 hex digits. 177 The Originating Proxy MUST insert the Media-Authorization header in the 178 response message that it sends to UAC. 180 5.2.4. Destination Proxy (DP) 182 The Destination Proxy (DP) authenticates the called party, and verifies 183 the called party is authorized to receive the requested level of QoS. In 184 cooperation with termination Policy Decision Point (PDP-t), the DP 185 obtains and/or generates a Media-Authorization-Token that contains 186 sufficient information for the destination server to get the authorized 187 bandwidth for the media streams. The Media-Authorization-Token is 188 formatted as a Policy-Element, as defined in RFC2750[8], and converted to 189 a string of hex digits. 191 The Destination Proxy MUST insert the Media-Authorization header in the 192 INVITE message that it sends to the UAS. 194 6. Examples 196 6.1. Requesting Bandwidth via RSVP messaging 198 Resource Reservation Protocol (RSVP) is the end-to-end Layer 3 199 reservation protocol that is widely used [7]. 201 6.1.1. User Agent Client Side 203 Figure 1 presents a high-level overview of a basic call flow with Media 204 Authorization from the viewpoint of the UAC. It is assumed that the SIP- 205 Proxy has a previously established authentication relationship with the 206 client. 208 When a user goes off-hook and dials a telephone number, the UAC collects 209 the dialed digits and sends the initial INVITE message to Originating 210 SIP-Proxy. 212 The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 213 message to the proper SIP-proxy. 215 Assuming that the call is not forwarded, the other end-point sends a 183 216 response to the initial INVITE, proxied back to OP. Included in this 217 response is the negotiated bandwidth requirement for the connection. 219 When OP receives the 183, it has sufficient information regarding the 220 end-points, bandwidth and characteristics of the media exchange. It 221 initiates a Policy-Setup message to PDP-o. 223 The PDP-o stores the authorized Media description in its local store 224 generates an Authorization-Token that points to this description and 225 returns the Authorization-Token to OP. 226 SIP Working Group Expiration 2/28/02 4 227 SIP Extensions for Media Authorization August 2001 229 UAC ER-o PDP-o OP 230 | Invite | | | Client Authentication 231 |------------------------------------------->| and Call Authorization 232 | | | | Invite 233 | | | |--------------> 234 | | | | 180/3 235 | | | Auth. Profile |<-------------- 236 | | |<--------------| 237 | | | Auth. Token | 238 | | |-------------->| Auth. Token put into 239 | | | 180/3 | Media-Authorization header 240 |<-------------------------------------------| extension. 241 |Copies the RSVP policy object | 242 |from the Media-Authorization | 243 | RSVP-PATHo | | | 244 |----------->| REQ | | 245 | |-------------->| Using the Auth-Token and Authorized 246 | | DEC | Profile that is set by the SIP Proxy 247 | |<--------------| the PDP makes the decision 248 | | | | RSVP-PATHo 249 | |------------------------------------------------> 250 | | | | RSVP-PATHt 251 |<-------------------------------------------------------------- 252 |Copies the RSVP policy object | 253 |from the Media-Authorization | 254 | RSVP-RESVt | | | 255 |----------->| REQ | | 256 | |-------------->| Using the Auth-Token and Authorized 257 | | DEC | Profile that is set by the SIP Proxy 258 | |<--------------| the PDP makes the decision 259 | | | | RSVP-RESVt 260 | |---------------------------------------------------> 261 | | | | RSVP-RESVo 262 |<---------------------------------------------------------------- 263 | | | | RSVP-RESVCONFo 264 |----------------------------------------------------------------> 265 | | | | RSVP-RESVCONFt 266 |<---------------------------------------------------------------- 267 | | | | 200 OK 268 |<-------------------------------------------|<------------------ 269 | | | | MEDIA 270 |<===============================================================> 271 | | | | ACK 272 |----------------------------------------------------------------> 274 Figure 1 276 SIP Working Group Expiration 2/28/02 5 277 SIP Extensions for Media Authorization August 2001 279 The OP includes the Authorization-Token in the Media-Auth-Token header 280 extension of the 183 message. 282 The UAC upon reception stores the Media-Authorization-Token inside the 283 Media-Auth-Token header extension. 285 Before sending the Media stream, the UAC requests bandwidth using an 286 RSVP-PATH message which includes the Session info that describes the 287 Media data-stream and TSpec that describes the bandwidth requested along 288 with Authorization information that was stored in Media-Authorization- 289 Token. 291 ERo, upon reception of the RSVP-PATHo message checks the authorization 292 through a PDP-o COPS message exchange. The PDPo checks the authorization 293 using the stored authorized Media description that was linked to 294 Authorization-Token that it returned to OP. If authorization is 295 successful PDPo returns an "install" Decision. 297 ERo checks the admissibility for the call and if admission succeeds, it 298 forwards the RSVP-PATHo message. 300 Once UAC receives the RSVP-PATHt message it sends RSVP-RESVt message to 301 reserve the bandwidth. 303 ERo, upon reception of the RSVP-RESVt message checks the authorization 304 through a PDPo COPS message exchange. The PDPo checks the authorization 305 using the stored authorized Media description that was linked to 306 Authorization-Token that it returned to OP. If authorization is 307 successful PDPo returns an "install" Decision. 309 ERo checks the admissibility for the call and if admission succeeds, it 310 forwards the RSVP-RESVt message. 312 Upon reception of RSVP-RESVo message the UAC sends RSVP-RESVCONFo message 313 to indicate that the reservation completed for one direction. 315 Upon reception of both RSVP-RESVCONFt and 200OK the UAC returns ACK 316 message. 318 6.1.2. User Agent Server Side 320 Figure 2 presents a high-level overview of a call flow with Media 321 Authorization from the viewpoint of the UAS. It is assumed that the SIP- 322 Proxy has a previously established authentication relationship with the 323 client. 325 Since the Destination SIP-Proxy (DP) has sufficient information regarding 326 the end-points, bandwidth and characteristics of the media exchange, it 327 initiates a Policy-Setup message to the termination Policy Decision Point 328 (PDPt). 330 SIP Working Group Expiration 2/28/02 6 331 SIP Extensions for Media Authorization August 2001 333 UAS ERt PDPt DP 334 | | | | Invite 335 | | | |<-------------- 336 | | | | Proxy Authentication 337 | | | Auth. Profile | and Call Authorization 338 | | |<--------------| 339 | | | Auth. Token | 340 | | |-------------->| Auth. Token put into 341 | | | Invite | Media-Authorization header 342 |<------------------------------------------| extension 343 | 180/3 | | | 344 |------------------------------------------>| 180/3 345 |Copies the RSVP policy object |--------------> 346 |from the Media-Authorization | 347 | RSVP-PATHt| | | 348 |---------->| REQ | | 349 | |-------------->| Using the Auth-Token and Authorized 350 | | DEC | Profile that is set by the SIP Proxy 351 | |<--------------| the PDP makes the decision 352 | | | | RSVP-PATHt 353 | |--------------------------------------------------> 354 | | | | RSVP-PATHo 355 |<-------------------------------------------------------------- 356 |Copies the RSVP policy object | 357 |from the Media-Authorization | 358 | RSVP-RESVo| | | 359 |---------->| | | 360 | | REQ | | 361 | |-------------->| Using the Auth-Token and Authorized 362 | | DEC | Profile that is set by the SIP Proxy 363 | |<--------------| the PDP makes the decision 364 | | | | RSVP-RESVo 365 | |---------------------------------------------------> 366 | | | | RSVP-RESVt 367 |<--------------------------------------------------------------- 368 | | | | RSVP-RESVCONFt 369 |---------------------------------------------------------------> 370 | | | | RSVP-RESVCONFo 371 |<--------------------------------------------------------------- 372 | | | | 200 OK 373 |-----------------------------------------> |-------------------> 374 | | | | ACK 375 |<---------------------------------------------------------------- 376 Figure 2 378 SIP Working Group Expiration 2/28/02 7 379 SIP Extensions for Media Authorization August 2001 381 The PDP-t stores the authorized Media description in its local store 382 generates an Authorization-Token that points to this description and 383 returns the Authorization-Token to DP. 385 Assuming that the call is not forwarded, the UAS sends a 183 response to 386 the initial INVITE message, which is forwarded back to UAC. At the same 387 time UAS sends RSVP-PATHt message for Media data-stream that includes the 388 Session info that describes the Media data-stream and TSpec that 389 describes the bandwidth requested along with Authorization information 390 that was stored in Media-Authorization-Token. 392 ERt, upon reception of the RSVP-PATHt message checks the authorization 393 through a PDPt COPS message exchange. The PDPt checks the authorization 394 using the stored authorized Media description that was linked to 395 Authorization-Token that it returned to DP. If authorization is 396 successful PDPt returns an "install" Decision. 398 ERt checks the admissibility for the call and if admission succeeds, it 399 forwards the RSVP-PATHt message. 401 Once the UAS receives the RSVP-PATHo message, it sends RSVP-RESVo message 402 to reserve the bandwidth. 404 ERt, upon reception of the RSVP-RESVo message, checks the authorization 405 through a PDPt COPS message exchange. The PDPt checks the authorization 406 using the stored authorized Media description that was linked to 407 Authorization-Token that it returned to DP. If authorization is 408 successful PDPt returns an "install" Decision. 410 ERt checks the admissibility for the call and if admission succeeds, it 411 forwards the RSVP-RESVo message. 413 Upon reception of RSVP-RESVo message the UAS sends RSVP-RESVCONFt message 414 to indicate that the reservation completed for one direction. 416 Upon reception of both RSVP-RESVCONFo and 200OK the UAS returns ACK 417 message. 419 6.2. Requesting Bandwidth via DOCSIS MAC messaging 421 The DOCSIS MAC layer [5] QoS Set-Up the call flows are different in the 422 sense that the Authorization token is a simple 32bit number [6], encoded 423 as a Policy-Element. DSA-REQ, DSA-RSP, and DSA-ACK are layer 2 messages 424 that are specific to and optimized for the Cable environment which 425 simplifies/reduces delays for the embedded client implementation [6]. 427 SIP Working Group Expiration 2/28/02 8 428 SIP Extensions for Media Authorization August 2001 430 UAC ER/CMTSo OP 431 | Invite | | 432 |------------------------------------------->| Client Authentication 433 | | |and Call Authorization 434 | | | 435 | | | Invite 436 | | |-----------> 437 | | | 438 | | | 180/3 OK 439 | | |<------------ 440 | | | 441 | | Gate-Setup | 442 | |<--------------------- | 443 | | Gate-Setup-Ack | 444 | |---------------------> | 445 | | | GateID put into 446 | | | Media-Authorization header 447 | | | extension 448 | | 180/3 OK | 449 |<-------------------------------------------| 450 |Copies the GAteID object | 451 |from the Media-Authorization | 452 | | | 453 | DSA-REQ | | 454 |------------------->| | 455 | | Using the GateID and the Profile 456 | | communicated during Gate-Setup 457 | | the CMTS honors the request and creates 458 | DSA-RSP | a scheduler with appropriate settings 459 |<-------------------| | 460 | | | 461 | DSA-ACK | | 462 |------------------->| | 463 | | | 465 Figure 3 467 6.2.1. User Agent Client Side 469 Figure 3 presents a high-level overview of a call flow with Media 470 Authorization from the viewpoint of the UAC. It is assumed that the SIP- 471 Proxy has a previously established authentication relationship with the 472 client. 474 When a user goes off-hook and dials a telephone number, the originating 475 SIP Client (UAC) collects the dialed digits and sends the initial INVITE 476 message to Originating SIP-Proxy. 478 The Originating SIP-Proxy (OP) authenticates UAC and forwards the INVITE 479 message to the proper destination SIP-proxy. 481 Assuming that the call is not forwarded, the other end-point sends a 183 482 response to the initial INVITE, forwarded back to OP. Included in this 483 response is the negotiated bandwidth requirement for the connection. 484 SIP Working Group Expiration 2/28/02 9 485 SIP Extensions for Media Authorization August 2001 487 When OP receives the 183, it has sufficient information regarding the 488 end-points, bandwidth and characteristics of the media exchange. It sends 489 a Gate-Setup message to ER/CMTSo containing Media data-stream description 490 and bandwidth characteristics. The ER/CMTSo returns a 32 bit index value 491 that inside ER/CMTSo points to Media definition that OP send out. 493 UAC sends DSA-REQ message asking for bandwidth, which includes the 32 bit 494 index value. 496 ER/CMTSo, upon reception of the RSA-REQ message uses the index value to 497 find the authorized media description. Checks the requested media link 498 against authorized if the both authorization and admission succeeds it 499 starts a layer 2 link for Media data-stream on the Cable Access link and 500 returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. 502 Upon reception of 200OK the UAC returns ACK message. 504 6.2.2. User Agent Server Side 506 Figure 4 presents a high-level overview of a basic call flow with Media 507 Authorization from the viewpoint of the UAS. It is assumed that the 508 Destination SIP-Proxy (DP) has a previously established authentication 509 relationship with the UAS. 511 When DP receives the INVITE message, it has sufficient information 512 regarding the end-points, bandwidth and characteristics of the media 513 exchange. It sends a Gate-Setup message to ER/CMTSt containing Media 514 data-stream description and bandwidth characteristics. The ER/CMTSt 515 returns a 32 bit index value that inside ER/CMTSt points to Media 516 definition that DP send out. 518 The DP includes the 32 bit index value in the Media-Auth-Token header 519 extension that its including into the INVITE message. 521 The UAS sends a 183 response to the initial INVITE, which is forwarded 522 back to UAC. At the same time UAS sends DSA-REQ message asking for 523 bandwidth which includes the 32 bit index value. 525 ER/CMTSt, upon reception of the RSA-REQ message uses the index value to 526 find the authorized media description. Checks the requested media link 527 against authorized if the both authorization and admission succeeds it 528 starts a layer 2 link for Media data-stream on the Cable Access link and 529 returns DSA-RSP, which is acknowledged by UAC via DSA-ACK message. Upon 530 reception of DSA-RSP the UAS returns ACK message. 532 SIP Working Group Expiration 2/28/02 10 533 SIP Extensions for Media Authorization August 2001 535 UAS ER/CMTSt DP 536 | | | 537 | | | Invite 538 | | |<----------- 539 | | | Proxy Authentication 540 | | | and Call Authorization 541 | | Gate-Setup | 542 | |<----------------------| 543 | | Gate-Setup-Ack | 544 | |---------------------->| 545 | | | GateID put into 546 | | | Media-Authorization header 547 | | | extension 548 | Invite | | 549 |<-------------------------------------------| 550 | | | 551 | | 180/3 | 552 |------------------------------------------->| 553 | | | 180/3 554 | | |------------> 555 |Copies the GateID object | 556 |from the Media-Authorization | 557 | | | 558 | DSA-REQ | 559 |------------------->| 560 | | Using the GateID and the Profile 561 | | communicated during Gate-Setup 562 | | the CMTS honors the request and creates 563 | DSA-RSP | a scheduler with appropriate settings 564 |<-------------------| 565 | | 566 | DSA-ACK | | 567 |------------------->| | 568 | | | 569 | | 200 OK | 570 |------------------------------------------->| 571 | | | 200 OK 572 | | |------------> 574 Figure 4 576 SIP Working Group Expiration 2/28/02 11 577 SIP Extensions for Media Authorization August 2001 579 7. Advantages of the Proposed Approach 581 The use of call authorization makes it possible to control the 582 utilization of network resources. This in turn makes IP Telephony more 583 robust against denial of service attacks and various kinds of service 584 frauds. 586 Using the authorization capability, the service provider can control the 587 number of flows, the amount of bandwidth, and the end-point reached 588 making the IP Telephony system dependable in the presence of scarce 589 resources. 591 8. Security Considerations 593 Media Authorization Tokens sent from a SIP-Proxy to a UAC/UAS MUST be 594 protected from eavesdropping, through a mechanism such as IPSec. 596 9. Notice Regarding Intellectual Property Rights 598 The IETF has been notified of intellectual property rights claimed in 599 regard to some or all of the specification contained in this document. 600 For more information consult the online list of claimed rights. 602 10. Reference 604 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, 605 RFC 2026, October 1996. 607 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 608 Levels", BCP 14, RFC 2119, March 1997 610 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 611 Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon 612 Internet Ltd., November 1997 614 4 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 615 session initiation protocol,"Request for Comments (Proposed 616 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 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 8 Herzog, S, RSVP Extensions for Policy Control, RFC2750, January 2000. 629 11. Acknowledgments 630 SIP Working Group Expiration 2/28/02 12 631 SIP Extensions for Media Authorization August 2001 633 The Distributed Call Signaling work in the PacketCable project is 634 the work of a large number of people, representing many different 635 companies. The authors would like to recognize and thank the 636 following for their assistance: John Wheeler, Motorola; David 637 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 638 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 639 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 640 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 641 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 642 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 643 Cable Communications. 645 13. Author's Addresses 647 Bill Marshall 648 AT&T 649 Florham Park, NJ 07932 650 Email: wtm@research.att.com 652 K. K. Ramakrishnan 653 TeraOptic Networks 654 Summit, NJ 07901 655 Email: kk@teraoptic.com 657 Ed Miller 658 Terayon 659 Louisville, CO 80027 660 Email: E.Miller@terayon.com 662 Glenn Russell 663 CableLabs 664 Louisville, CO 80027 665 Email: G.Russell@Cablelabs.com 667 Burcak Beser 668 Pacific Broadband Communications 669 San Jose, CA 670 Email: Burcak@pacband.com 672 Mike Mannette 673 3Com 674 Rolling Meadows, IL 60008 675 Email: Michael_Mannette@3com.com 677 Kurt Steinbrenner 678 3Com 679 Rolling Meadows, IL 60008 680 Email: Kurt_Steinbrenner@3com.com 682 Dave Oran 683 Cisco 685 SIP Working Group Expiration 2/28/02 13 686 SIP Extensions for Media Authorization August 2001 688 Acton, MA 01720 689 Email: oran@cisco.com 691 Flemming Andreasen 692 Cisco 693 Edison, NJ 694 Email: fandreas@cisco.com 696 John Pickens 697 Com21 698 San Jose, CA 699 Email: jpickens@com21.com 701 Poornima Lalwaney 702 Nokia 703 San Diego, CA 92121 704 Email: poornima.lalwaney@nokia.com 706 Jon Fellows 707 Copper Mountain Networks 708 San Diego, CA 92121 709 Email: jfellows@coppermountain.com 711 Doc Evans 712 D. R. Evans Consulting 713 Boulder, CO 80303 714 Email: n7dr@arrl.net 716 Keith Kelly 717 NetSpeak 718 Boca Raton, FL 33587 719 Email: keith@netspeak.com 721 SIP Working Group Expiration 2/28/02 14 722 SIP Extensions for Media Authorization August 2001 724 Full Copyright Statement 726 "Copyright (C) The Internet Society (date). All Rights Reserved. 727 This document and translations of it may be copied and furnished to 728 others, and derivative works that comment on or otherwise explain it 729 or assist in its implmentation may be prepared, copied, published 730 and distributed, in whole or in part, without restriction of any 731 kind, provided that the above copyright notice and this paragraph 732 are included on all such copies and derivative works. However, this 733 document itself may not be modified in any way, such as by removing 734 the copyright notice or references to the Internet Society or other 735 Internet organizations, except as needed for the purpose of 736 developing Internet standards in which case the procedures for 737 copyrights defined in the Internet Standards process must be 738 followed, or as required to translate it into languages other than 739 English. The limited permissions granted above are perpetual and 740 will not be revoked by the Internet Society or its successors or 741 assigns. This document and the information contained herein is 742 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 743 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 744 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 745 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 748 Expiration Date This memo is filed as , and expires February 28, 2002. 751 SIP Working Group Expiration 2/28/02 15