idnits 2.17.1 draft-ietf-sip-manyfolks-resource-04.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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document 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 328 has weird spacing: '...te send no ...' == Line 329 has weird spacing: '...te recv no ...' == Line 435 has weird spacing: '... send rec...' == Line 436 has weird spacing: '... recv sen...' == Line 437 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 [5], 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 (February 25, 2002) is 8089 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 968 looks like a reference -- Missing reference section? '2' on line 972 looks like a reference -- Missing reference section? '3' on line 976 looks like a reference -- Missing reference section? '4' on line 980 looks like a reference -- Missing reference section? '5' on line 984 looks like a reference -- Missing reference section? '6' on line 988 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 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-04.txt 10 February 25, 2002 11 Expires: August, 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 discusses how network quality of service can be made a 39 precondition to establishment of sessions initiated by the Session 40 Initiation Protocol (SIP). These preconditions require that the 41 participant reserve network resources before continuing with the 42 session. We do not define new quality of service reservation 43 mechanisms; these preconditions simply require a participant to use 44 existing resource reservation mechanisms before beginning the 45 session. 47 1 Introduction 49 Some architectures require that at session establishment time, once 50 the callee has been alerted, the chances of a session establishment 51 failure are minimum. One source of failure is the inability to 52 reserve network resources for a session. In order to minimize "ghost 53 rings", it is necessary to reserve network resources for the session 54 before the callee is alerted. However, the reservation of network 55 resources frequently requires learning the IP address, port, and 56 session parameters from the callee. This information is obtained as a 57 result of the initial offer/answer exchange carried in SIP. This 58 exchange normally causes the "phone to ring", thus introducing a 59 chicken-and-egg problem: resources cannot be reserved without 60 performing an initial offer/answer exchange, and the initial 61 offer/answer exchange can't be done without performing resource 62 reservation. 64 The solution is to introduce the concept of a precondition. A 65 precondition is a set of constraints about the session which are 66 introduced in the offer. The recipient of the offer generates an 67 answer, but does not alert the user or otherwise proceed with session 68 establishment. That only occurs when the preconditions are met. This 69 can be known through a local event (such as a confirmation of a 70 resource reservation), or through a new offer sent by the caller. 72 This document deals with sessions that use SIP [1] as signalling 73 protocol and SDP [2] to describe the parameters of the session. 75 We have chosen to include the quality of service preconditions in the 76 SDP description rather than in the SIP header because preconditions 77 are stream specific. 79 2 Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [3]. 85 3 Overview 87 In order to ensure that session establishment does not take place 88 until certain preconditions are met we distinguish between two 89 different state variables that affect a particular media stream: 90 current status and desired status. This document defines quality of 91 service status. 93 The desired status consists of a threshold for the current status. 94 Session establishment stops until the current status reaches or 95 surpasses this threshold. Once this threshold is reached or 96 surpassed, session establishment resumes. 98 For example, the following values for current and desired status 99 would not allow session establishment to resume: 101 current status = resources reserved in the send direction 102 desired status = resources reserved in both (sendrecv) directions 104 On the other hand, the values of the example below would make session 105 establishment resume: 107 current status = resources reserved in both (sendrecv) directions 108 desired status = resources reserved in the send direction 110 These two state variables define a certain piece of state of a media 111 stream the same way as the direction attribute or the codecs in use, 112 define other pieces of state. Consequently, we treat these two new 113 variables in the same way as other SDP media attributes are treated 114 in the offer/answer model used by SIP [4]: they are exchanged between 115 two user agents using an offer and an answer in order to have a 116 shared view of the status of the session. 118 Figure 1 shows a typical message exchange between two SIP user agents 119 using preconditions. A includes quality of service preconditions in 120 the SDP of the initial INVITE. A does not want B to be alerted until 121 there is network resources reserved in both directions (sendrecv) 122 end-to-end. B agrees to reserve network resources for this session 123 before alerting the callee. B will handle resource reservation in the 124 B->A direction, but wants A to handle the A->B direction. To indicate 125 so, B returns a 183 response to A asking A to start resource 126 reservation and to warn B as soon as the A->B direction is ready for 127 the session. A and B both start resource reservation. B finishes 128 reserving resources in the B->A direction, but does not alert the 129 user yet, because network resources in both directions are needed. 130 When A finishes reserving resources in the A->B direction, it sends 131 an UPDATE to B. B returns a 200 (OK) response for the UPDATE 132 indicating that all the preconditions for the session have been met. 133 At this point of time, B starts alerting the user, and session 134 establishment completes normally. 136 4 SDP parameters 138 We define the following media level SDP attributes: 140 current-status = "a=curr:" precondition-type 141 = SP status-type SP direction-tag 142 desired-status = "a=des:" precondition-type 143 = SP strength-tag SP status-type 144 = SP direction-tag 145 confirm-status = "a=conf:" precondition-type 146 = SP status-type SP direction-tag 147 precondition-type = "qos" 148 strength-tag = ("mandatory" | "optional" | "none" 149 = | "failure") 150 status-type = ("e2e" | "local" | "remote") 151 direction-tag = ("none" | "send" | "recv" | "sendrecv") 153 Current status: The current status attribute carries the current 154 status of network resources for a particular media stream. 156 Desired status: The desired status attribute carries the 157 preconditions for a particular media stream. When the 158 current status value has the same or a better value than 159 the desired status value, the preconditions are considered 160 to be met. 162 Confirmation status: The desired status attribute carries 163 threshold conditions for a media stream. When the status of 164 network resources reach these conditions, the peer user 165 agent will send an update of the session description 166 containing an updated current status attribute for this 167 particular media stream. 169 Precondition type: This document defines quality of service 170 preconditions. Extensions may define other types of 171 preconditions. 173 Strength tag: The strength tag indicates whether or not the 174 callee can be alerted in case the network fails to meet the 175 preconditions. 177 Status type: We define two types of status: end-to-end and 178 segmented. The end-to-end status reflects the status of the 179 end-to-end reservation of resources. The segmented status 180 reflects the status of the access network reservations of 181 both user agents. The end-to-end status corresponds to the 182 tag "e2e" defined above and the segmented status to the 183 tags "local" and "remote". End-to-end status is useful when 184 end-to-end resource reservation mechanisms. The segmented 185 status is useful when one or both UAs perform resource 186 reservations on their respective access networks. 188 A B 190 | | 191 |-------------(1) INVITE SDP1--------------->| 192 | | 193 |<------(2) 183 Session Progress SDP 2-------| 194 | *** *** | 195 |--*R*-----------(3) PRACK-------------*R*-->| 196 | *E* *E* | 197 |<-*S*-------(4) 200 OK (PRACK)--------*S*---| 198 | *E* *E* | 199 | *R* *R* | 200 | *V* *V* | 201 | *A* *A* | 202 | *T* *T* | 203 | *I* *I* | 204 | *O* *O* | 205 | *N* *N* | 206 | *** *** | 207 | *** | 208 | *** | 209 |-------------(5) UPDATE SDP3--------------->| 210 | | 211 |<--------(6) 200 OK (UPDATE) SDP4-----------| 212 | | 213 |<-------------(7) 180 Ringing---------------| 214 | | 215 |-----------------(8) PRACK----------------->| 216 | | 217 |<------------(9) 200 OK (PRACK)-------------| 218 | | 219 | | 220 | | 221 |<-----------(10) 200 OK (INVITE)------------| 222 | | 223 |------------------(11) ACK----------------->| 224 | | 225 | | 227 Figure 1: Basic session establishment using preconditions 228 Direction tag: The direction tag indicates the direction a 229 concrete attribute is applicable to. 231 The values of the tags "send", "recv", "local" and "remote" represent 232 the point of view of the entity generating the SDP description. In an 233 offer, "send" is the direction offerer->answerer and "local" is the 234 offerer's access network. In an answer, "send" is the direction 235 answerer->offerer and "local" is the answerer's access network. 237 The following example shows these new SDP attributes in two media 238 lines of a session description: 240 m=audio 20000 RTP/AVP 0 241 a=curr:qos e2e send 242 a=des:qos optional e2e send 243 a=des:qos mandatory e2e recv 244 m=audio 20002 RTP/AVP 0 245 a=curr:qos local sendrecv 246 a=curr:qos remote none 247 a=des:qos optional local sendrecv 248 a=des:qos mandatory remote sendrecv 250 5 Usage of the new SDP status parameters in the SIP offer/answer model 252 Parameter negotiation in SIP is carried out using the offer answer 253 model described in [4]. The idea behind this model is to provide a 254 shared view of the session parameters for both user agents once the 255 answer has been received by the offerer. This section describes which 256 values can our new SDP attributes take in an answer depending on 257 their value in the offer. 259 To achieve a shared view of the status of a media stream, we define a 260 model that consists of three tables: both user agents implement a 261 local status table, and each offer/answer exchange has a transaction 262 status table associated to it. The offerer generates a transaction 263 status table identical to its local status table and sends it to the 264 answerer in the offer. The anwerer uses the information of this 265 transaction status table to update its local status table. The 266 answerer also updates the transaction status table fields that were 267 out of date and returns this table to the offerer in the answer. The 268 offerer can then update its local status table with the information 269 received in the answer. After this offer/answer exchange, the local 270 status tables of both user agents are synchronised. They now have a 271 common view of the status of the media stream. Sessions that involve 272 several media streams implement these tables per media stream. Note, 273 however, that this is a model of user agent behavior, not of 274 software. An implementation is free to take any approach that 275 replicates the external behavior this model defines. 277 5.1 Generating an offer 279 Both user agents MUST implement a table, referred to as "local status 280 table", reflecting the status of the resource reservation. Tables 1 281 and 2 show the format of this tables for both the end-to-end and the 282 segmented status types. For the end-to-end status type, the table 283 contains two rows; one for each direction (i.e., send and recv). A 284 value of "yes" in the "Current" field indicates that resource has 285 been successfully reserved in the corresponding direction. "No" 286 indicates that resources have not been reserved yet. The "Desired 287 Strength" field indicates the strength of the preconditions in the 288 corresponding direction. The table for the segmented status type 289 contains four rows: both directions in the local access network and 290 in the peer's access network. The meaning of the fields is the same 291 as in the end-to-end case. 293 Before generating an offer, the offerer MUST build a transaction 294 status table with the current and the desired status for each media 295 stream. The different values of the strength tag for the desired 296 status attribute have the following semantics: 298 o None: no resource reservation is needed. 300 o Optional: the user agents SHOULD try to provide resource 301 reservation, but the session can continue regardless of 302 whether this provision is possible or not. 304 o Mandatory: the user agents MUST provide resource reservation. 305 Otherwise, session establishment MUST NOT continue. 307 The offerer then decides whether it is going to use the end-to-end 308 status type or the segmented status type. If the status type of the 309 media line will be end-to-end, the user agent generates records with 310 the desired status and the current status for each direction (send 311 and recv) independently, as shown in table 1: 313 Direction Current Desired Strength 314 ____________________________________ 315 send no mandatory 316 recv no mandatory 318 Table 1: Table for the end-to-end status type 319 If the status type of the media line will be segmented, the user 320 agent generates records with the desired status and the current 321 status for each direction (send and recv) and each segment (local and 322 remote) independently, as shown in table 2: 324 Direction Current Desired Strength 325 ______________________________________ 326 local send no none 327 local recv no none 328 remote send no optional 329 remote recv no none 331 Table 2: Table for the segmented status type 333 At the time of sending the offer, the offerer's local status table 334 and the transaction status table contain the same values. 336 With the transaction status table, the user agent generates the 337 current-status and the desired status lines following the syntax of 338 Section 4 and the rules described below in Section 5.1.1. 340 5.1.1 SDP encoding 342 For the end-to-end status type, the user agent MUST generate one 343 current status line with the tag "e2e" for the media stream. If the 344 strength tags for both directions are equal (e.g., both mandatory) in 345 the transaction status table, the user agent MUST add one desired 346 status line with the tag "sendrecv". If both tags are different, the 347 user agent MUST include two desired status lines, one with the tag 348 "send" and the other with the tag "recv". 350 The semantics of two lines with the same strength tag, one 351 with a "send" tag and the other with a "recv" tag, is the 352 same as one "sendrecv" line. However, in order to achieve a 353 more compact encoding, we have chosen to make mandatory the 354 latter format. 356 For the segmented status type, the user agent MUST generate two 357 current status lines: one with the tag "local" and the other with the 358 tag "remote". The user agent MUST add one or two desired status lines 359 per segment (i.e., local and remote). If for a particular segment 360 (local or remote) the tags for both directions in the transaction 361 status table are equal (e.g., both mandatory), the user agent MUST 362 add one desired status line with the tag "sendrecv". If both tags are 363 different, the user agent MUST include two desired status lines, one 364 with the tag "send" and the other with the tag "recv". 366 Note that the rules above apply to the desired strength tag "none" as 367 well. This way, a user agent that supports quality of service but 368 does not intend to use them, adds desired status lines with the 369 strength tag "none". Since this tag can be upgraded in the answer, as 370 described in Section 5.2, the answerer can request quality of service 371 reservation without a need of another offer/answer exchange. 373 The example below shows the SDP corresponding to tables 1 and 2. 375 m=audio 20000 RTP/AVP 0 376 a=curr:qos e2e none 377 a=des:qos mandatory e2e sendrecv 378 m=audio 20002 RTP/AVP 0 379 a=curr:qos local none 380 a=curr:qos remote none 381 a=des:qos optional remote send 382 a=des:qos optional local none 384 5.2 Generating an Answer 386 When the answerer receives the offer, it recreates the transaction 387 status table using the SDP attributes contained in the offer. The 388 answerer updates both its local status and the transaction status 389 table following the rules below: 391 Desired Strength: We define an absolute ordering for the 392 strength tags: none, optional and mandatory. Mandatory is 393 the tag with highest grade and none the tag with lowest 394 grade. An answerer MAY upgrade the desired strength in any 395 entry of the transaction status table, but it MUST NOT 396 downgrade it. Therefore, it is OK to upgrade a row from 397 none to optional, from none to mandatory or from optional 398 to mandatory, but not the other way around. 400 Current Status: For every row, the value of the "Current" field 401 in the transaction status table and in the local status 402 table of the answerer have to be compared. Table 3 shows 403 the four possible combinations. If both fields have the 404 same value (two first rows of table 3, nothing needs to be 405 updated. If the "Current" field of the transaction status 406 table is "Yes" and the field of the local status table is 407 "No" (third row of table 3), the latter MUST be set to 408 "Yes". If the "Current" field of the transaction status 409 table is "No" and the field of the local status table is 410 "Yes" (forth row of table 3), the answerer needs to check 411 if it has local information (e.g., a confirmation of a 412 resource reservation has been received) about that 413 particular current status. If it does, the "Current" field 414 of the transaction status table is set to "Yes". If the 415 answerer does not have local information about that current 416 status, the "Current" field of the local status table MUST 417 be set to "No". 419 Transaction status table Local status table 420 ____________________________________________ 421 no no 422 yes yes 423 yes no 424 no yes 426 Table 3: Possible values for the "Current" fields 428 Once both tables have been updated an answer is generated following 429 the rules described in Section 5.1.1 and taking into account that 430 "send", "recv", "local" and "remote" tags have to be inverted in the 431 answer, as shown in table 4. 433 Offer Answer 434 ______________ 435 send recv 436 recv send 437 local remote 438 remote local 440 Table 4: Values of tags in offer and answers 442 At the time the answer is sent, the transaction status table and the 443 answerer's local status table contain the same values. Therefore, 444 this answer contains the shared view of the status of the media line 445 in the current-status attribute and the negotiated strength and 446 direction tags in the desired-status attribute. 448 If the resource reservation mechanism used requires participation of 449 both user agents, the answerer SHOULD start resource reservation 450 after having sent the answer and the offerer SHOULD start resource 451 reservation as soon as the answer is received. If participation of 452 the peer user agent is not needed (e.g., segmented status type), the 453 offerer MAY start resource reservation before sending the offer and 454 the answerer MAY start it before sending the answer. 456 The status of the resource reservation of a media line can change 457 between two consecutive offer/answer exchanges. Therefore, both user 458 agents MUST keep their local status tables up to date using local 459 information through the duration of the session. 461 6 Suspending and Resuming Session Establishment 463 A user agent server that receives an offer with preconditions 464 SHOULDNOT alert the user until all the mandatory preconditions are 465 met; session establishment is suspended until that moment. 467 A user agent server may receive an INVITE request with no offer in 468 it. In this case, following normal SIP procedures, the user agent 469 server will provide an offer in a reliable response (1xx or 2xx). The 470 user agent client will send the answer in another SIP request. If the 471 offer and the answer contain preconditions, the user agent client 472 SHOULD NOT alert the user until all the mandatory preconditions in 473 the answer are met. 475 While session establishment is suspended, user agents SHOULD not send 476 any data over any media stream. In the case of RTP [5], neither RTP 477 nor RTCP packets are sent. 479 A user agent server knows that all the preconditions are met for a 480 media line when its local status table has a value of "yes" in all 481 the rows whose strength tag is "mandatory". When the preconditions of 482 all the media lines of the session are met, session establishment 483 SHOULD resume. 485 For an initial INVITE suspending and resuming session establishment 486 is very intuitive. The callee will not be alerted until all the 487 mandatory preconditions are met. However, offers containing 488 preconditions sent in the middle of an ongoing session need further 489 explanation. Both user agents SHOULD continue using the old session 490 parameters until all the mandatory preconditions are met. At that 491 moment, the user agents can begin using the new session parameters. 492 Section 10 contains an example of this situation. 494 7 Status Confirmation 496 The qos-confirm-status attribute MAY be used in both offers and 497 answers. This attribute represents a threshold for the resource 498 reservation. When this threshold is reached or surpassed, the user 499 agent MUST send an offer to the peer user agent reflecting the new 500 current status of the media line. If this threshold is crossed again 501 (e.g., the network stops providing resources for the media stream), 502 the user agent MUST send a new offer as well. 504 If a peer has requested confirmation on a particular stream, an agent 505 MUST mark that stream with a flag in its local status table. When all 506 the rows with this flag have a value of "yes", the user agent MUST 507 send a new offer to the peer. This offer will contain the current 508 status of resource reservation in the qos-current-status attributes. 509 If later any of the rows with this flag transition to "No", a new 510 offer MUST be sent as well. 512 Confirmation attributes are not negotiated. The answerer uses the 513 value of the qos-confirm-status attribute in the offer and the 514 offerer uses the value of this attribute in the answer. 516 For example, if a user agent receives an SDP description with the 517 following attributes: 519 m=audio 20002 RTP/AVP 0 520 a=curr:qos local none 521 a=curr:qos remote none 522 a=des:qos mandatory local sendrecv 523 a=des:qos mandatory remote sendrecv 524 a=conf:qos remote sendrecv 526 It will send an offer as soon as it reserves resources in its access 527 network ("remote" tag in the received message) for both directions 528 (sendrecv). 530 8 Refusing an offer 532 We define a new SIP status code: 534 Server-Error = "580" ;Precondition Failure 536 When an answerer cannot or is not willing to meet the preconditions 537 in the offer it SHOULD reject the offer by returning a 580 538 (Precondition-Failure) response. This response SHOULD contain an SDP 539 description indicating which desired status triggered the failure. 540 The corresponding desired status line MUST a value of the strength 541 tag of "failure", as shown in the example below: 543 m=audio 20000 RTP/AVP 0 544 a=des:qos failure e2e send 546 SDP description indicating this type of failure MUST follow the 547 format for describing media capabilities defined in the SIP 548 offer/answer model [4]. 550 Using the 580 (Precondition Failure) status code to refuse an offer 551 is useful when the offer came in an INVITE or in an UPDATE request. 552 However, SIP does not provide a means to refuse offers that contained 553 in a response (1xx or 2xx) to an INVITE. 555 If a UAC generates an initial INVITE without an offer and receives an 556 offer in a 1xx or 2xx response which is not acceptable, it SHOULD 557 respond to this offer with a correctly formed answer and immediately 558 after that send a CANCEL or a BYE. 560 If the offer comes in a 1xx or 2xx response to a re-INVITE, A would 561 not have a way to reject it without terminating the session at the 562 same time. The same recommendation given in Section 14.2 of [1] 563 applies here: 565 "The UAS MUST ensure that the session description overlaps 566 with its previous session description in media formats, 567 transports, other parameters that require support from the 568 peer. This is to avoid the need for the peer to reject the 569 session description. If, however, it is unacceptable to A, 570 A SHOULD generate an answer with a valid session 571 description, and then send a BYE to terminate the session." 573 9 Option tag for Require and Supported header fields 575 We define the option tag "precondition" for use in the Require and 576 Supported header fields. An offerer MUST include this tag if the 577 offer contains one or more strength tags with the value "mandatory". 578 If all the strength tags in the description are "optional" or "none" 579 the offerer MUST include this tag either in a Supported header field 580 or in a Require header field. It is, however, RECOMMENDED, that the 581 Supported header field is used in this case. The lack of 582 preconditions in the answer would indicate that the answerer did not 583 support this extension. 585 The mapping of offers and answers to SIP requests and responses is 586 performed following the rules given in . Therefore, a user agent 587 including preconditions in the SDP MUST include both "100rel" [6] and 588 "update" tags in the Require header field. 590 10 Examples 592 The following examples cover both status types; end-to-end and 593 segmented. 595 10.1 End-to-end Status Type 597 The call flow of figure 2 shows a basic session establishment using 598 the end-to-end status type. The SDP descriptions of this example are 599 shown below: 601 SDP1: B includes end-to-end quality of service preconditions in the 602 initial offer. 604 m=audio 20000 RTP/AVP 0 605 c=IN IP4 192.0.2.1 606 a=curr:qos e2e none 607 a=des:qos mandatory e2e sendrecv 609 SDP2: Since B uses RSVP, it can know when resources in its "send" 610 direction are available, because it will receive RESV messages from 611 the network. However, it does not know the status of the reservations 612 in the other direction. B requests confirmation for resource 613 reservations in its "recv" direction to the peer user agent A in its 614 answer. 616 m=audio 30000 RTP/AVP 0 617 c=IN IP4 192.0.2.4 618 a=curr:qos e2e none 619 a=des:qos mandatory e2e sendrecv 620 a=conf:qos e2e recv 622 After having sent the answer B starts reserving network resources for 623 the media stream. When A receives this answer (2) it starts 624 performing resource reservation as well. Both UAs use RSVP, so A 625 sends PATH messages towards B and B sends PATH messages towards A. 627 As time passes by, B receives RESV messages confirming the 628 reservation. However, B waits until resources in the other direction 629 as reserved as well since it did not receive any confirmation and the 630 preconditions still have not been met. 632 SDP3: When A receives RESV messages it sends an updated offer (5) to 633 B: 635 m=audio 20000 RTP/AVP 0 636 c=IN IP4 192.0.2.1 637 a=curr:qos e2e send 638 a=des:qos mandatory e2e sendrecv 640 SDP4: B responds with an answer (6) which contains the current status 641 of the resource reservation (i.e., sendrecv): 643 m=audio 30000 RTP/AVP 0 644 c=IN IP4 192.0.2.4 645 a=curr:qos e2e sendrecv 646 a=des:qos mandatory e2e sendrecv 648 At this point of time, session establishment resumes and B returns a 649 180 (Ringing) response (7). 651 Note that now the media stream has been already established, and A 652 has received a 180 (Ringing) response. Since the direction of the 653 stream is "sendrecv", A will not generate local ringback, since it 654 assumes that it will receive early media over this stream. 656 However, if B wants A to generate local ringback, it can put the 657 media stream on hold in SDP4. In this case, B would put the media 658 stream off hold by sending an offer in the 200 OK for the INVITE (8). 659 The contents of the messages for this alternative flow is shown 660 below: 662 SDP4 (on hold): 664 m=audio 30000 RTP/AVP 0 665 c=IN IP4 192.0.2.4 666 a=recvonly 667 a=curr:qos e2e sendrecv 668 a=des:qos mandatory e2e sendrecv 670 SDP5 in the 200 OK (10): 672 m=audio 30000 RTP/AVP 0 673 c=IN IP4 192.0.2.4 674 a=sendrecv 675 a=curr:qos e2e sendrecv 676 a=des:qos mandatory e2e sendrecv 678 SDP6 in the ACK (11): 680 m=audio 20000 RTP/AVP 0 681 c=IN IP4 192.0.2.1 682 a=sendrecv 683 a=curr:qos e2e sendrecv 684 a=des:qos mandatory e2e sendrecv 686 Let's assume that in the middle of the session A wishes to change the 687 A B 689 | | 690 |-------------(1) INVITE SDP1--------------->| 691 | | 692 |<------(2) 183 Session Progress SDP 2-------| 693 | *** *** | 694 |--*R*-----------(3) PRACK-------------*R*-->| 695 | *E* *E* | 696 |<-*S*-------(4) 200 OK (PRACK)--------*S*---| 697 | *E* *E* | 698 | *R* *R* | 699 | *V* *V* | 700 | *A* *A* | 701 | *T* *T* | 702 | *I* *I* | 703 | *O* *O* | 704 | *N* *N* | 705 | *** *** | 706 | *** | 707 | *** | 708 |-------------(5) UPDATE SDP3--------------->| 709 | | 710 |<--------(6) 200 OK (UPDATE) SDP4-----------| 711 | | 712 |<-------------(7) 180 Ringing---------------| 713 | | 714 |-----------------(8) PRACK----------------->| 715 | | 716 |<------------(9) 200 OK (PRACK)-------------| 717 | | 718 | | 719 | | 720 |<-----------(10) 200 OK (INVITE)------------| 721 | | 722 |------------------(11) ACK----------------->| 723 | | 724 | | 726 Figure 2: Example using the end-to-end status type 727 IP address where it is receiving media. Figure 3 shows this scenario. 729 A B 731 | | 732 |-------------(1) INVITE SDP1--------------->| 733 | | 734 |<------(2) 183 Session Progress SDP 2-------| 735 | *** *** | 736 |--*R*-----------(3) PRACK-------------*R*-->| 737 | *E* *E* | 738 |<-*S*-------(4) 200 OK (PRACK)--------*S*---| 739 | *E* *E* | 740 | *R* *R* | 741 | *V* *V* | 742 | *A* *A* | 743 | *T* *T* | 744 | *I* *I* | 745 | *O* *O* | 746 | *N* *N* | 747 | *** *** | 748 | *** | 749 | *** | 750 |-------------(5) UPDATE SDP3--------------->| 751 | | 752 |<--------(6) 200 OK (UPDATE) SDP4-----------| 753 | | 754 |<-----------(7) 200 OK (INVITE)-------------| 755 | | 756 |------------------(8) ACK------------------>| 757 | | 758 | | 760 Figure 3: Session modification with preconditions 762 SDP1: A includes an offer in a re-INVITE (1). A continues to receive 763 media on the old IP address (192.0.2.1), but it is ready to receive 764 media on the new one as well (192.0.2.2): 766 m=audio 20000 RTP/AVP 0 767 c=IN IP4 192.0.2.2 768 a=curr:qos e2e none 769 a=des:qos mandatory e2e sendrecv 771 SDP2: B includes a "confirm" tag in its answer. B continues sending 772 media to the old remote IP address (192.0.2.1) 774 m=audio 30000 RTP/AVP 0 775 c=IN IP4 192.0.2.4 776 a=curr:qos e2e none 777 a=des:qos mandatory e2e sendrecv confirm 779 SDP3: When A receives RESV messages it sends an updated offer (5) to 780 B: 782 m=audio 20000 RTP/AVP 0 783 c=IN IP4 192.0.2.2 784 a=curr:qos e2e send 785 a=des:qos mandatory e2e sendrecv 787 SDP4: B responds with an answer (6) indicating that the preconditions 788 have been met (current status "sendrecv). It is now when B begins 789 sending media to the new remote IP address (192.0.2.2). 791 m=audio 30000 RTP/AVP 0 792 c=IN IP4 192.0.2.4 793 a=curr:qos e2e sendrecv 794 a=des:qos mandatory e2e sendrecv 796 10.2 Segmented Status Type 798 The call flow of figure 4 shows a basic session establishment using 799 the segmented status type. The SDP descriptions of this example are 800 shown below: 802 SDP1: B includes local and remote QoS preconditions in the initial 803 offer. Before sending the initial offer, A reserves resources in its 804 access network. This is indicated in the local current status of the 805 SDP below: 807 m=audio 20000 RTP/AVP 0 8 808 c=IN IP4 192.0.2.1 809 a=curr:qos local sendrecv 810 a=curr:qos remote none 811 a=des:qos mandatory local sendrecv 812 a=des:qos mandatory remote sendrecv 814 SDP2: B reserves resources in its access network and, since all the 815 preconditions are met, returns an answer in a 180 (Ringing) response 816 (3). 818 m=audio 30000 RTP/AVP 0 8 819 c=IN IP4 192.0.2.4 820 a=curr:qos local sendrecv 821 a=curr:qos remote sendrecv 822 a=des:qos mandatory local sendrecv 823 a=des:qos mandatory remote sendrecv 825 Let's assume that after receiving this response A decides that it 826 wants to use only PCM u-law (payload 0), as opposed to both PCM u-law 827 and A-law (payload 8). It would send an UPDATE to B possibly before 828 receiving the 200 OK for the INVITE (5). The SDP would look like: 830 m=audio 20000 RTP/AVP 0 831 c=IN IP4 192.0.2.1 832 a=curr:qos local sendrecv 833 a=curr:qos remote sendrecv 834 a=des:qos mandatory local sendrecv 835 a=des:qos mandatory remote sendrecv 837 B would generate an answer for this offer and place it in the 200 OK 838 for the UPDATE. 840 Note that this last offer/answer to reduce the number of supported 841 codecs may arrive to the user agent server after the 200 OK response 842 has been generated. This would mean that the session is established 843 before A has reduced the number of supported codecs. To avoid this 844 situation, the user agent client could wait for the first answer from 845 the user agent before setting its local current status to "sendrecv". 847 11 Security Considerations 849 An entity in the middle of two user agents establishing a session may 850 add desired-status attributes making session establishment 851 impossible. It could also modify the content of the current-status 852 parameters so that the session is established without meeting the 853 preconditions. Integrity protection can be used to avoid this 854 attacks. 856 A B 858 | *** | 859 | *R* | 860 | *E* | 861 | *S* | 862 | *E* | 863 | *R* | 864 | *V* | 865 | *A* | 866 | *T* | 867 | *I* | 868 | *O* | 869 | *N* | 870 | *** | 871 |-------------(1) INVITE SDP1--------------->| 872 | *** | 873 | *R* | 874 | *E* | 875 | *S* | 876 | *E* | 877 | *R* | 878 | *V* | 879 | *A* | 880 | *T* | 881 | *I* | 882 | *O* | 883 | *N* | 884 | *** | 885 |<----------(2) 180 Ringing SDP2-------------| 886 | | 887 |----------------(3) PRACK------------------>| 888 | | 889 |<-----------(4) 200 OK (PRACK)--------------| 890 | | 891 | | 892 |<-----------(5) 200 OK (INVITE)-------------| 893 | | 894 |------------------(6) ACK------------------>| 895 | | 896 | | 898 Figure 4: Example using the segmented status type 900 An entity performing resource reservations upon reception of 901 unathenticated requests carrying preconditions can be an easy target 902 for a denial of service attack. Requests with preconditions SHOULD be 904 12 IANA considerations 906 This document defines three media level SDP attributes: desired- 907 status, current-status and conf-status. Their format is defined in 908 Section 4. 910 Section 4 also one standard precondition-type related to the 911 attributes above: "qos". If in the future it was needed to 912 standardize further precondition-types, they would need to be defined 913 in a standards track document. 915 This document also defines a new SIP status code (580). Its default 916 reason phrase (Precondition Failure) is defined in section 8. 918 13 Contributors 920 The following persons contributed to early versions of this spec: 922 K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn 923 Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), 924 Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), 925 Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens 926 (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain 927 Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly 928 (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), 929 Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia 930 University). 932 14 Acknowledgments 934 The Distributed Call Signaling work in the PacketCable project is the 935 work of a large number of people, representing many different 936 companies. The authors would like to recognize and thank the 937 following for their assistance: John Wheeler, Motorola; David 938 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jay Strater, 939 Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido 940 Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi 941 Khazai, Nortel; John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, 942 Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, 943 AT&T; Telcordia Technologies; and Lucent Cable Communications. 945 15 Authors' Addresses 947 Gonzalo Camarillo 948 Ericsson 949 Advanced Signalling Research Lab. 950 FIN-02420 Jorvas 951 Finland 952 electronic mail: Gonzalo.Camarillo@ericsson.com 954 Bill Marshall 955 AT&T 956 Florham Park, NJ 07932 957 USA 958 electronic mail: wtm@research.att.com 960 Jonathan Rosenberg 961 dynamicsoft 962 West Orange, NJ 07052 963 USA 964 electronic mail: jdrosen@dynamicsoft.com 966 16 Bibliography 968 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 969 protocol," Internet Draft, Internet Engineering Task Force, Feb. 970 2002. Work in progress. 972 [2] M. Handley and V. Jacobson, "SDP: session description protocol," 973 Request for Comments 2327, Internet Engineering Task Force, Apr. 974 1998. 976 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 977 levels," Request for Comments 2119, Internet Engineering Task Force, 978 Mar. 1997. 980 [4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with 981 SDP," Internet Draft, Internet Engineering Task Force, Jan. 2002. 982 Work in progress. 984 [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 985 transport protocol for real-time applications," Request for Comments 986 1889, Internet Engineering Task Force, Jan. 1996. 988 [6] J. Rosenberg and H. Schulzrinne, "Reliability of provisional 989 responses in SIP," Internet Draft, Internet Engineering Task Force, 990 Sept. 2001. Work in progress. 992 Full Copyright Statement 994 Copyright (c) The Internet Society (2002). All Rights Reserved. 996 This document and translations of it may be copied and furnished to 997 others, and derivative works that comment on or otherwise explain it 998 or assist in its implementation may be prepared, copied, published 999 and distributed, in whole or in part, without restriction of any 1000 kind, provided that the above copyright notice and this paragraph are 1001 included on all such copies and derivative works. However, this 1002 document itself may not be modified in any way, such as by removing 1003 the copyright notice or references to the Internet Society or other 1004 Internet organizations, except as needed for the purpose of 1005 developing Internet standards in which case the procedures for 1006 copyrights defined in the Internet Standards process must be 1007 followed, or as required to translate it into languages other than 1008 English. 1010 The limited permissions granted above are perpetual and will not be 1011 revoked by the Internet Society or its successors or assigns. 1013 This document and the information contained herein is provided on an 1014 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1015 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1016 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1017 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1018 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1020 Notice Regarding Intellectual Property Rights 1022 The IETF has been notified of intellectual property rights claimed in 1023 regard to some or all of the specification contained in this 1024 document. For more information consult the online list of claimed 1025 rights.