idnits 2.17.1 draft-ietf-sipping-sip-offeranswer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 922. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 289 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 399: '... "It MUST NOT generate a new ...' RFC 2119 keyword, line 400: '...ed or rejected. It MUST NOT generate a...' RFC 2119 keyword, line 639: '... line) MUST NOT change for th...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (May 28, 2007) is 6171 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) == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-04 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group T. Sawada 3 Internet Draft KDDI Corporation 4 Expires: November 2007 P. Kyzivat 5 Cisco Systems, Inc. 6 May 28, 2007 8 SIP (Session Initiation Protocol) Usage of Offer/Answer Model 9 draft-ietf-sipping-sip-offeranswer-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on November 28, 2007. 36 Abstract 38 SIP utilizes offer/answer model to establish and update multimedia 39 sessions. The descriptions on how to use offer/answer in SIP are 40 dispersed in the multiple RFCs. This document summarizes all the 41 current usage of offer/answer model in SIP communication. 43 Table of Contents 45 1. Summary of SIP usage of Offer/Answer Model...................2 46 1.1. Offer/Answer Exchange Pairs in SIP Messages.............3 47 1.2. Rejection against an Offer..............................4 48 1.3. Session Description which is not Offer nor Answer........5 49 2. Detailed Discussion on Offer/Answer Model for SIP............5 50 2.1. Offer/Answer for INVITE method with 100rel extension.....5 51 2.1.1. INVITE Request with SDP............................6 52 2.1.2. INVITE request without SDP.........................8 53 2.2. Offer/Answer Exchange in Early Dialog...................9 54 2.3. Offer/Answer Exchange in Established Dialog.............9 55 3. Exceptional Case Handling...................................10 56 3.1. Message Crossing Case Handling.........................10 57 3.2. Glare Case Handling....................................11 58 4. Content of Offers and Answers...............................12 59 4.1. General Principle for Constructing Offers and Answers...12 60 4.2. Choice of Media Types and Formats to Include and Exclude13 61 4.2.1. Sending Initial INVITE with Offer.................13 62 4.2.2. Responding with Offer when Initial INVITE has no Offer13 63 4.2.3. Answering Initial INVITE with Offer...............14 64 4.2.4. Answering when Initial INVITE had no Offer.........14 65 4.2.5. Subsequent Offers and Answers.....................14 66 4.3. Hold and Resume of media...............................15 67 5. Remaining Issues or Best Practices on Offer/Answer..........16 68 5.1. Rejecting PRACK Offer..................................16 69 5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 70 Transaction................................................17 71 6. Add New Offer/Answer Usage in SIP...........................18 72 6.1. Explicit Usage........................................18 73 6.2. Rejection of an Offer..................................19 74 6.3. Backward Compatibility.................................19 75 6.4. Exceptional Case Handling..............................19 76 7. Security Considerations.....................................19 77 8. References.................................................19 78 8.1. Normative References...................................19 79 8.2. Informative References.................................19 80 Author's Addresses............................................20 81 Full Copyright Statement.......................................20 82 Intellectual Property Statement................................20 83 Acknowledgment................................................21 85 1. Summary of SIP usage of Offer/Answer Model 87 The offer/answer model itself is independent from the higher layer 88 application protocols which utilize it. SIP is one of the 89 applications using offer/answer model. In RFC 3264 [3], which defines 90 the offer/answer model, which SIP message should convey an offer or 91 an answer is not defined. This should be defined in the SIP core and 92 extensions RFCs. 94 In theory, any SIP message can include a session description in its 95 body. But a session description in a SIP message is not necessarily 96 an offer or an answer. Only the session description that conforms to 97 the rules described in the standard track RFCs can be interpreted as 98 an offer or an answer. The rules for how to handle the offer/answer 99 model are currently defined in several RFCs. 101 The offer/answer model defines the update of sessions. In SIP, dialog 102 is used to match the offer/answer exchange to the session which is to 103 be updated with it. In other words, only the offer/answer exchange in 104 the SIP dialog can update the session which is managed with it. 106 1.1. Offer/Answer Exchange Pairs in SIP Messages 108 Currently, the rules on offer/answer model are defined in RFC 3261 109 [1], RFC 3262 [2] and RFC 3311 [4]. In these RFCs, only the six 110 patterns shown in Table 1 are defined for exchanging an offer and an 111 answer with SIP messages. 113 Note that an offer/answer exchange initiated by an INVITE request 114 must follow exactly one of the patterns 1, 2, 3, 4. Only one of them, 115 one for each dialog if multiple dialogs are created, must occur in an 116 INVITE 3-way handshake process. Pattern 2 and pattern 4 can occur 117 only when the INVITE request does not include an offer. 'The first 118 reliable non-failure message' must have an offer if there is no offer 119 in the INVITE request. This means that UA which receives the INVITE 120 request without an offer must include an offer in the first reliable 121 response with 100rel extension. If no reliable provisional response 122 has been sent, the UAS must include an offer when sending 2xx 123 response. 125 In pattern 3, the first reliable provisional response may or may not 126 have an answer. When a reliable provisional response contains a 127 session description, and is the first to do so, then that session 128 description is the answer to the offer in the INVITE request. 130 In pattern 5, a PRACK request can contain an offer only if the 131 reliable response which it acknowledges contains an answer in the 132 previous offer/answer exchange. 134 Offer Answer RFC Ini Est Early 135 ------------------------------------------------------------------- 136 1. INVITE Req. 2xx INVITE Resp. RFC 3261 O O X 137 2. 2xx INVITE Resp. ACK Req. RFC 3261 O O X 138 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 O O X 139 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 O O X 140 5. PRACK Req. 200 PRACK Resp. RFC 3262 X O O 141 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 X O O 143 Table 1. Summary of SIP Usage of Offer/Answer Model 145 In Table 1, '1xx-rel' corresponds to the reliable provisional 146 response which contains the 100rel option defined in RFC 3262 [2]. 148 'Ini' column shows the ability to exchange the offer/answer to 149 initiate the session. 'O' indicates that the pattern can be used in 150 the initial offer/answer exchange, while 'X' indicates that it can 151 not. Only the initial INVITE transaction can be used to exchange the 152 offer/answer to establish multimedia session. 154 'Est' column shows the ability to update the established session. 156 'Early' column shows the ability to be used to modify the established 157 session in an early dialog. There are two ways to exchange a 158 subsequent offer/answer in an early dialog. 160 1.2. Rejection against an Offer 162 How to reject an offer when it can not be accepted is not so clear 163 and some methods can not allow explicit rejection against an offer. 164 Corresponding to the patterns in Table 1, how to reject an offer is 165 shown in Table 2. 167 When a UA receives an INVITE request with an offer which it can not 168 accept, it should respond with a 488 response, preferably with 169 Warning header field indicating the reason of the rejection unless 170 another response code is more appropriate to reject it. (Pattern 1 171 and Pattern 3) 173 When a UA receives an UPDATE request with an offer which it can not 174 accept, it should respond with a 488 response preferably with Warning 175 header field indicating the reason of the rejection, unless another 176 response code is more appropriate to reject it. (Pattern 6) 178 When a UA receives a PRACK request with an offer which it can not 179 accept, it may respond with a 200 response with a syntactically 180 correct session description followed by an UPDATE request possibly to 181 rearrange the session parameters if both ends support UPDATE method. 183 A UA may simply give up continuing the dialog and send an error 184 response to the INVITE request. (Pattern 5) 186 When a UA receives a response with an offer which it can not accept, 187 a UA does not have a way to reject it explicitly. Therefore, a UA 188 should respond to the offer with the correct session description and 189 rearrange the session parameters by initiating a new offer/answer 190 exchange, or just terminate the session. (Pattern 2 and Pattern 4) 191 When initiating a new offer/answer, a UA should take care not to 192 cause a never-ending offer/answer loop. 194 Offer Rejection 195 ----------------------------------------------------- 196 1. INVITE Req. 488 INVITE Response 197 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 198 3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 199 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 200 5. PRACK Req. (*) 200 PRACK Resp. followed by new offer 201 6. UPDATE Req. 488 UPDATE Response 203 Table 2. Rejection against an Offer 205 (*) UA should only use PRACK to send an offer when it has strong 206 reasons to assume the receiver will accept. 208 1.3. Session Description which is not Offer nor Answer 210 As previously stated, a session description in a SIP message is not 211 necessarily an offer or an answer. For example, SIP can use a session 212 description to describe capabilities apart from offer/answer exchange. 213 Examples of this are 200 OK responses for OPTIONS and 488 responses 214 for INVITE. 216 2. Detailed Discussion on Offer/Answer Model for SIP 218 2.1. Offer/Answer for INVITE method with 100rel extension 220 The INVITE method provides the basic procedure for offer/answer 221 exchange in SIP. Without the 100rel option, the rules are simple as 222 described in RFC 3261 [1]. If an INVITE request includes a session 223 description, pattern 1 is applied and if an INVITE request does not 224 include a session description, pattern 2 is applied. 226 With 100rel, pattern 3 and pattern 4 are added and this makes the 227 rules complicated. An INVITE request may cause multiple responses. 228 Note that even if both UAs support the 100rel extension, not all the 229 provisional responses may be sent reliably. Note also that a reliable 230 provisional response is allowed without a session description if the 231 UAS does not wish to send the answer yet. An unreliable provisional 232 response may include a session description in the body if the UAS has 233 not sent a reliable response, but its session description is neither 234 an offer nor an answer. All the session descriptions in the 235 unreliable responses to the INVITE request must be identical to the 236 answer which is included in the reliable response. Session 237 descriptions in an unreliable response that precedes a reliable 238 response can be considered a "preview" of the session description 239 that will be coming, and hence may be treated like an offer or an 240 answer until the actual one arrives. 242 2.1.1. INVITE Request with SDP 244 When a UAC includes an SDP body in the INVITE request as an offer, it 245 expects the answer to be received with one of the reliable responses. 246 Other than that, no offer/answer exchanges can occur in the INVITE 3- 247 way handshake process. 249 UAC UAS 250 | F1 INVITE (SDP) | <- The offer in offer/answer model 251 |-------------------->| 252 | F2 1xx (SDP) | <- The SDP is not an official answer but 253 |<--------------------| UAC acts as if it receives the answer. 254 | | ^ 255 | F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer 256 |<--------------------| | SDP. 257 | F4 PRACK (no SDP) | | 258 |-------------------->| | UAC must not send a new offer. 259 | F5 2xx PRA (no SDP) | | 260 |<--------------------| v 261 | | 262 | F6 1xx-rel (SDP) | <- The answer in offer/ answer model 263 |<--------------------| - 264 | F7 PRACK | | UAC can send a new offer in a PRACK 265 |-------------------->| | request to acknowledge F6. 266 | F8 2xx PRA | | After F7 UAC and UAS can send a new offer 267 |<--------------------| v in an UPDATE request. 268 | | 269 | F9 1xx-rel | <- SDP should not be included in the 270 |<--------------------| subsequent 1xx-rel once offer/answer 271 | F10 PRACK | has been completed. 272 |-------------------->| 273 | F11 2xx PRA | 274 |<--------------------| 275 | | 276 | F12 2xx INV | <- SDP should not be included in the final 277 |<--------------------| response once offer/answer has been 278 | F13 ACK | completed. 279 |-------------------->| 281 Figure 1 Example of Offer/Answer with 100rel Extension (1) 283 For example, in Figure 1, only the SDP in F6 is the answer. The SDP 284 in the non-reliable response (F2) is the preview of the answer and 285 must be the same as the answer in F6, but is not officially the 286 answer. Receiving F2, UAC should act as if it receives the answer. 287 However, offer/answer exchange is not completed yet and UAC must not 288 send a new offer until it receives the same SDP in the first reliable 289 response, which is the real answer. After sending the SDP in F6, UAS 290 must prepare to receive new offer from UAC with an UPDATE request or 291 a PRACK request. 293 UAS does not include an SDP in the responses F9 and F12. However, UAC 294 should prepare to receive SDP bodies in F9 and/or F12, and just 295 ignore them for the case that the peer does not conform to the 296 recommended implementation. 298 2.1.2. INVITE request without SDP 300 When UAC does not include an SDP body in the INVITE request, it 301 expects the offer to be received with the first reliable response. 302 UAC will send the answer in the request to acknowledge the response, 303 i.e. PRACK or ACK request for the reliable response. Other than that, 304 no offer/answer exchanges can occur in the INVITE 3-way handshake 305 process. 307 For example, in Figure 2, only the SDP in F3 is the offer. The SDP in 308 the non-reliable response (F2) is the preview of the offer and must 309 be the same as the offer in F3, but is not officially the offer. 310 Receiving F2, UAC can act as if it receives the offer. However, the 311 official offer is not received until it receives the first reliable 312 response. The first reliable response (F3) must include an SDP as an 313 offer. 315 UAS should not include SDP in the responses F6 and F9. However, UAC 316 should prepare to receive SDP bodies in F6 and/or F9, and just ignore 317 them for the case that the peer does not conform to the recommended 318 implementation. 320 UAC UAS 321 | F1 INVITE (no SDP) | 322 |-------------------->| 323 | F2 1xx (SDP) | <- SDP may be included but it is not the 324 |<--------------------| offer. UAC may act as if it receives 325 | | the offer. 326 | F3 1xx-rel (SDP) | <- The first 1xx-rel must contain an SDP 327 |<--------------------| as the offer. 328 | F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel 329 |-------------------->| must contain an SDP as the answer. 330 | F5 2xx PRA (no SDP) | - 331 |<--------------------| | 332 | | | 333 | F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not 334 |<--------------------| | contain an SDP. 335 | F7 PRACK | | 336 |-------------------->| | UAC can send a new offer in an UPDATE 337 | F8 2xx PRA | | request after F4. 338 |<--------------------| v 339 | | 340 | F9 2xx INV (no SDP) | <- The final response should not 341 |<--------------------| contain an SDP. 342 | F10 ACK | 343 |-------------------->| 345 Figure 2 Example of Offer/Answer with 100rel Extension (2) 347 2.2. Offer/Answer Exchange in Early Dialog 349 When both UAs support the 100rel extension, they can update the 350 session in the early dialog once the first offer/answer exchange has 351 been completed. 353 From UA sending an INVITE request: 355 UA can send an UPDATE request with a new offer if both ends support 356 the UPDATE method. Support for the UPDATE method must be declared in 357 an Allow header in some prior messages in the dialog. 359 UA can send a PRACK request with a new offer only when acknowledging 360 the reliable provisional response with the answer to the offer in the 361 INVITE request. Compared to using the UPDATE method, using PRACK can 362 save messages to be exchanged between the UAs. However, as a PRACK 363 request should not be rejected, UA is recommended to send a PRACK 364 request only when it has strong reasons to assume the receiver will 365 accept it. For example, the procedure used in precondition extension 366 [5] is a case where a PRACK request should be used for updating the 367 session status in the early dialog. 369 From UA receiving an INVITE request: 371 UA can send an UPDATE request with a new offer if both ends support 372 UPDATE method. UAS can not send a new offer in the reliable 373 provisional response. So the UPDATE method is the only method for UAS 374 to update the early session. 376 2.3. Offer/Answer Exchange in Established Dialog 378 The re-INVITE and UPDATE methods can be used in the established 379 dialog to update the session. 381 The UPDATE method is simpler and can save at least one message 382 compared with INVITE method. But both ends must support the UPDATE 383 method for it to be used. 385 The INVITE method needs at least three messages to complete but no 386 extensions are needed. Additionally, the INVITE method allows the 387 peer to take time to decide whether it will accept a session update 388 or not by sending provisional responses. That is, re-INVITE allows 389 the UAS to interact with the user at the peer, while UPDATE needs to 390 be answered automatically by the UAS. It is noted that re-INVITE 391 should be answered immediately unless such a user interaction is 392 needed. Otherwise, some 3pcc flows will break. 394 3. Exceptional Case Handling 396 In RFC 3264 [3], the following restrictions are defined with regard 397 to sending a new offer. 399 "It MUST NOT generate a new offer if it has received an offer 400 which it has not yet answered or rejected. It MUST NOT generate a 401 new offer if it has generated a prior offer for which it has not 402 yet received an answer or a rejection." 404 Assuming that the above rules are guaranteed, there seems to be two 405 possible 'exceptional' cases to be considered in SIP offer/answer 406 usage, which are the 'message crossing' case and the 'glare' case. 407 One of the reasons why the usage of a SIP method to exchange 408 offer/answer needs to be carefully restricted in the RFCs is to make 409 sure that UA can detect and handle appropriately the 'exceptional' 410 cases to avoid the confusion. 412 3.1. Message Crossing Case Handling 414 When message packets are crossed in the transport network, an offer 415 may be received before the answer for the previous offer/answer 416 exchange as described in Figure 3. In such a case, UA A must detect 417 the session description of the offer2 is not the answer to the offer1. 419 A B 420 |offer1 | 421 |----------------->| 422 | answer1| 423 |<------\ /-------| 424 | \/ | 425 | /\ offer2| 426 |<------/ \-------| 428 Figure 3 Message Crossing Case 430 When offer2 is in an UPDATE request or a re-INVITE request, a session 431 description can never be the answer. Then UA A must reject the 432 message including offer2 with a 491 response with Retry-After header 433 field. 435 When offer2 is in a PRACK request, that is, when a PRACK request to 436 acknowledge the reliable provisional response with an answer to the 437 offer in the INVITE request contains a session description, UA A 438 knows it is an offer. As a PRACK request should not be rejected, UA A 439 is recommended to wait for the answer1 before sending a PRACK 440 response with the answer to the offer2. Note that if UA A does not 441 send a new offer until the reliable provisional response with an 442 answer to the offer in the INVITE request is acknowledged with a 443 PRACK request, this case never happens. Therefore, to make 444 implementations simple, a UA acting as a UAS for an INVITE 445 transaction is recommended not to send an UPDATE request with an 446 offer until the reliable response with an answer to the offer in the 447 INVITE request is acknowledged with a PRACK request. 449 When offer2 is in a reliable provisional response or a successful 450 final response, UA A knows it is not the answer to the offer1. For a 451 reliable response to an initial INVITE request, this case never 452 happens. For a reliable response to a re-INVITE request, UA A can 453 detect the offer2 is not the answer1. In this case, UA A can not 454 reject offer2 in a reliable response, it is recommended to wait for 455 answer1 before sending a PRACK request with the answer to offer2. 456 Note that if UA A does not send an INVITE request without session 457 description if it has sent the offer which has not yet received the 458 answer to it, this case never happens. 460 3.2. Glare Case Handling 462 When both ends in a dialog send a new offer at nearly the same time, 463 UA may receive a new offer before it receives the answer to the offer 464 it sent as described in Figure 4. This case is called a 'glare' case 465 in general. 467 A B 468 |offer1 offer2| 469 |-------\ /-------| 470 | \/ | 471 | /\ | 472 |<------/ \------>| 474 Figure 4 Glare Case 476 When offer2 is in an UPDATE request or (re-)INVITE request, it must 477 be rejected with a 491 response. 479 When offer2 is in a PRACK request, it may be accepted with 200 or may 480 be rejected with a 491 response. A 491 response may be adequate for 481 offer/answer model but it may delay the completion of the reliable 482 response transfer mechanism or, in worst case, may result in the 483 failure to complete the SIP transaction because there is no clear 484 retry rule when a PRACK request is rejected with a 491 response. To 485 avoid this glare condition, UA is recommended not to send an offer, 486 which currently must be in an UPDATE request, if it has generated the 487 reliable provisional response with the answer to the offer in the 488 INVITE request which is not acknowledged with a PRACK request. 490 To avoid glare condition for offer2 in the response, UA A is 491 recommended not to send a new offer if it has sent a (re)INVITE 492 request without session description and has not received the reliable 493 response which includes the offer. 495 4. Content of Offers and Answers 497 While RFCs 3264[3] and 3312[5] give some guidance, questions remain 498 about exactly what should be included in an offer or answer. This is 499 especially a problem when the common "hold" feature has been 500 activated, and when there is the potential for a multimedia call. 502 Details of behavior depend on the capabilities and state of the User 503 Agent. The kinds of recommendations that can be made are limited by 504 the model of device capabilities and state that is presumed to exist. 506 This section focuses on a few key aspects of offers and answers that 507 have been identified as troublesome, and will consider other aspects 508 to be out of scope. This section considers: 510 - choice of supported media types and formats to include and exclude 512 - hold and resume of media 514 The following are out of scope for this document: 516 - NAT traversal and ICE 518 - specific codecs and their parameters 520 - the negotiation of secure media streams 522 - grouping of media streams 524 - preconditions 526 4.1. General Principle for Constructing Offers and Answers 528 A UA should send an offer that indicates what it, and its user, are 529 interested in using/doing at that time, without regard for what the 530 other party in the call may have indicated previously. 532 A UA should send an answer that includes as close an approximation to 533 what the UA and its user are interested in doing at that time, while 534 remaining consistent with the offer/answer rules of RFC 3264[3] and 535 other RFCs. 537 NOTE: "at that time" is important. The device may permit the 538 user to configure which supported media are to be used by 539 default. 541 Some UAs may not have an understanding of what it is interested in 542 doing at a particular time. (E.g. a gateway to a different protocol.) 543 In this case the UA could delegate the decision to the other protocol, 544 if the situation can be represented. Or it can make some assumptions. 545 This may result in a limitation in what works through the gateway. 547 4.2. Choice of Media Types and Formats to Include and Exclude 549 4.2.1. Sending Initial INVITE with Offer 551 When a UAC sends an initial INVITE with an offer, it has complete 552 freedom to choose which media type(s) and media format(s) (payload 553 types in the case of RTP) it should include in the offer. 555 The media types may be all or a subset of the media the UAC is 556 capable of supporting, with the particular subset being determined by 557 the design and configuration [6] of the UAC combined with input from 558 the user interface of the UAC. 560 The media formats may be all or a subset of the media formats the UAC 561 is capable of supporting for the corresponding media type, with the 562 particular subset being determined by the design and configuration 563 [6] of the UAC combined with input from the user interface of the UAC. 565 Including all supported media formats will maximize the possibility 566 that the other party will have a supported format in common. But 567 including many can result in an unacceptably large SDP body. 569 4.2.2. Responding with Offer when Initial INVITE has no Offer 571 When a UAS has received an initial INVITE without an offer, it must 572 include an offer in the first reliable response to the INVITE. It has 573 largely the same options as when sending an initial INVITE with an 574 offer, but there are some differences. The choice may be governed by 575 both static (default) selections of media types as well as dynamic 576 selections made by a user via interaction with the device while it is 577 alerting. 579 NOTE: The offer may be sent in a provisional response, before 580 the user of the device has been alerted and had an opportunity 581 to select media options for the call. In this case the UAS 582 cannot include any call-specific options from the user of the 583 device. It there is a possibility that the user of the device 584 may wish to change what is offered before answering the call, 585 then special care should be taken. If PRACK and UPDATE are 586 supported by caller and callee then an initial offer can be sent 587 reliably, and changed with an UPDATE if the user desires a 588 change. If PRACK and UPDATE are not supported then the initial 589 offer cannot be changed until the call is fully established. In 590 that case either the offer should be delayed until the 200 is 591 sent, or else the offer should include the minimum set of media 592 the user is able to select. 594 4.2.3. Answering Initial INVITE with Offer 596 When a UAS receives an initial INVITE with an offer, what media lines 597 the answer may contain is constrained by RFC 3264.[3] The answer must 598 contain the same number of m-lines as the offer, and they must 599 contain the same media types. Each media line may be accepted, by 600 including a non-zero port number, or rejected by including a zero 601 port number in the answer. The media lines that are accepted should 602 typically be those that would have been offered had the INVITE not 603 contained an offer, but with those not offered removed. 605 The media formats the answer may contain is constrained by RFC 3264 606 [3]. For each accepted m-line in the answer, there must be at least 607 one media format in common with those in the request. The UAS may 608 also include other media formats it is able to support at this time. 609 However there is little benefit to including added types. 611 If the UAS does not wish to indicate support for any of the media 612 types in a particular media line of the offer it must reject the 613 corresponding media line, by setting the port number to zero. 615 4.2.4. Answering when Initial INVITE had no Offer 617 When a UAC has sent an initial INVITE without an offer, and then 618 receives a response with the first offer, it should answer in the 619 same way as a UAS receiving an initial INVITE with an offer. 621 4.2.5. Subsequent Offers and Answers 623 The guidelines above (sections 4.1. and 4.2.1. through 4.2.5.) apply, 624 but constraints in RFC 3264 [3] must also be followed. The following 625 are of particular note because they have proven troublesome: 627 o The number of m-lines may not be reduced in a subsequent offer. 628 Previously rejected media streams must remain, or be reused to 629 offer the same or a different stream. 631 o In the o-line, only the version number may change, and if it 632 changes it must increment by one from the one previously sent as 633 an offer or answer. If it doesn't change then the entire SDP body 634 must be identical to what was previously sent as an offer or 635 answer. 637 o In the case of RTP, the mapping from a particular dynamic payload 638 type number to a particular codec within that media stream (m- 639 line) MUST NOT change for the duration of the session. 641 NOTE: This may be impossible for a B2BUA to follow in some cases 642 (e.g. 3pcc transfer) if it does not terminate media. 644 4.3. Hold and Resume of media 646 RFC 3264 [3] specifies (non-normatively) that "hold" should be 647 indicated in an established session by sending a new offer containing 648 "a=sendonly" for each media stream to be held. An answerer is then to 649 respond with "a=recvonly" to acknowledge that the hold request has 650 been understood. 652 Note that the use of sendonly/recvonly is not limited to hold. These 653 may be used for other reasons, such as devices that are only capable 654 of sending or receiving. So receiving an offer with "a=sendonly" must 655 not be treated as a certain indication that the offerer has placed 656 the media stream on hold. 658 This model is based on an assumption that the UA initiating the hold 659 will want to play Music on Hold, which is not always the case. A UA 660 may, if desired, initiate hold by offering "a=inactive" if it does 661 not intend to transmit any media while in hold status. 663 The rules of RFC 3264 [3] constrain what may be in an answer when the 664 offer contains "sendonly", "recvonly", or "inactive" in an a= line. 665 But they do not constrain what must be in a subsequent offer. The 666 General Principle for Constructing Offers and Answers (section 4.1.) 667 is important here. The initiation of "hold" is a local action. It 668 should affect the desired state of the UA. It then affects what the 669 UA includes in offers and answers until the local state is reset. 671 The receipt of an offer containing "a=sendonly" or "a=inactive" and 672 the sending of a compatible answer should not change the desired 673 state of the recipient. However, a UA that has been "placed on hold" 674 may itself desire to initiate its own hold status, based on local 675 input. 677 If UA2 has previously been "placed on hold" by UA1, via receipt of 678 "a=sendonly", then it may initiate its own hold by sending a new 679 offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will 680 answer with "a=inactive" because that is the only valid answer that 681 reflects its desire not to receive media. 683 Once in this state, to resume a two way exchange of media each side 684 must reset its local hold status. If UA1 is first to go off hold it 685 will then send an offer with "a=sendrecv". The UA2 will respond with 686 its desired state of "a=sendonly" because that is a permitted 687 response. When UA2 desires to also resume, it will send an offer with 688 "a=sendrecv". In this case, because UA1 has the same desire it will 689 respond "a=sendrecv". 691 If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", 692 and subsequently wants to initiate its own hold, it need not send a 693 new offer, since the only offer it could make would be "a=inactive" 694 and that is already in effect in both directions. However, its local 695 desired state will now be either "sendonly" or "inactive" according 696 to how it desires to send Music on Hold. This affects what it will 697 send in future offers and answers. 699 5. Remaining Issues or Best Practices on Offer/Answer 701 This document clarifies the offer/answer usage in SIP and summarizes 702 the correct or recommended behaviors along with the existing RFCs. To 703 create any new normative behaviors beyond these RFCs is not the 704 intent of this document. 706 However, through the scrutiny of the offer/answer model in SIP, some 707 issues are found to be unresolved within the current set of RFCs. 708 Those remaining issues are described in this section mainly for 709 further study. 711 5.1. Rejecting PRACK Offer 713 As stated in section 1.2. and 2.2., it is recommended not to send an 714 offer in a PRACK request unless UAC has strong reasons to assume the 715 receiver will accept it. Even so, there may be the cases when the UAS 716 has to reject the offer for some reason. The current RFCs do not 717 provide the way to reject the offer and at the same time to 718 acknowledge the reliable response. 720 Several candidates were proposed to resolve this issue, such as 721 sending 2xx PRACK response without SDP to reject the offer. Some of 722 the candidates may also be adapted as a way to reject an unacceptable 723 offer in a response. Anyway, those candidates violate the current 724 rules and lose backward compatibility to some extent. It is beyond 725 the scope of this document and remains for further study. 727 5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 728 Transaction 730 When a re-INVITE transaction fails, the dialog remains with the 731 session bound to it. The issue here is what the session status is if 732 offer/answer exchange has been completed before the re-INVITE 733 transaction fails with the final failure response (Figure 5). One 734 option is to take those offer/answer exchanges not committed yet and 735 to make the session status rollback to the one before re-INVITE 736 transaction was initiated. Another option is to take those exchanges 737 committed and to keep the session status as it is even after re- 738 INVITE fails. There is no clear consensus on which one is the correct 739 behavior. 741 There are some cases where it is useful to exchange 742 offer(s)/answer(s) even before re-INVITE completes. The case of 743 adding a new media (like adding video to audio only session) which 744 requires permission from the peer through some user interaction is 745 one example. Precondition procedures can be another case which may 746 require several offer/answer exchanges in one re-INVITE transaction. 748 UAC UAS 749 | session established | 750 |<===================>| 751 | | 752 | F1 re-INVITE (SDP) | 753 |-------------------->| 754 | F2 1xx-rel (SDP) | 755 |<--------------------| 756 | F3 PRACK | <- PRACK request may include new offer and 757 |-------------------->| can complete the offer/answer with 758 | F4 2xx PRA | the answer in 2xx PRACK response. 759 |<--------------------| 760 | | <- UPDATE method can update the session 761 | | status before receiving the final 762 | F5 4xx/5xx/6xx INV | response to re-INVITE request (F1). 763 |<--------------------| 764 | F6 ACK | 765 |-------------------->| Issue: What is the correct session status 766 | | after re-INVITE transaction. 768 Figure 5 Commit/Rollback Issue with re-INVITE transaction 770 To make bad things worse, if a new offer from UAC and the final 771 response to re-INVITE are sent at nearly the same time, the UAS can 772 not know whether this new offer was sent before or after UAC received 773 the final failure response (Figure 6). Note that the ACK request to 774 the failure response is sent hop-by-hop basis, therefore even after 775 receiving the ACK request, UAS can not make sure that UPDATE request 776 was sent after the final response had been reached to the other end. 778 Sending a new UPDATE request from UAC to synchronize the status 779 anytime after the re-INVITE fails may be a good option. This solution, 780 however, requires that the UPDATE method be supported by both ends 781 and needs care to avoid flapping when each end tries to advertise 782 their different views of the session status. 784 To resolve this issue may be beyond the scope of this document and 785 require another normative document which is for further study. 787 UAC UAS 788 | session established | 789 |<===================>| 790 | | 791 | F1 re-INVITE (SDP) | 792 |-------------------->| 793 | F2 1xx-rel (SDP) | 794 |<--------------------| 795 | F3 PRACK | 796 |-------------------->| 797 | F4 2xx PRA | 798 |<--------------------| 799 | | 800 |UPDATE(SDP) 4xx INV | 801 |---------\ /--------| 802 | \/ | 803 | /\ | 804 |<--------/ \------->| 805 | | 807 Figure 6 Commit/Rollback Issue with Race Condition 809 6. Add New Offer/Answer Usage in SIP 811 It is not recommended to add new SIP methods for the offer/answer 812 exchange beyond the ways described in this document. However, it may 813 be requested to have new offer/answer exchange methods as SIP 814 extensions evolve. In this clause, what should be taken into 815 considerations is noted. 817 6.1. Explicit Usage 819 New method definitions should define offer/answer usage explicitly 820 without any ambiguity. 822 6.2. Rejection of an Offer 824 New method definitions should define how to reject an offer where 825 possible. 827 6.3. Backward Compatibility 829 New methods must keep backward compatibility. 831 6.4. Exceptional Case Handling 833 New methods should take care of how to handle exceptional cases, 834 message crossing case and glare case. 836 7. Security Considerations 838 There are not any security issues beyond the referenced RFCs. 840 8. References 842 8.1. Normative References 844 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 845 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 846 Session Initiation Protocol", RFC 3261, June 2002. 848 [2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 849 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 850 June 2002. 852 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 853 SDP", RFC 3264, June 2002. 855 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 856 Method", RFC 3311, September 2002. 858 [5] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 859 Resource Management and Session Initiation Protocol (SIP)", RFC 860 3312, October 2002. 862 8.2. Informative References 864 [6] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent 865 Profile Data Set for Media Policy", draft-ietf-sipping-media- 866 policy-dataset-04 (work in progress), May 2007. 868 Author's Addresses 870 Takuya Sawada 871 KDDI Corporation 872 3-10-10, Iidabashi, Chiyoda-ku, Tokyo, Japan 874 Email: tu-sawada@kddi.com 876 Paul H. Kyzivat 877 Cisco Systems, Inc. 878 1414 Massachusetts Avenue 879 Boxborough, MA 01719 880 USA 882 Email: pkyzivat@cisco.com 884 Full Copyright Statement 886 Copyright (C) The IETF Trust (2007). 888 This document is subject to the rights, licenses and restrictions 889 contained in BCP 78, and except as set forth therein, the authors 890 retain all their rights. 892 This document and the information contained herein are provided on an 893 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 894 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 895 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 896 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 897 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 900 Intellectual Property Statement 902 The IETF takes no position regarding the validity or scope of any 903 Intellectual Property Rights or other rights that might be claimed to 904 pertain to the implementation or use of the technology described in 905 this document or the extent to which any license under such rights 906 might or might not be available; nor does it represent that it has 907 made any independent effort to identify any such rights. Information 908 on the procedures with respect to rights in RFC documents can be 909 found in BCP 78 and BCP 79. 911 Copies of IPR disclosures made to the IETF Secretariat and any 912 assurances of licenses to be made available, or the result of an 913 attempt made to obtain a general license or permission for the use of 914 such proprietary rights by implementers or users of this 915 specification can be obtained from the IETF on-line IPR repository at 916 http://www.ietf.org/ipr. 918 The IETF invites any interested party to bring to its attention any 919 copyrights, patents or patent applications, or other proprietary 920 rights that may cover technology that may be required to implement 921 this standard. Please address the information to the IETF at 922 ietf-ipr@ietf.org. 924 Acknowledgment 926 Funding for the RFC Editor function is provided by the IETF 927 Administrative Support Activity (IASA).