idnits 2.17.1 draft-ietf-sip-call-auth-05.txt: 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 page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 164 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 197 has weird spacing: '... Where proxy...' -- 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '8') (Obsoleted by RFC 4566) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft AT&T 4 Document: F. Andreasen 5 Category: Informational Cisco 6 D. Evans 7 D. R. Evans Consulting 9 May, 2002 11 SIP Extensions for Media Authorization 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC 2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. Internet-Drafts 21 are draft documents valid for a maximum of six months and may be updated, 22 replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet-Drafts as reference material or to cite 24 them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes the need for QoS and media authorization and 35 defines a SIP extension that can be used to integrate QoS admission 36 control with call signaling and help guard against denial of service 37 attacks. The use of this extension is only applicable in administrative 38 domains, or among federations of administrative domains with previously 39 agreed-upon policies, where both the SIP proxy authorizing the QoS, and 40 the policy control of the underlying network providing the QoS belong to 41 that administrative domain or federation of domains. 43 Table of Contents 45 1. Scope of Applicability...............................................2 46 2. Conventions used in this document....................................2 47 3. Background and Motivation............................................2 48 4. Overview.............................................................3 49 5. Changes to SIP to Support Media Authorization........................4 50 5.1 SIP Header Extension.............................................4 51 5.2 SIP Procedures...................................................4 52 5.2.1 User Agent Client (UAC)......................................5 53 5.2.2 User Agent Server (UAS)......................................5 55 SIP Working Group Informational - Expires 11/02/02 1 56 5.2.3 Originating Proxy (OP).......................................5 57 5.2.4 Destination Proxy (DP).......................................6 58 6. Examples.............................................................6 59 6.1 Requesting Bandwidth via RSVP messaging..........................6 60 6.1.1 User Agent Client Side.......................................6 61 6.1.2 User Agent Server Side.......................................8 62 7. Advantages of the Proposed Approach.................................10 63 8. Security Considerations.............................................10 64 9. IANA Considerations.................................................11 65 10. Notice Regarding Intellectual Property Rights......................11 66 11. Normative References...............................................11 67 12. Informative References.............................................11 68 13. Contributors.......................................................11 69 14. Acknowledgments....................................................12 70 15. Authors' Addresses.................................................12 72 1. Scope of Applicability 74 This document defines a SIP extension that can be used to integrate QoS 75 admission control with call signaling and help guard against denial of 76 service attacks. The use of this extension is only applicable in 77 administrative domains, or among federations of administrative domains 78 with previously agreed-upon policies, where both the SIP proxy 79 authorizing the QoS, and the policy control of the underlying network 80 providing the QoS belong to that administrative domain or federation of 81 domains. Furthermore, the mechanism is generally incompatible with end- 82 to-end encryption of message bodies that describe media sessions. 84 This is in contrast with general Internet principles which separate data 85 transport from applications, and the solution described in this document 86 is thus not applicable to the Internet at large. Despite these 87 limitations, there are sufficiently useful specialized deployments that 88 meet the assumptions described above, and can accept the limitations that 89 result, to warrant publication of this mechanism. An example deployment 90 would be a closed network which emulates a traditional circuit switched 91 telephone network. 93 2. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [2]. 99 3. Background and Motivation 101 Current IP telephony systems assume a perfect world in which there is 102 either unlimited amount of bandwidth or network layer Quality of Service 103 (QoS) is provided without any kind of policy control. However the reality 104 is that end-to-end bandwidth is not unlimited and uncontrolled access to 105 QoS in general is unlikely. The primary reason for this is that QoS 106 provides preferential treatment of one flow at the expense of another. 107 Consequently, it is important to have policy control over whether a given 108 flow should have access to QoS. This will not only enable fairness in 109 general, but can also prevent denial of service attacks. 111 SIP Working Group Informational - Expires 11/02/02 2 112 In this document, we are concerned with providing QoS for media streams 113 established via the Session Initiation Protocol (SIP) [3]. We assume an 114 architecture that integrates call signaling with media authorization as 115 illustrated in the Figure below. The solid lines (A and B) show 116 interfaces whereas the dotted line (C) illustrates the QoS enabled media 117 flow: 119 +---------+ 120 | Proxy | 121 +--------->| | 122 | +---------+ 123 | ^ 124 A)| B) | 125 | { } 126 | | 127 | v 128 v +------+ 129 +------+ C) | Edge | 130 | UA |........|router|...... 131 +------+ +------+ 133 Figure 1 - Basic Architecture 135 In this architecture, we assume an untrusted SIP UA connected to a QoS 136 enabled network with an edge router acting as a Policy Enforcement Point 137 (PEP) [6]. We furthermore assume that a SIP UA, that wishes to obtain 138 QoS, initiates sessions through a proxy which can interface with the QoS 139 policy control for the data network being used. We will refer to such a 140 proxy as a QoS enabled proxy. We assume that the SIP UA needs to present 141 an authorization token to the network in order to obtain Quality of 142 Service (C). The SIP UA obtains this authorization token via SIP (A) from 143 the QoS enabled proxy by means of an extension SIP header defined in this 144 document. The proxy in turn communicates either directly with the edge 145 router or with a Policy Decision Point (PDP - not shown) [6] in order to 146 obtain a suitable authorization token for the UA. 148 Examples of access data networks where such a QoS enabled proxy could be 149 used include DOCSIS based cable networks and 3rd generation (3G) wireless 150 networks. 152 4. Overview 154 A session, that needs to obtain QoS for the media streams in accordance 155 with our basic architecture described above is performed as follows. 157 The SIP UA sends an INVITE to the QoS enabled proxy which for each 158 resulting dialog includes a media authorization token in all unreliable 159 provisional responses (except 100), the first reliable 1xx or 2xx 160 response, and all retransmissions of that reliable response for the 162 SIP Working Group Informational - Expires 11/02/02 3 163 dialog. When the UA requests QoS, it includes the media authorization 164 token with the resource reservation. 166 A SIP UA may also receive an INVITE from its QoS enabled proxy which 167 includes a media authorization token. In that case, when the UA requests 168 QoS, it includes the media authorization token with the resource 169 reservation. 171 5. Changes to SIP to Support Media Authorization 173 This document defines a private SIP header extension to support a media 174 authorization scheme. In this architecture a QoS enabled SIP proxy 175 supplies the UA with an authorization token which is to be used in QoS 176 requests. The extension defined allows network QoS resources to be 177 authorized by the QoS enabled SIP proxy. 179 5.1 SIP Header Extension 181 A new P-Media-Authorization general header field is defined. The Media- 182 Auth header field contains a media authorization token which is to be 183 included in subsequent resource reservations for the media flows 184 associated with the session. The media authorization token is used for 185 authorizing QoS for the media stream(s). The P-Media-Authorization header 186 field is described by the following ABNF [4]: 188 P-Media-Authorization = "P-Media-Authorization" HCOLON 189 P-Media-Authorization-Token 190 *(COMMA P-Media-Authorization-Token) 192 P-Media-Authorization-Token = 1*HEXDIG 194 Table 1 below is an extension of tables 2 and 3 in [3] for the new header 195 field defined here: 197 Where proxy ACK BYE CAN INV OPT REG 198 P-Media-Authorization ad - - - o - - 200 Table 1: Summary of header fields. 202 The P-Media-Authorization header field can be used with the INVITE method 203 as well as any response to it. Extension methods MAY define usage of the 204 header field as well. 206 5.2 SIP Procedures 208 This section defines the SIP [3] procedures for usage in media 209 authorization compatible systems from the point of view of authorizing 210 QoS. 212 SIP Working Group Informational - Expires 11/02/02 4 213 5.2.1 User Agent Client (UAC) 215 The initial SIP INVITE message, mid-call messages that result in network 216 QoS resource changes, and mid-call changes in call destination should be 217 authorized. These SIP messages are sent through the QoS enabled proxies 218 to receive this authorization. In order to authorize QoS, the QoS enabled 219 SIP proxy MAY need to inspect message bodies that describe the media 220 streams, e.g. SDP, and hence such message bodies SHOULD NOT be encrypted 221 end-to-end. 223 The P-Media-Authorization-Token, which is contained in the P-Media- 224 Authorization header, is included for each dialog in all unreliable 225 provisional responses (except 100), the first reliable 1xx or 2xx 226 response, and all retransmissions of that reliable response for the 227 dialog sent by the QoS enabled SIP proxy to the UAC. 229 The UAC SHOULD use all the P-Media-Authorization-Token(s) from the most 230 recent request/response that contained the P-Media-Authorization header 231 when requesting QoS for the associated media stream(s). This applies both 232 to the initial and subsequent refresh reservation messages. The UAC 233 converts the string of hex digits into binary, and utilizes the result as 234 a Policy-Element as defined in RFC 2750 [5] (including Length and P- 235 Type). This Policy-Element would typically contain the authorizing entity 236 and credentials, and be used in an RSVP request for media data stream QoS 237 resources. 239 5.2.2 User Agent Server (UAS) 241 The User Agent Server receives the P-Media-Authorization-Token in an 242 INVITE (or other) message from the QoS enabled SIP proxy. If the response 243 contains a message body that describes media streams for which the UA 244 desires QoS, said message body SHOULD NOT be end-to-end encrypted. 246 The UAS SHOULD use all the P-Media-Authorization-Token(s) from the most 247 recent request/response that contained the P-Media-Authorization header 248 when requesting QoS for the associated media stream(s). This applies both 249 to the initial and subsequent refresh reservation messages. The UAS 250 converts the string of hex digits into binary, and utilizes the result as 251 a Policy-Element as defined in RFC 2750 [5] (including Length and P- 252 Type). This Policy-Element would typically contain the authorizing entity 253 and credentials, and be used in an RSVP request for media data stream 254 resources. 256 5.2.3 Originating Proxy (OP) 258 When the originating QoS enabled proxy (OP) receives an INVITE (or other) 259 message from the UAC, the proxy authenticates the caller, and verifies 260 that the caller is authorized to receive QoS. 262 In cooperation with an originating Policy Decision Point (PDP-o), the OP 263 obtains and/or generates a media authorization token that contains 264 sufficient information for the UAC to get the authorized QoS for the 265 media streams. The media authorization token is formatted as a Policy- 266 Element, as defined in RFC 2750 [5], and then converted to a string of 268 SIP Working Group Informational - Expires 11/02/02 5 269 hex digits to form a P-Media-Authorization-Token. The proxy MAY inspect 270 message bodies that describe the media streams, e.g. SDP, in both 271 requests and responses in order to decide what QoS to authorize. 273 For each dialog that results from the INVITE (or other) message received 274 from the UAC, the originating proxy MUST add a P-Media-Authorization 275 header with the P-Media-Authorization-Token in all unreliable provisional 276 responses (except 100), the first reliable 1xx or 2xx response, and all 277 retransmissions of that reliable response the proxy sends to the UAC, if 278 that response may result in network QoS changes. A response with an SDP 279 may result in such changes. 281 5.2.4 Destination Proxy (DP) 283 The Destination QoS Enabled Proxy (DP) verifies that the called party is 284 authorized to receive QoS. 286 In cooperation with a terminating Policy Decision Point (PDP-t), the DP 287 obtains and/or generates a media authorization token that contains 288 sufficient information for the UAS to get the authorized QoS for the 289 media streams. The media authorization token is formatted as a Policy- 290 Element, as defined in RFC 2750 [5], and then converted to a string of 291 hex digits to form a P-Media-Authorization-Token. The proxy MAY inspect 292 message bodies that describe the media streams, e.g. SDP, in both 293 requests and responses in order to decide what QoS to authorize. 295 The Destination Proxy MUST add the P-Media-Authorization header with the 296 P-Media-Authorization-Token in the INVITE (or other) request that it 297 sends to the UAS, if that message may result in network QoS changes. A 298 message with an SDP body may result in such changes. 300 6. Examples 302 6.1 Requesting Bandwidth via RSVP messaging 304 Below we provide an example for how the P-Media-Authorization header 305 field can be used in conjunction with the Resource Reservation Protocol 306 (RSVP) [7]. The example assumes that resource management is integrated 307 with SIP signaling and therefore utilizes the 183 Session Progress 308 provisional response, which contains an SDP description of the media 309 flow. 311 6.1.1 User Agent Client Side 313 Figure 2 presents a high-level overview of a basic call flow with media 314 authorization from the viewpoint of the UAC. Some policy interactions 315 have been omitted for brevity. 317 When a user goes off-hook and dials a telephone number, the UAC collects 318 the dialed digits and sends the initial (1)INVITE message to the 319 originating SIP proxy. 321 SIP Working Group Informational - Expires 11/02/02 6 322 The originating SIP proxy (OP) authenticates the user/UAC and forwards 323 the (2)INVITE message to the proper SIP proxy. 325 Assuming the call is not forwarded, the terminating end-point sends a 326 (3)183 response to the initial INVITE via OP. Included in this response 327 is an indication of the negotiated bandwidth requirement for the 328 connection (in the form of an SDP description [8]). 330 When OP receives the (3)183, it has sufficient information regarding the 331 end-points, bandwidth and characteristics of the media exchange. It 332 initiates a Policy-Setup message to PDP-o, (4)AuthProfile. 334 The PDP-o stores the authorized media description in its local store, 335 generates an authorization token that points to this description, and 336 returns the authorization token to the OP, (5)AuthToken. 338 UAC ER-o PDP-o OP 339 |(1)Invite | | | Client Authentication 340 |------------------------------------------->| and Call Authorization 341 | | | | (2)Invite 342 | | | |--------------> 343 | | | | (3)180/3 344 | | |(4)AuthProfile |<-------------- 345 | | |<--------------| 346 | | |(5)AuthToken | 347 | | |-------------->| Auth. Token put into 348 | | |(6)180/3 | P-Media-Authorization 349 |<-------------------------------------------| header extension. 350 |Copies the RSVP policy object | 351 |from the P-Media-Authorization | 352 |(7)RSVP-PATH | | 353 |----------->| (8)REQ | | 354 | |-------------->| Using the Auth-Token and Authorized 355 | | (9)DEC | Profile that is set by the SIP Proxy 356 | |<--------------| the PDP makes the decision 357 | | | |(10)RSVP-PATH 358 | |------------------------------------------------> 359 | | | |(11)RSVP-PATH 360 |<-------------------------------------------------------------- 361 |Copies the RSVP policy object | 362 |from the P-Media-Authorization | 363 |(12)RSVP-RESV | | 364 |----------->| (13)REQ | | 365 | |-------------->| Using the Auth-Token and Authorized 366 | | (14)DEC | Profile that is set by the SIP Proxy 367 | |<--------------| the PDP makes the decision 368 | | | |(15)RSVP-RESV 369 | |---------------------------------------------------> 370 | | | |(16)RSVP-RESV 371 |<---------------------------------------------------------------- 372 | | | | 374 Figure 2 - Media Authorization with RSVP (UAC) 376 SIP Working Group Informational - Expires 11/02/02 7 377 The OP includes the authorization token in the P-Media-Authorization 378 header extension of the (6)183 message. 380 Upon receipt of the (6)183 message, the UAC stores the media 381 authorization token from the P-Media-Authorization header. 383 Before sending any media, the UAC requests QoS by sending an (7)RSVP-PATH 384 message which includes the previously stored P-Media-Authorization-Token 385 as a Policy-Element. 387 ER-o, upon reception of the (7)RSVP-PATH message checks the authorization 388 through a PDP-o COPS message exchange, (8)REQ. PDP-o checks the 389 authorization using the stored authorized media description that was 390 linked to the authorization token it returned to OP. If authorization is 391 successful, PDP-o returns an "install" Decision, (9)DEC. 393 ER-o checks the admissibility for the request and if admission succeeds, 394 it forwards the (10)RSVP-PATH message. 396 Once UAC receives the (11)RSVP-PATH message from UAS it sends the 397 (12)RSVP-RESV message to reserve the network resources. 399 ER-o, upon receiving the (12)RSVP-RESV message checks the authorization 400 through a PDP-o COPS message exchange, (13)REQ. PDP-o checks the 401 authorization using the stored authorized media description that was 402 linked to the authorization token it returned to OP. If authorization is 403 successful PDP-o returns an "install" Decision, (14)DEC. 405 ER-o checks the admissibility for the request and if admission succeeds, 406 it forwards the (15)RSVP-RESV message. 408 Upon receiving the (16)RSVP-RESV message, network resources have been 409 reserved in both directions. 411 6.1.2 User Agent Server Side 413 Figure 3 presents a high-level overview of a call flow with media 414 authorization from the viewpoint of the UAS. Some policy interactions 415 have been omitted for brevity. 417 Since the destination SIP proxy (DP) has sufficient information regarding 418 the endpoints, bandwidth and characteristics of the media exchange, it 419 initiates a Policy-Setup message to the terminating Policy Decision Point 420 (PDP-t) on receipt of the (1)INVITE. 422 SIP Working Group Informational - Expires 11/02/02 8 423 UAS ER-t PDP-t DP 424 | | | | (1)Invite 425 | | | |<-------------- 426 | | | | Proxy Authentication 427 | | | (2)AuthProfile| and Call Authorization 428 | | |<--------------| 429 | | | (3)AuthToken | 430 | | |-------------->| Auth. Token put into 431 | | | (4)Invite | P-Media-Authorization 432 |<------------------------------------------| header extension 433 | (5)180/3 | | | 434 |------------------------------------------>| (6)180/3 435 |Copies the RSVP policy object |--------------> 436 |from the P-Media-Authorization | 437 |(7)RSVP-PATH | | 438 |---------->| (8)REQ | | 439 | |-------------->| Using the Auth-Token and Authorized 440 | | (9)DEC | Profile that is set by the SIP Proxy 441 | |<--------------| the PDP makes the decision 442 | | | |(10)RSVP-PATH 443 | |--------------------------------------------------> 444 | | | |(11)RSVP-PATH 445 |<-------------------------------------------------------------- 446 |Copies the RSVP policy object | 447 |from the P-Media-Authorization | 448 | (12)RSVP-RESV | | 449 |---------->| | | 450 | | (13)REQ | | 451 | |-------------->| Using the Auth-Token and Authorized 452 | | (14)DEC | Profile that is set by the SIP Proxy 453 | |<--------------| the PDP makes the decision 454 | | | |(15)RSVP-RESV 455 | |---------------------------------------------------> 456 | | | |(16)RSVP-RESV 457 |<--------------------------------------------------------------- 458 | | | | 460 Figure 3 - Media Authorization with RSVP (UAS) 462 PDP-t stores the authorized media description in its local store, 463 generates an authorization token that points to this description, and 464 returns the authorization token to DP. The token is placed in the 465 (4)INVITE message and forwarded to the UAS. 467 Assuming that the call is not forwarded, the UAS sends a (5)183 response 468 to the initial INVITE message, which is forwarded back to UAC. At the 469 same time, the UAS sends an (7)RSVP-PATH message which includes the 470 previously stored P-Media-Authorization-Token as a Policy-Element. 472 ER-t, upon receiving the (7)RSVP-PATH message checks the authorization 473 through a PDP-t COPS message exchange. PDP-t checks the authorization 474 using the stored authorized media description that was linked to the 476 SIP Working Group Informational - Expires 11/02/02 9 477 authorization token it returned to DP. If authorization is successful 478 PDP-t returns an "install" Decision, (9)DEC. 480 ER-t checks the admissibility for the call and if admission succeeds, it 481 forwards the (10)RSVP-PATH message. 483 Once the UAS receives the (11)RSVP-PATH message, it sends (12)RSVP-RESV 484 message to reserve the network resources. 486 ER-t, upon reception of the (12)RSVP-RESV message, checks the 487 authorization through a PDP-t COPS message exchange. PDP-t checks the 488 authorization using the stored authorized media description that was 489 linked to the authorization token that it returned to DP. If 490 authorization is successful PDP-t returns an "install" Decision, (14)DEC. 492 ER-t checks the admissibility for the call and if admission succeeds, it 493 forwards the (15)RSVP-RESV message. 495 Upon receiving the (16)RSVP-RESV message, network resources have been 496 reserved in both directions. 498 7. Advantages of the Proposed Approach 500 The use of media authorization makes it possible to control the usage of 501 network resources. This in turn makes IP Telephony more robust against 502 denial of service attacks and various kinds of service frauds. By using 503 the authorization capability, the number of flows, and the amount of 504 network resources reserved can be controlled thereby making the IP 505 Telephony system dependable in the presence of scarce resources. 507 8. Security Considerations 509 In order to control access to QoS, a QoS enabled proxy may want to 510 authenticate the UA before providing it with a media authorization token. 511 Both the method and policy associated with such authentication is outside 512 the scope of this document, however it could for example be done by using 513 standard SIP authentication mechanisms as described in [3]. 515 Media authorization tokens sent in the P-Media-Authorization header from 516 a QoS enabled proxy to a UA MUST be protected from eavesdropping and 517 tampering. This can for example be done through a mechanism such as IPSec 518 or TLS. However, this will only provide hop-by-hop security. If there is 519 one or more intermediaries, e.g. proxies, between the UA and the QoS 520 enabled proxy, these intermediaries will have access to the P-Media- 521 Authorization header field value thereby compromising confidentiality and 522 integrity. This will enable both theft-of-service and denial-of-service 523 attacks against the UA. Consequently, the P-Media-Authorization header 524 field MUST NOT be available to any untrusted intermediary in clear or 525 without integrity protection. There is currently no mechanism defined in 526 SIP that would satisfy these requirements. Until such a mechanism 527 exists, proxies MUST NOT send P-Media-Authorization headers through 528 untrusted intermediaries. 530 SIP Working Group Informational - Expires 11/02/02 10 531 QoS enabled proxies may need to inspect message bodies describing media 532 streams, e.g. SDP. Consequently, such message bodies SHOULD NOT be 533 encrypted. This will in turn prevent end-to-end confidentiality of said 534 message bodies which lowers the overall security possible. 536 9. IANA Considerations 538 This document defines a new private SIP header for media authorization 539 which is "P-Media-Authorization". 541 10. Notice Regarding Intellectual Property Rights 543 The IETF has been notified of intellectual property rights claimed in 544 regard to some or all of the specification contained in this document. 545 For more information consult the online list of claimed rights. 547 11. Normative References 549 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 550 9, RFC 2026, October 1996. 552 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 553 Levels", BCP 14, RFC 2119, March 1997. 555 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 556 Peterson, J., Sparks, R., Handley, M., E. Schooler, "SIP: 557 Session Initiation Protocol", RFC 3261, February 2002. 559 [4] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 560 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 561 Demon Internet Ltd., November 1997. 563 [5] Herzog, S., RSVP Extensions for Policy Control, RFC 2750, 564 January 2000. 566 12. Informative References 568 [6] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for 569 Policy-based Admission Control", RFC 2753, January 2000. 571 [7] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., 572 "Resource Reservation Protocol (RSVP) -- Version 1 Functional 573 Specification ", RFC 2205, September 1997. 575 [8] Handley, M., Jacobson, V., "SDP: Session Description Protocol", 576 RFC 2327, April 1998. 578 13. Contributors 580 The following people contributed significantly and were co-authors 581 on earlier versions of this spec: 583 K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), 584 Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband 586 SIP Working Group Informational - Expires 11/02/02 11 587 Communications), Mike Mannette (3Com), Kurt Steinbrenner 588 (3Com), Dave Oran (Cisco), John Pickens (Com21), Poornima 589 Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), and 590 Keith Kelly (NetSpeak). 592 14. Acknowledgments 594 The Distributed Call Signaling work in the PacketCable project is 595 the work of a large number of people, representing many different 596 companies. The authors would like to recognize and thank the 597 following for their assistance: John Wheeler, Motorola; David 598 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 599 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 600 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 601 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 602 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 603 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 604 Cable Communications. Dean Willis provided valuable feedback as 605 well. 607 15. Authors' Addresses 609 Bill Marshall 610 AT&T 611 Florham Park, NJ 07932 612 Email: wtm@research.att.com 614 Flemming Andreasen 615 Cisco 616 Edison, NJ 08837 617 Email: fandreas@cisco.com 619 Doc Evans 620 D. R. Evans Consulting 621 Boulder, CO 80303 622 Email: n7dr@arrl.net 624 SIP Working Group Informational - Expires 11/02/02 12 625 Full Copyright Statement 627 Copyright (C) The Internet Society (2002). All Rights Reserved. This 628 document and translations of it may be copied and furnished to 629 others, and derivative works that comment on or otherwise explain it 630 or assist in its implementation may be prepared, copied, published 631 and distributed, in whole or in part, without restriction of any 632 kind, provided that the above copyright notice and this paragraph 633 are included on all such copies and derivative works. However, this 634 document itself may not be modified in any way, such as by removing 635 the copyright notice or references to the Internet Society or other 636 Internet organizations, except as needed for the purpose of 637 developing Internet standards in which case the procedures for 638 copyrights defined in the Internet Standards process must be 639 followed, or as required to translate it into languages other than 640 English. The limited permissions granted above are perpetual and 641 will not be revoked by the Internet Society or its successors or 642 assigns. This document and the information contained herein is 643 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 644 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 645 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 646 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 647 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 649 SIP Working Group Informational - Expires 11/02/02 13