idnits 2.17.1 draft-ietf-sip-manyfolks-resource-06.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 366 has weird spacing: '...te send no ...' == Line 367 has weird spacing: '...te recv no ...' == Line 474 has weird spacing: '... send rec...' == Line 475 has weird spacing: '... recv sen...' == Line 476 has weird spacing: '... local remo...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: While session establishment is suspended, user agents SHOULD not send any data over any media stream. In the case of RTP [6], neither RTP nor RTCP packets are sent. -- 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.) -- The document date (March 25, 2002) is 8039 days in the past. Is this intentional? 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 1203 looks like a reference -- Missing reference section? '2' on line 1207 looks like a reference -- Missing reference section? '3' on line 1211 looks like a reference -- Missing reference section? '4' on line 1215 looks like a reference -- Missing reference section? '5' on line 1219 looks like a reference -- Missing reference section? '6' on line 1222 looks like a reference -- Missing reference section? '7' on line 1226 looks like a reference -- Missing reference section? '8' on line 1230 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIP WG 3 Internet Draft G. Camarillo (Editor) 4 Ericsson 5 W. Marshall (Editor) 6 AT&T 7 Jonathan Rosenberg 8 dynamicsoft 9 draft-ietf-sip-manyfolks-resource-06.txt 10 March 25, 2002 11 Expires: September, 2002 13 Integration of Resource Management and SIP 15 STATUS OF THIS MEMO 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 To view the list Internet-Draft Shadow Directories, see 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document defines a generic framework for preconditions which is 39 extensible through IANA registration. This document also discusses 40 how network quality of service can be made a precondition to 41 establishment of sessions initiated by the Session Initiation 42 Protocol (SIP). These preconditions require that the participant 43 reserve network resources before continuing with the session. We do 44 not define new quality of service reservation mechanisms; these 45 preconditions simply require a participant to use existing resource 46 reservation mechanisms before beginning the session. 48 Table of Contents 50 1 Introduction ........................................ 3 51 2 Terminology ......................................... 3 52 3 Overview ............................................ 3 53 4 SDP parameters ...................................... 4 54 5 Usage of preconditions with offer/answer ............ 7 55 5.1 Generating an offer ................................. 8 56 5.1.1 SDP encoding ........................................ 9 57 5.2 Generating an Answer ................................ 10 58 6 Suspending and Resuming Session Establishment ....... 12 59 7 Status Confirmation ................................. 13 60 8 Refusing an offer ................................... 14 61 8.1 Rejecting a Media Stream ............................ 15 62 9 Unknown Precondition Type ........................... 15 63 10 Option Tag for Preconditions ........................ 15 64 11 Indicating Capabilities ............................. 16 65 12 Examples ............................................ 16 66 12.1 End-to-end Status Type .............................. 16 67 12.2 Segmented Status Type ............................... 21 68 12.3 Offer in a SIP response ............................. 22 69 13 Security Considerations ............................. 26 70 14 IANA considerations ................................. 26 71 15 Contributors ........................................ 26 72 16 Acknowledgments ..................................... 27 73 17 Authors' Addresses .................................. 27 74 18 Bibliography ........................................ 28 76 1 Introduction 78 Some architectures require that at session establishment time, once 79 the callee has been alerted, the chances of a session establishment 80 failure are minimum. One source of failure is the inability to 81 reserve network resources for a session. In order to minimize "ghost 82 rings", it is necessary to reserve network resources for the session 83 before the callee is alerted. However, the reservation of network 84 resources frequently requires learning the IP address, port, and 85 session parameters from the callee. This information is obtained as a 86 result of the initial offer/answer exchange carried in SIP. This 87 exchange normally causes the "phone to ring", thus introducing a 88 chicken-and-egg problem: resources cannot be reserved without 89 performing an initial offer/answer exchange, and the initial 90 offer/answer exchange can't be done without performing resource 91 reservation. 93 The solution is to introduce the concept of a precondition. A 94 precondition is a set of constraints about the session which are 95 introduced in the offer. The recipient of the offer generates an 96 answer, but does not alert the user or otherwise proceed with session 97 establishment. That only occurs when the preconditions are met. This 98 can be known through a local event (such as a confirmation of a 99 resource reservation), or through a new offer sent by the caller. 101 This document deals with sessions that use SIP [1] as signalling 102 protocol and SDP [2] to describe the parameters of the session. 104 We have chosen to include the quality of service preconditions in the 105 SDP description rather than in the SIP header because preconditions 106 are stream specific. 108 2 Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [3]. 114 3 Overview 116 In order to ensure that session establishment does not take place 117 until certain preconditions are met we distinguish between two 118 different state variables that affect a particular media stream: 119 current status and desired status. This document defines quality of 120 service status. 122 The desired status consists of a threshold for the current status. 123 Session establishment stops until the current status reaches or 124 surpasses this threshold. Once this threshold is reached or 125 surpassed, session establishment resumes. 127 For example, the following values for current and desired status 128 would not allow session establishment to resume: 130 current status = resources reserved in the send direction 131 desired status = resources reserved in both (sendrecv) directions 133 On the other hand, the values of the example below would make session 134 establishment resume: 136 current status = resources reserved in both (sendrecv) directions 137 desired status = resources reserved in the send direction 139 These two state variables define a certain piece of state of a media 140 stream the same way as the direction attribute or the codecs in use, 141 define other pieces of state. Consequently, we treat these two new 142 variables in the same way as other SDP media attributes are treated 143 in the offer/answer model used by SIP [4]: they are exchanged between 144 two user agents using an offer and an answer in order to have a 145 shared view of the status of the session. 147 Figure 1 shows a typical message exchange between two SIP user agents 148 using preconditions. A includes quality of service preconditions in 149 the SDP of the initial INVITE. A does not want B to be alerted until 150 there is network resources reserved in both directions (sendrecv) 151 end-to-end. B agrees to reserve network resources for this session 152 before alerting the callee. B will handle resource reservation in the 153 B->A direction, but needs A to handle the A->B direction. To indicate 154 so, B returns a 183 response to A asking A to start resource 155 reservation and to confirm to B as soon as the A->B direction is 156 ready for the session. A and B both start resource reservation. B 157 finishes reserving resources in the B->A direction, but does not 158 alert the user yet, because network resources in both directions are 159 needed. When A finishes reserving resources in the A->B direction, it 160 sends an UPDATE [5] to B. B returns a 200 (OK) response for the 161 UPDATE indicating that all the preconditions for the session have 162 been met. At this point of time, B starts alerting the user, and 163 session establishment completes normally. 165 4 SDP parameters 167 We define the following media level SDP attributes: 169 current-status = "a=curr:" precondition-type 170 SP status-type SP direction-tag 171 desired-status = "a=des:" precondition-type 172 SP strength-tag SP status-type 173 SP direction-tag 174 confirm-status = "a=conf:" precondition-type 175 SP status-type SP direction-tag 176 precondition-type = "qos" | token 177 strength-tag = ("mandatory" | "optional" | "none" 178 = | "failure" | "unknown") 179 status-type = ("e2e" | "local" | "remote") 180 direction-tag = ("none" | "send" | "recv" | "sendrecv") 182 Current status: The current status attribute carries the current 183 status of network resources for a particular media stream. 185 Desired status: The desired status attribute carries the 186 preconditions for a particular media stream. When the 187 direction-tag of the current status attribute with a given 188 precondition-type/status-type for a particular stream is 189 equal to (or better than) the direction-tag of the desired 190 status attribute with the same precondition-type/status- 191 type for that stream, then the preconditions are considered 192 to be met for that stream. 194 Confirmation status: The confirmation status attribute carries 195 threshold conditions for a media stream. When the status of 196 network resources reach these conditions, the peer user 197 agent will send an update of the session description 198 containing an updated current status attribute for this 199 particular media stream. 201 Precondition type: This document defines quality of service 202 preconditions. Extensions may define other types of 203 preconditions. 205 Strength tag: The strength-tag indicates whether or not the 206 callee can be alerted in case the network fails to meet the 207 preconditions. 209 Status type: We define two types of status: end-to-end and 210 segmented. The end-to-end status reflects the status of the 211 end-to-end reservation of resources. The segmented status 212 reflects the status of the access network reservations of 213 both user agents. The end-to-end status corresponds to the 214 tag "e2e" defined above and the segmented status to the 215 tags "local" and "remote". End-to-end status is useful when 217 A B 219 | | 220 |-------------(1) INVITE SDP1--------------->| 221 | | 222 |<------(2) 183 Session Progress SDP 2-------| 223 | *** *** | 224 |--*R*-----------(3) PRACK-------------*R*-->| 225 | *E* *E* | 226 |<-*S*-------(4) 200 OK (PRACK)--------*S*---| 227 | *E* *E* | 228 | *R* *R* | 229 | *V* *V* | 230 | *A* *A* | 231 | *T* *T* | 232 | *I* *I* | 233 | *O* *O* | 234 | *N* *N* | 235 | *** *** | 236 | *** | 237 | *** | 238 |-------------(5) UPDATE SDP3--------------->| 239 | | 240 |<--------(6) 200 OK (UPDATE) SDP4-----------| 241 | | 242 |<-------------(7) 180 Ringing---------------| 243 | | 244 |-----------------(8) PRACK----------------->| 245 | | 246 |<------------(9) 200 OK (PRACK)-------------| 247 | | 248 | | 249 | | 250 |<-----------(10) 200 OK (INVITE)------------| 251 | | 252 |------------------(11) ACK----------------->| 253 | | 254 | | 256 Figure 1: Basic session establishment using preconditions 257 end-to-end resource reservation mechanisms are available. 258 The segmented status is useful when one or both UAs perform 259 resource reservations on their respective access networks. 260 Note that the use of the segmented status type does not 261 prevent bottlenecks in the backbone, only in the access 262 networks. 264 Direction tag: The direction-tag indicates the direction a 265 particular attribute (current, desired or confirmation 266 status) is applicable to. 268 The values of the tags "send", "recv", "local" and "remote" represent 269 the point of view of the entity generating the SDP description. In an 270 offer, "send" is the direction offerer->answerer and "local" is the 271 offerer's access network. In an answer, "send" is the direction 272 answerer->offerer and "local" is the answerer's access network. 274 The following example shows these new SDP attributes in two media 275 lines of a session description: 277 m=audio 20000 RTP/AVP 0 278 a=curr:qos e2e send 279 a=des:qos optional e2e send 280 a=des:qos mandatory e2e recv 281 m=audio 20002 RTP/AVP 0 282 a=curr:qos local sendrecv 283 a=curr:qos remote none 284 a=des:qos optional local sendrecv 285 a=des:qos mandatory remote sendrecv 287 5 Usage of preconditions with offer/answer 289 Parameter negotiation in SIP is carried out using the offer/answer 290 model described in [4]. The idea behind this model is to provide a 291 shared view of the session parameters for both user agents once the 292 answer has been received by the offerer. This section describes which 293 values our new SDP attributes can take in an answer depending on 294 their value in the offer. 296 To achieve a shared view of the status of a media stream, we define a 297 model that consists of three tables: both user agents implement a 298 local status table, and each offer/answer exchange has a transaction 299 status table associated to it. The offerer generates a transaction 300 status table identical to its local status table and sends it to the 301 answerer in the offer. The anwerer uses the information of this 302 transaction status table to update its local status table. The 303 answerer also updates the transaction status table fields that were 304 out of date and returns this table to the offerer in the answer. The 305 offerer can then update its local status table with the information 306 received in the answer. After this offer/answer exchange, the local 307 status tables of both user agents are synchronised. They now have a 308 common view of the status of the media stream. Sessions that involve 309 several media streams implement these tables per media stream. Note, 310 however, that this is a model of user agent behavior, not of 311 software. An implementation is free to take any approach that 312 replicates the external behavior this model defines. 314 5.1 Generating an offer 316 Both user agents MUST maintain local precondition status, which is 317 referred to as a "local status table". Tables 1 and 2 show the format 318 of these tables for both the end-to-end and the segmented status 319 types. For the end-to-end status type, the table contains two rows; 320 one for each direction (i.e., send and recv). A value of "yes" in the 321 "Current" field indicates that resource has been successfully 322 reserved in the corresponding direction. "No" indicates that 323 resources have not been reserved yet. The "Desired Strength" field 324 indicates the strength of the preconditions in the corresponding 325 direction. The table for the segmented status type contains four 326 rows: both directions in the local access network and in the peer's 327 access network. The meaning of the fields is the same as in the end- 328 to-end case. 330 Before generating an offer, the offerer MUST build a transaction 331 status table with the current and the desired status for each media 332 stream. The different values of the strength-tag for the desired 333 status attribute have the following semantics: 335 o None: no resource reservation is needed. 337 o Optional: the user agents SHOULD try to provide resource 338 reservation, but the session can continue regardless of 339 whether this provision is possible or not. 341 o Mandatory: the user agents MUST provide resource reservation. 342 Otherwise, session establishment MUST NOT continue. 344 The offerer then decides whether it is going to use the end-to-end 345 status type or the segmented status type. If the status type of the 346 media line will be end-to-end, the user agent generates records with 347 the desired status and the current status for each direction (send 348 and recv) independently, as shown in table 1: 350 Direction Current Desired Strength 351 ____________________________________ 352 send no mandatory 353 recv no mandatory 355 Table 1: Table for the end-to-end status type 357 If the status type of the media line will be segmented, the user 358 agent generates records with the desired status and the current 359 status for each direction (send and recv) and each segment (local and 360 remote) independently, as shown in table 2: 362 Direction Current Desired Strength 363 ______________________________________ 364 local send no none 365 local recv no none 366 remote send no optional 367 remote recv no none 369 Table 2: Table for the segmented status type 371 At the time of sending the offer, the offerer's local status table 372 and the transaction status table contain the same values. 374 With the transaction status table, the user agent MUST generate the 375 current-status and the desired status lines following the syntax of 376 Section 4 and the rules described below in Section 5.1.1. 378 5.1.1 SDP encoding 380 For the end-to-end status type, the user agent MUST generate one 381 current status line with the tag "e2e" for the media stream. If the 382 strength-tags for both directions are equal (e.g., both "mandatory") 383 in the transaction status table, the user agent MUST add one desired 384 status line with the tag "sendrecv". If both tags are different, the 385 user agent MUST include two desired status lines, one with the tag 386 "send" and the other with the tag "recv". 388 The semantics of two lines with the same strength-tag, one 389 with a "send" tag and the other with a "recv" tag, is the 390 same as one "sendrecv" line. However, in order to achieve a 391 more compact encoding, we have chosen to make mandatory the 392 latter format. 394 For the segmented status type, the user agent MUST generate two 395 current status lines: one with the tag "local" and the other with the 396 tag "remote". The user agent MUST add one or two desired status lines 397 per segment (i.e., local and remote). If for a particular segment 398 (local or remote) the tags for both directions in the transaction 399 status table are equal (e.g., both "mandatory"), the user agent MUST 400 add one desired status line with the tag "sendrecv". If both tags are 401 different, the user agent MUST include two desired status lines, one 402 with the tag "send" and the other with the tag "recv". 404 Note that the rules above apply to the desired strength-tag "none" as 405 well. This way, a user agent that supports quality of service but 406 does not intend to use them, adds desired status lines with the 407 strength-tag "none". Since this tag can be upgraded in the answer, as 408 described in Section 5.2, the answerer can request quality of service 409 reservation without a need of another offer/answer exchange. 411 The example below shows the SDP corresponding to tables 1 and 2. 413 m=audio 20000 RTP/AVP 0 414 a=curr:qos e2e none 415 a=des:qos mandatory e2e sendrecv 416 m=audio 20002 RTP/AVP 0 417 a=curr:qos local none 418 a=curr:qos remote none 419 a=des:qos optional remote send 420 a=des:qos optional local none 422 5.2 Generating an Answer 424 When the answerer receives the offer, it recreates the transaction 425 status table using the SDP attributes contained in the offer. The 426 answerer updates both its local status and the transaction status 427 table following the rules below: 429 Desired Strength: We define an absolute ordering for the 430 strength-tags: "none", "optional" and "mandatory". 431 "Mandatory" is the tag with highest grade and "none" the 432 tag with lowest grade. An answerer MAY upgrade the desired 433 strength in any entry of the transaction status table, but 434 it MUST NOT downgrade it. Therefore, it is OK to upgrade a 435 row from "none" to "optional", from "none" to "mandatory" 436 or from "optional" to "mandatory", but not the other way 437 around. 439 Current Status: For every row, the value of the "Current" field 440 in the transaction status table and in the local status 441 table of the answerer have to be compared. Table 3 shows 442 the four possible combinations. If both fields have the 443 same value (two first rows of table 3, nothing needs to be 444 updated. If the "Current" field of the transaction status 445 table is "Yes" and the field of the local status table is 446 "No" (third row of table 3), the latter MUST be set to 447 "Yes". If the "Current" field of the transaction status 448 table is "No" and the field of the local status table is 449 "Yes" (forth row of table 3), the answerer needs to check 450 if it has local information (e.g., a confirmation of a 451 resource reservation has been received) about that 452 particular current status. If it does, the "Current" field 453 of the transaction status table is set to "Yes". If the 454 answerer does not have local information about that current 455 status, the "Current" field of the local status table MUST 456 be set to "No". 458 Transac. status table Local status table New values transac./local 459 ____________________________________________________________________ 460 no no no/no 461 yes yes yes/yes 462 yes no yes/yes 463 no yes depends on local info 465 Table 3: Possible values for the "Current" fields 467 Once both tables have been updated, an answer MUST be generated 468 following the rules described in Section 5.1.1 and taking into 469 account that "send", "recv", "local" and "remote" tags have to be 470 inverted in the answer, as shown in table 4. 472 Offer Answer 473 ______________ 474 send recv 475 recv send 476 local remote 477 remote local 479 Table 4: Values of tags in offer and answers 481 At the time the answer is sent, the transaction status table and the 482 answerer's local status table contain the same values. Therefore, 483 this answer contains the shared view of the status of the media line 484 in the current-status attribute and the negotiated strength and 485 direction-tags in the desired-status attribute. 487 If the resource reservation mechanism used requires participation of 488 both user agents, the answerer SHOULD start resource reservation 489 after having sent the answer and the offerer SHOULD start resource 490 reservation as soon as the answer is received. If participation of 491 the peer user agent is not needed (e.g., segmented status type), the 492 offerer MAY start resource reservation before sending the offer and 493 the answerer MAY start it before sending the answer. 495 The status of the resource reservation of a media line can change 496 between two consecutive offer/answer exchanges. Therefore, both user 497 agents MUST keep their local status tables up to date using local 498 information through the duration of the session. 500 6 Suspending and Resuming Session Establishment 502 A user agent server that receives an offer with preconditions SHOULD 503 NOT alert the user until all the mandatory preconditions are met; 504 session establishment is suspended until that moment (e.g., a PSTN 505 gateway reserves resources without sending signalling to the PSTN.) 507 A user agent server may receive an INVITE request with no offer in 508 it. In this case, following normal procedures defined in [1] and in 509 [5], the user agent server will provide an offer in a reliable 1xx 510 response. The user agent client will send the answer in another SIP 511 request (i.e., the PRACK for the 1xx). If the offer and the answer 512 contain preconditions, the user agent server SHOULD NOT alert the 513 user until all the mandatory preconditions in the answer are met. 515 Note that in this case, a user agent server providing a 516 initial offer with preconditions, a 180 (Ringing) response 517 will never be sent, since the user agent server cannot 518 alert the user until all the preconditions are met. 520 A UAS that is not capable of unilaterally meeting all of the 521 mandatory preconditions MUST include a confirm-status attribute in 522 the SDP (offer or answer) that it sends (see Section 7). Further, the 523 SDP (offer or answer) that contains this confirm-status attribute 524 MUST be sent as soon as allowed by the SIP offer/answer rules. 526 While session establishment is suspended, user agents SHOULD not send 527 any data over any media stream. In the case of RTP [6], neither RTP 528 nor RTCP packets are sent. 530 A user agent server knows that all the preconditions are met for a 531 media line when its local status table has a value of "yes" in all 532 the rows whose strength-tag is "mandatory". When the preconditions of 533 all the media lines of the session are met, session establishment 534 SHOULD resume. 536 For an initial INVITE suspending and resuming session establishment 537 is very intuitive. The callee will not be alerted until all the 538 mandatory preconditions are met. However, offers containing 539 preconditions sent in the middle of an ongoing session need further 540 explanation. Both user agents SHOULD continue using the old session 541 parameters until all the mandatory preconditions are met. At that 542 moment, the user agents can begin using the new session parameters. 543 Section 12 contains an example of this situation. 545 7 Status Confirmation 547 The confirm-status attribute MAY be used in both offers and answers. 548 This attribute represents a threshold for the resource reservation. 549 When this threshold is reached or surpassed, the user agent MUST send 550 an offer to the peer user agent reflecting the new current status of 551 the media line as soon as allowed by the SIP offer/answer rules. If 552 this threshold is crossed again (e.g., the network stops providing 553 resources for the media stream), the user agent MUST send a new offer 554 as well as soon as allowed by the SIP offer/answer rules. 556 If a peer has requested confirmation on a particular stream, an agent 557 MUST mark that stream with a flag in its local status table. When all 558 the rows with this flag have a value of "yes", the user agent MUST 559 send a new offer to the peer. This offer will contain the current 560 status of resource reservation in the current-status attributes. If 561 later any of the rows with this flag transition to "No", a new offer 562 MUST be sent as well. 564 Confirmation attributes are not negotiated. The answerer uses the 565 value of the confirm-status attribute in the offer and the offerer 566 uses the value of this attribute in the answer. 568 For example, if a user agent receives an SDP description with the 569 following attributes: 571 m=audio 20002 RTP/AVP 0 572 a=curr:qos local none 573 a=curr:qos remote none 574 a=des:qos mandatory local sendrecv 575 a=des:qos mandatory remote sendrecv 576 a=conf:qos remote sendrecv 578 It will send an offer as soon as it reserves resources in its access 579 network ("remote" tag in the received message) for both directions 580 (sendrecv). 582 8 Refusing an offer 584 We define a new SIP status code: 586 Server-Error = "580" ;Precondition Failure 588 When a UAS acting as an answerer cannot or is not willing to meet the 589 preconditions in the offer it SHOULD reject the offer by returning a 590 580 (Precondition-Failure) response. This response SHOULD contain an 591 SDP description indicating which desired status triggered the 592 failure. The corresponding desired status line MUST use the "failure" 593 strength-tag, as shown in the example below: 595 m=audio 20000 RTP/AVP 0 596 a=des:qos failure e2e send 598 SDP description indicating this type of failure MUST follow the 599 format for describing media capabilities defined in the SIP 600 offer/answer model [4]. 602 Using the 580 (Precondition Failure) status code to refuse an offer 603 is useful when the offer came in an INVITE or in an UPDATE request. 604 However, SIP does not provide a means to refuse offers that contained 605 in a response (1xx or 2xx) to an INVITE. 607 If a UAC generates an initial INVITE without an offer and receives an 608 offer in a 1xx or 2xx response which is not acceptable, it SHOULD 609 respond to this offer with a correctly formed answer and immediately 610 after that send a CANCEL or a BYE. 612 If the offer comes in a 1xx or 2xx response to a re-INVITE, A would 613 not have a way to reject it without terminating the session at the 614 same time. The same recommendation given in Section 14.2 of [1] 615 applies here: 617 "The UAS MUST ensure that the session description overlaps 618 with its previous session description in media formats, 619 transports, other parameters that require support from the 620 peer. This is to avoid the need for the peer to reject the 621 session description. If, however, it is unacceptable to A, 622 A SHOULD generate an answer with a valid session 623 description, and then send a BYE to terminate the session." 625 8.1 Rejecting a Media Stream 627 In the offer/answer model when an answerer wishes to reject a media 628 stream it sets its port to zero. The presence of preconditions does 629 not change this behaviour; streams are still rejected by setting 630 their port to zero. 632 Both the offerer and the answerer MUST ignore all the preconditions 633 that affect a stream with its port set to zero. They are not taken 634 into consideration to decide whether or not session establishment can 635 resume. 637 9 Unknown Precondition Type 639 This document defines the "qos" tag for quality of service 640 preconditions. New precondition-types defined in the future will have 641 new associated tags. A UA that receives an unknown precondition-type 642 with a "mandatory" strength-tag in an offer MUST refuse the offer 643 unless the only unknown mandatory preconditions have the "local" tag. 644 In this case, the UA does not need to be involved in order to meet 645 the preconditions. The UA will ask for confirmation of the 646 preconditions and, when the confirmation arrives, it will resume 647 session establishment. 649 A UA refusing an offer follows the rules described in section 8, but 650 instead of the tag "failure", it uses the tag "unknown", as shown in 651 the example below: 653 m=audio 20000 RTP/AVP 0 654 a=des:foo unknown e2e send 656 10 Option Tag for Preconditions 658 We define the option tag "precondition" for use in the Require and 659 Supported header fields. An offerer MUST include this tag in the 660 Require header field if the offer contains one or more "mandatory" 661 strength-tags. If all the strength-tags in the description are 662 "optional" or "none" the offerer MUST include this tag either in a 663 Supported header field or in a Require header field. It is, however, 664 RECOMMENDED, that the Supported header field is used in this case. 665 The lack of preconditions in the answer would indicate that the 666 answerer did not support this extension. 668 The mapping of offers and answers to SIP requests and responses is 669 performed following the rules given in [5]. Therefore, a user agent 670 including preconditions in the SDP MUST support the PRACK method, and 671 consequently, MUST include the "100rel" [7] tag in the Require header 672 field. 674 A user agent including preconditions in the SDP SHOULD support the 675 UPDATE method. If it is supported, an "update" [5] tag MUST be 676 included in the Require header field. 678 User agents that use preconditions but do not support 679 UPDATE can only be used in a limited set of scenarios, such 680 as the one described in figure 4. 682 11 Indicating Capabilities 684 The offer/answer model [4] describes the format of a session 685 description to indicate capabilities. This format is used in 686 responses to OPTIONS requests. A UA that supports preconditions 687 SHOULD add desired status lines indicating the precondition-types 688 supported for each media stream. These lines MUST have the "none" 689 strength-tag, as shown in the example below: 691 m=audio 0 RTP/AVP 0 692 a=rtpmap:0 PCMU/8000 693 a=des:foo none e2e sendrecv 694 a=des:qos none local sendrecv 696 Note that when this document was published, the precondition-type 697 "foo" has not been registered. It is used here in the session 698 description above to provide an example with multiple precondition- 699 types. 701 A UA that supports this framework SHOULD add a "precondition" tag to 702 the Supported header field of its responses to OPTIONS requests. 704 12 Examples 706 The following examples cover both status types; end-to-end and 707 segmented. 709 12.1 End-to-end Status Type 711 The call flow of figure 2 shows a basic session establishment using 712 the end-to-end status type. The SDP descriptions of this example are 713 shown below: 715 SDP1: A includes end-to-end quality of service preconditions in the 716 initial offer. 718 m=audio 20000 RTP/AVP 0 719 c=IN IP4 192.0.2.1 720 a=curr:qos e2e none 721 a=des:qos mandatory e2e sendrecv 723 SDP2: Since B uses RSVP, it can know when resources in its "send" 724 direction are available, because it will receive RESV messages from 725 the network. However, it does not know the status of the reservations 726 in the other direction. B requests confirmation for resource 727 reservations in its "recv" direction to the peer user agent A in its 728 answer. 730 m=audio 30000 RTP/AVP 0 731 c=IN IP4 192.0.2.4 732 a=curr:qos e2e none 733 a=des:qos mandatory e2e sendrecv 734 a=conf:qos e2e recv 736 After having sent the answer B starts reserving network resources for 737 the media stream. When A receives this answer (2) it starts 738 performing resource reservation as well. Both UAs use RSVP, so A 739 sends PATH messages towards B and B sends PATH messages towards A. 741 As time passes by, B receives RESV messages confirming the 742 reservation. However, B waits until resources in the other direction 743 are reserved as well since it did not receive any confirmation and 744 the preconditions still have not been met. 746 SDP3: When A receives RESV messages it sends an updated offer (5) to 747 B: 749 m=audio 20000 RTP/AVP 0 750 c=IN IP4 192.0.2.1 751 a=curr:qos e2e send 752 a=des:qos mandatory e2e sendrecv 754 SDP4: B responds with an answer (6) which contains the current status 755 of the resource reservation (i.e., sendrecv): 757 m=audio 30000 RTP/AVP 0 758 c=IN IP4 192.0.2.4 759 a=curr:qos e2e sendrecv 760 a=des:qos mandatory e2e sendrecv 762 At this point of time, session establishment resumes and B returns a 763 180 (Ringing) response (7). 765 Note that now the media stream has been already established, and A 766 has received a 180 (Ringing) response. Since the direction of the 767 stream is "sendrecv", A will not generate local ringback, since it 768 assumes that it will receive early media over this stream. 770 However, if B wants A to generate local ringback, it can put the 771 media stream on hold in SDP4. In this case, B would put the media 772 stream off hold by sending an offer in an UPDATE request which would 773 be sent at the same time as the 200 OK for the INVITE (10). The 774 contents of the messages for this alternative flow are shown below: 776 SDP4 (on hold): 778 m=audio 30000 RTP/AVP 0 779 c=IN IP4 192.0.2.4 780 a=recvonly 781 a=curr:qos e2e sendrecv 782 a=des:qos mandatory e2e sendrecv 784 SDP5 in an UPDATE: 786 m=audio 30000 RTP/AVP 0 787 c=IN IP4 192.0.2.4 788 a=sendrecv 789 a=curr:qos e2e sendrecv 790 a=des:qos mandatory e2e sendrecv 792 SDP6 in the 200 OK for the UPDATE: 794 m=audio 20000 RTP/AVP 0 795 c=IN IP4 192.0.2.1 796 a=sendrecv 797 a=curr:qos e2e sendrecv 798 a=des:qos mandatory e2e sendrecv 800 Let's assume that in the middle of the session A wishes to change the 801 IP address where it is receiving media. Figure 3 shows this scenario. 803 A B 805 | | 806 |-------------(1) INVITE SDP1--------------->| 807 | | 808 |<------(2) 183 Session Progress SDP 2-------| 809 | *** *** | 810 |--*R*-----------(3) PRACK-------------*R*-->| 811 | *E* *E* | 812 |<-*S*-------(4) 200 OK (PRACK)--------*S*---| 813 | *E* *E* | 814 | *R* *R* | 815 | *V* *V* | 816 | *A* *A* | 817 | *T* *T* | 818 | *I* *I* | 819 | *O* *O* | 820 | *N* *N* | 821 | *** *** | 822 | *** | 823 | *** | 824 |-------------(5) UPDATE SDP3--------------->| 825 | | 826 |<--------(6) 200 OK (UPDATE) SDP4-----------| 827 | | 828 |<-------------(7) 180 Ringing---------------| 829 | | 830 |-----------------(8) PRACK----------------->| 831 | | 832 |<------------(9) 200 OK (PRACK)-------------| 833 | | 834 | | 835 | | 836 |<-----------(10) 200 OK (INVITE)------------| 837 | | 838 |------------------(11) ACK----------------->| 839 | | 840 | | 842 Figure 2: Example using the end-to-end status type 843 A B 845 | | 846 |-------------(1) INVITE SDP1--------------->| 847 | | 848 |<------(2) 183 Session Progress SDP 2-------| 849 | *** *** | 850 |--*R*-----------(3) PRACK-------------*R*-->| 851 | *E* *E* | 852 |<-*S*-------(4) 200 OK (PRACK)--------*S*---| 853 | *E* *E* | 854 | *R* *R* | 855 | *V* *V* | 856 | *A* *A* | 857 | *T* *T* | 858 | *I* *I* | 859 | *O* *O* | 860 | *N* *N* | 861 | *** *** | 862 | *** | 863 | *** | 864 |-------------(5) UPDATE SDP3--------------->| 865 | | 866 |<--------(6) 200 OK (UPDATE) SDP4-----------| 867 | | 868 |<-----------(7) 200 OK (INVITE)-------------| 869 | | 870 |------------------(8) ACK------------------>| 871 | | 872 | | 874 Figure 3: Session modification with preconditions 876 SDP1: A includes an offer in a re-INVITE (1). A continues to receive 877 media on the old IP address (192.0.2.1), but it is ready to receive 878 media on the new one as well (192.0.2.2): 880 m=audio 20000 RTP/AVP 0 881 c=IN IP4 192.0.2.2 882 a=curr:qos e2e none 883 a=des:qos mandatory e2e sendrecv 885 SDP2: B includes a "conf" attribute in its answer. B continues 886 sending media to the old remote IP address (192.0.2.1) 888 m=audio 30000 RTP/AVP 0 889 c=IN IP4 192.0.2.4 890 a=curr:qos e2e none 891 a=des:qos mandatory e2e sendrecv 892 a=conf:qos e2e recv 894 SDP3: When A receives RESV messages it sends an updated offer (5) to 895 B: 897 m=audio 20000 RTP/AVP 0 898 c=IN IP4 192.0.2.2 899 a=curr:qos e2e send 900 a=des:qos mandatory e2e sendrecv 902 SDP4: B responds with an answer (6) indicating that the preconditions 903 have been met (current status "sendrecv). It is now when B begins 904 sending media to the new remote IP address (192.0.2.2). 906 m=audio 30000 RTP/AVP 0 907 c=IN IP4 192.0.2.4 908 a=curr:qos e2e sendrecv 909 a=des:qos mandatory e2e sendrecv 911 12.2 Segmented Status Type 913 The call flow of figure 4 shows a basic session establishment using 914 the segmented status type. The SDP descriptions of this example are 915 shown below: 917 SDP1: A includes local and remote QoS preconditions in the initial 918 offer. Before sending the initial offer, A reserves resources in its 919 access network. This is indicated in the local current status of the 920 SDP below: 922 m=audio 20000 RTP/AVP 0 8 923 c=IN IP4 192.0.2.1 924 a=curr:qos local sendrecv 925 a=curr:qos remote none 926 a=des:qos mandatory local sendrecv 927 a=des:qos mandatory remote sendrecv 929 SDP2: B reserves resources in its access network and, since all the 930 preconditions are met, returns an answer in a 180 (Ringing) response 931 (3). 933 m=audio 30000 RTP/AVP 0 8 934 c=IN IP4 192.0.2.4 935 a=curr:qos local sendrecv 936 a=curr:qos remote sendrecv 937 a=des:qos mandatory local sendrecv 938 a=des:qos mandatory remote sendrecv 940 Let's assume that after receiving this response A decides that it 941 wants to use only PCM u-law (payload 0), as opposed to both PCM u-law 942 and A-law (payload 8). It would send an UPDATE to B possibly before 943 receiving the 200 OK for the INVITE (5). The SDP would look like: 945 m=audio 20000 RTP/AVP 0 946 c=IN IP4 192.0.2.1 947 a=curr:qos local sendrecv 948 a=curr:qos remote sendrecv 949 a=des:qos mandatory local sendrecv 950 a=des:qos mandatory remote sendrecv 952 B would generate an answer for this offer and place it in the 200 OK 953 for the UPDATE. 955 Note that this last offer/answer to reduce the number of supported 956 codecs may arrive to the user agent server after the 200 OK response 957 has been generated. This would mean that the session is established 958 before A has reduced the number of supported codecs. To avoid this 959 situation, the user agent client could wait for the first answer from 960 the user agent before setting its local current status to "sendrecv". 962 12.3 Offer in a SIP response 964 The call flow of figure 5 shows a basic session establishment where 965 the initial offer appears in a reliable 1xx response. This example 966 uses the end-to-end status type. The SDP descriptions of this example 967 are shown below: 969 The first INVITE) (1) does not contain a session description. 970 Therefore, the initial offer is sent by B in a reliable 183 response. 972 SDP1: B includes end-to-end quality of service preconditions in the 973 initial offer. Since B uses RSVP, it can know when resources in its 974 A B 976 | *** | 977 | *R* | 978 | *E* | 979 | *S* | 980 | *E* | 981 | *R* | 982 | *V* | 983 | *A* | 984 | *T* | 985 | *I* | 986 | *O* | 987 | *N* | 988 | *** | 989 |-------------(1) INVITE SDP1--------------->| 990 | *** | 991 | *R* | 992 | *E* | 993 | *S* | 994 | *E* | 995 | *R* | 996 | *V* | 997 | *A* | 998 | *T* | 999 | *I* | 1000 | *O* | 1001 | *N* | 1002 | *** | 1003 |<----------(2) 180 Ringing SDP2-------------| 1004 | | 1005 |----------------(3) PRACK------------------>| 1006 | | 1007 |<-----------(4) 200 OK (PRACK)--------------| 1008 | | 1009 | | 1010 |<-----------(5) 200 OK (INVITE)-------------| 1011 | | 1012 |------------------(6) ACK------------------>| 1013 | | 1014 | | 1016 Figure 4: Example using the segmented status type 1017 A B 1019 | | 1020 |----------------(1) INVITE----------------->| 1021 | | 1022 |<------(2) 183 Session Progress SDP 1-------| 1023 | | 1024 |---------------(3) PRACK SDP 2------------->| 1025 | *** *** | 1026 |<-*R*--------(4) 200 OK (PRACK)-------*R*---| 1027 | *E* *E* | 1028 | *S* *S* | 1029 | *E* *E* | 1030 | *R* *R* | 1031 | *V* *V* | 1032 | *A* *A* | 1033 | *T* *T* | 1034 | *I* *I* | 1035 | *O* *O* | 1036 | *N* *N* | 1037 | *** *** | 1038 |-------------(5) UPDATE SDP3----------***-->| 1039 | *** | 1040 |<--------(6) 200 OK (UPDATE) SDP4-----***---| 1041 | *** | 1042 | *** | 1043 | *** | 1044 |<-------------(7) 180 Ringing---------------| 1045 | | 1046 |-----------------(8) PRACK----------------->| 1047 | | 1048 |<------------(9) 200 OK (PRACK)-------------| 1049 | | 1050 | | 1051 | | 1052 |<-----------(10) 200 OK (INVITE)------------| 1053 | | 1054 |------------------(11) ACK----------------->| 1055 | | 1057 Figure 5: Example of an initial offer in a 1xx response 1058 "send" direction are available, because it will receive RESV messages 1059 from the network. However, it does not know the status of the 1060 reservations in the other direction. B requests confirmation for 1061 resource reservations in its "recv" direction to the peer user agent 1062 A in its answer. 1064 m=audio 30000 RTP/AVP 0 1065 c=IN IP4 192.0.2.4 1066 a=curr:qos e2e none 1067 a=des:qos mandatory e2e sendrecv 1068 a=conf:qos e2e recv 1070 SDP2: A includes its answer if the PRACK for the 183 response. 1072 m=audio 20000 RTP/AVP 0 1073 c=IN IP4 192.0.2.1 1074 a=curr:qos e2e none 1075 a=des:qos mandatory e2e sendrecv 1077 After having sent the answer A starts reserving network resources for 1078 the media stream. When B receives this answer (3) it starts 1079 performing resource reservation as well. Both UAs use RSVP, so A 1080 sends PATH messages towards B and B sends PATH messages towards A. 1082 SDP3: When A receives RESV messages it sends an updated offer (5) to 1083 B: 1085 m=audio 20000 RTP/AVP 0 1086 c=IN IP4 192.0.2.1 1087 a=curr:qos e2e send 1088 a=des:qos mandatory e2e sendrecv 1090 SDP4: B responds with an answer (6) which contains the current status 1091 of the resource reservation (i.e., recv): 1093 m=audio 30000 RTP/AVP 0 1094 c=IN IP4 192.0.2.4 1095 a=curr:qos e2e recv 1096 a=des:qos mandatory e2e sendrecv 1098 As time passes by, B receives RESV messages confirming the 1099 reservation. At this point of time, session establishment resumes and 1100 B returns a 180 (Ringing) response (7). 1102 13 Security Considerations 1104 An entity in the middle of two user agents establishing a session may 1105 add desired-status attributes making session establishment 1106 impossible. It could also modify the content of the current-status 1107 parameters so that the session is established without meeting the 1108 preconditions. Integrity protection can be used to avoid these 1109 attacks. 1111 An entity performing resource reservations upon reception of 1112 unathenticated requests carrying preconditions can be an easy target 1113 for a denial of service attack. Requests with preconditions SHOULD be 1114 authenticated. 1116 14 IANA considerations 1118 This document defines three media level SDP attributes: desired- 1119 status, current-status and conf-status. Their format is defined in 1120 Section 4. 1122 Section 4 also defines one standard precondition-type related to the 1123 attributes above: "qos". If in the future it was needed to 1124 standardize further precondition-types, they would need to be defined 1125 in a standards track document. Future precondition-types MUST define 1126 the semantics with respect to the offer/answer model, as this 1127 document defined these semantics for quality of service preconditions 1128 in Section 5. 1130 This document also defines a new SIP status code (580). Its default 1131 reason phrase (Precondition Failure) is defined in section 8. 1133 This document defines a SIP option tag (precondition) in section 10. 1135 15 Contributors 1137 The following persons contributed and were co-authors on earlier 1138 versions of this spec: 1140 K. K. Ramakrishnan (TeraOptic Networks), Ed Miller 1141 (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific 1142 Broadband Communications), Mike Mannette (3Com), Kurt 1143 Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen 1144 (Cisco), Michael Ramalho (Cisco), John Pickens (Com21), 1145 Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain 1146 Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly 1147 (NetSpeak), Adam Roach (dynamicsoft), Dean Willis 1148 (dynamicsoft), Steve Donovan (dynamicsoft), Henning 1149 Schulzrinne (Columbia University). 1151 This "manyfolks" draft is the culmination of over two years of work 1152 by many individuals, most are listed here and in the following 1153 acknowledgements section. A special note is due to Flemming 1154 Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek, 1155 Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike 1156 Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach, 1157 Jonathan Rosenberg, and Henning Schulzrinne for spearheading the 1158 initial "single INVITE" quality of service preconditions work from 1159 previous, non-SIP compatible, "two-stage Invite" proposals. These 1160 "two-stage INVITE" proposals had their origins from Distributed Call 1161 Signaling work in PacketCable, which, in turn, had architectural 1162 elements from AT&T's Distributed Open Systems Architecture (DOSA) 1163 work [8]. 1165 16 Acknowledgments 1167 The Distributed Call Signaling work in the PacketCable project is the 1168 work of a large number of people, representing many different 1169 companies. The authors would like to recognize and thank the 1170 following for their assistance: John Wheeler, Motorola; David 1171 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, 1172 Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido 1173 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 1174 Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, 1175 Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, 1176 AT&T; Telcordia Technologies; and Lucent Cable Communications. 1178 Miguel Angel Garcia, Rohan May and Mark Watson provided helpful 1179 comments and suggestions. 1181 17 Authors' Addresses 1183 Gonzalo Camarillo 1184 Ericsson 1185 Advanced Signalling Research Lab. 1186 FIN-02420 Jorvas 1187 Finland 1188 electronic mail: Gonzalo.Camarillo@ericsson.com 1190 Bill Marshall 1191 AT&T 1192 Florham Park, NJ 07932 1193 USA 1194 electronic mail: wtm@research.att.com 1195 Jonathan Rosenberg 1196 dynamicsoft 1197 West Orange, NJ 07052 1198 USA 1199 electronic mail: jdrosen@dynamicsoft.com 1201 18 Bibliography 1203 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 1204 protocol," Internet Draft, Internet Engineering Task Force, Feb. 1205 2002. Work in progress. 1207 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 1208 Request for Comments 2327, Internet Engineering Task Force, Apr. 1209 1998. 1211 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 1212 levels," Request for Comments 2119, Internet Engineering Task Force, 1213 Mar. 1997. 1215 [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 1216 SDP," Internet Draft, Internet Engineering Task Force, Feb. 2002. 1217 Work in progress. 1219 [5] J. Rosenberg, "The SIP UPDATE method," Internet Draft, Internet 1220 Engineering Task Force, Mar. 2002. Work in progress. 1222 [6] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 1223 transport protocol for real-time applications," Request for Comments 1224 1889, Internet Engineering Task Force, Jan. 1996. 1226 [7] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 1227 responses in SIP," Internet Draft, Internet Engineering Task Force, 1228 Feb. 2002. Work in progress. 1230 [8] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. 1231 Ramakrishnan, "DOSA: an architecture for providing robust IP 1232 telephony service," in Proceedings of the Conference on Computer 1233 Communications (IEEE Infocom) , (Tel Aviv, Israel), Mar. 2000. 1235 Full Copyright Statement 1237 Copyright (c) The Internet Society (2002). All Rights Reserved. 1239 This document and translations of it may be copied and furnished to 1240 others, and derivative works that comment on or otherwise explain it 1241 or assist in its implementation may be prepared, copied, published 1242 and distributed, in whole or in part, without restriction of any 1243 kind, provided that the above copyright notice and this paragraph are 1244 included on all such copies and derivative works. However, this 1245 document itself may not be modified in any way, such as by removing 1246 the copyright notice or references to the Internet Society or other 1247 Internet organizations, except as needed for the purpose of 1248 developing Internet standards in which case the procedures for 1249 copyrights defined in the Internet Standards process must be 1250 followed, or as required to translate it into languages other than 1251 English. 1253 The limited permissions granted above are perpetual and will not be 1254 revoked by the Internet Society or its successors or assigns. 1256 This document and the information contained herein is provided on an 1257 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1258 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1259 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1260 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1261 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1263 Notice Regarding Intellectual Property Rights 1265 The IETF has been notified of intellectual property rights claimed in 1266 regard to some or all of the specification contained in this 1267 document. For more information consult the online list of claimed 1268 rights.