idnits 2.17.1 draft-ietf-sipping-sip-offeranswer-02.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 901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 912. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 925. 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 281 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 404: '... "It MUST NOT generate a new ...' RFC 2119 keyword, line 405: '...ed or rejected. It MUST NOT generate a...' RFC 2119 keyword, line 643: '... 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 (July 9, 2007) is 6136 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: January 2008 P. Kyzivat 5 Cisco Systems, Inc. 6 July 9, 2007 8 SIP (Session Initiation Protocol) Usage of Offer/Answer Model 9 draft-ietf-sipping-sip-offeranswer-02.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 9, 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. RFC 3264 [3] defines the 90 offer/answer model, but does not specify which SIP message should 91 convey an offer or an answer. This should be defined in the SIP core 92 and 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 standards-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. When an initial 115 INVITE causes multiple dialogs due to forking, an offer/answer 116 exchange is carried out independently in each distinct dialog. 117 Pattern 2 and pattern 4 can occur only when the INVITE request does 118 not include an offer. 'The first reliable non-failure message' must 119 have an offer if there is no offer in the INVITE request. This means 120 that UA which receives the INVITE request without an offer must 121 include an offer in the first reliable response with 100rel extension. 122 If no reliable provisional response has been sent, the UAS must 123 include an offer when sending 2xx 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 The '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 The 'Est' column shows the ability to update the established session. 156 The 'Early' column indicates which patterns may be used to modify the 157 established session in an early dialog. There are two ways to 158 exchange a 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 unacceptable offer, it 168 should respond with a 488 response, preferably with Warning header 169 field indicating the reason of the rejection unless another response 170 code is more appropriate to reject it. (Pattern 1 and Pattern 3) 172 When a UA receives an UPDATE request with an offer which it can not 173 accept, it should respond with a 488 response preferably with Warning 174 header field indicating the reason of the rejection, unless another 175 response code is more appropriate to reject it. (Pattern 6) 177 When a UA receives a PRACK request with an offer which it can not 178 accept, it may respond with a 200 response with a syntactically 179 correct session description followed by an UPDATE request possibly to 180 rearrange the session parameters if both ends support UPDATE method. 182 A UA may simply give up continuing the dialog and send an error 183 response to the INVITE request. (Pattern 5) 185 When a UA receives a response with an offer which it can not accept, 186 a UA does not have a way to reject it explicitly. Therefore, a UA 187 should respond to the offer with the correct session description and 188 rearrange the session parameters by initiating a new offer/answer 189 exchange, or just terminate the session. (Pattern 2 and Pattern 4) 190 When initiating a new offer/answer, a UA should take care not to 191 cause a never-ending offer/answer loop. 193 Offer Rejection 194 ----------------------------------------------------- 195 1. INVITE Req. 488 INVITE Response 196 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 197 3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 198 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 199 5. PRACK Req. (*) 200 PRACK Resp. followed by new offer 200 6. UPDATE Req. 488 UPDATE Response 202 Table 2. Rejection against an Offer 204 (*) UA should only use PRACK to send an offer when it has strong 205 reasons to assume the receiver will accept. 207 1.3. Session Description which is not Offer nor Answer 209 As previously stated, a session description in a SIP message is not 210 necessarily an offer or an answer. For example, SIP can use a session 211 description to describe capabilities apart from offer/answer exchange. 212 Examples of this are 200 OK responses for OPTIONS and 488 responses 213 for INVITE. 215 2. Detailed Discussion on Offer/Answer Model for SIP 217 2.1. Offer/Answer for INVITE method with 100rel extension 219 The INVITE method provides the basic procedure for offer/answer 220 exchange in SIP. Without the 100rel option, the rules are simple as 221 described in RFC 3261 [1]. If an INVITE request includes a session 222 description, pattern 1 is applied and if an INVITE request does not 223 include a session description, pattern 2 is applied. 225 With 100rel, pattern 3 and pattern 4 are added and this makes the 226 rules complicated. An INVITE request may cause multiple responses. 227 Note that even if both UAs support the 100rel extension, not all the 228 provisional responses may be sent reliably. Note also that a reliable 229 provisional response is allowed without a session description if the 230 UAS does not wish to send the answer yet. An unreliable provisional 231 response may include a session description in the body if the UAS has 232 not sent a reliable response, but its session description is neither 233 an offer nor an answer. All the session descriptions in the 234 unreliable responses to the INVITE request must be identical to the 235 answer which is included in the reliable response. Session 236 descriptions in an unreliable response that precedes a reliable 237 response can be considered a "preview" of the session description 238 that will be coming, and hence may be treated like an offer or an 239 answer until the actual one arrives. 241 NOTE: This "preview" session description rule applies to a 242 single offer/answer exchange. In parallel offer/answer exchanges 243 (caused by forking) a UA may obviously receive the different 244 "preview" of answer in each dialog. UAs are expected to deal 245 with this. 247 2.1.1. INVITE Request with SDP 249 When a UAC includes an SDP body in the INVITE request as an offer, it 250 expects the answer to be received with one of the reliable responses. 251 Other than that, no offer/answer exchanges can occur in the INVITE 3- 252 way handshake process. 254 UAC UAS 255 | F1 INVITE (SDP) | <- The offer in offer/answer model 256 |-------------------->| 257 | F2 1xx (SDP) | <- The SDP is not an official answer but 258 |<--------------------| UAC acts as if it receives the answer. 259 | | ^ 260 | F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer 261 |<--------------------| | SDP. 262 | F4 PRACK (no SDP) | | 263 |-------------------->| | UAC must not send a new offer. 264 | F5 2xx PRA (no SDP) | | 265 |<--------------------| v 266 | | 267 | F6 1xx-rel (SDP) | <- The answer in offer/ answer model 268 |<--------------------| - 269 | F7 PRACK | | UAC can send a new offer in a PRACK 270 |-------------------->| | request to acknowledge F6. 271 | F8 2xx PRA | | After F7 UAC and UAS can send a new offer 272 |<--------------------| v in an UPDATE request. 273 | | 274 | F9 1xx-rel | <- SDP should not be included in the 275 |<--------------------| subsequent 1xx-rel once offer/answer 276 | F10 PRACK | has been completed. 277 |-------------------->| 278 | F11 2xx PRA | 279 |<--------------------| 280 | | 281 | F12 2xx INV | <- SDP should not be included in the final 282 |<--------------------| response once offer/answer has been 283 | F13 ACK | completed. 284 |-------------------->| 286 Figure 1 Example of Offer/Answer with 100rel Extension (1) 288 For example, in Figure 1, only the SDP in F6 is the answer. The SDP 289 in the non-reliable response (F2) is the preview of the answer and 290 must be the same as the answer in F6, but is not officially the 291 answer. Receiving F2, UAC should act as if it receives the answer. 292 However, offer/answer exchange is not completed yet and UAC must not 293 send a new offer until it receives the same SDP in the first reliable 294 response, which is the real answer. After sending the SDP in F6, UAS 295 must prepare to receive new offer from UAC with an UPDATE request or 296 a PRACK request. 298 UAS does not include an SDP in the responses F9 and F12. However, UAC 299 should prepare to receive SDP bodies in F9 and/or F12, and just 300 ignore them for the case that the peer does not conform to the 301 recommended implementation. 303 2.1.2. INVITE request without SDP 305 When UAC does not include an SDP body in the INVITE request, it 306 expects the offer to be received with the first reliable response. 307 UAC will send the answer in the request to acknowledge the response, 308 i.e. PRACK or ACK request for the reliable response. Other than that, 309 no offer/answer exchanges can occur in the INVITE 3-way handshake 310 process. 312 For example, in Figure 2, only the SDP in F3 is the offer. The SDP in 313 the non-reliable response (F2) is the preview of the offer and must 314 be the same as the offer in F3, but is not officially the offer. 315 Receiving F2, UAC can act as if it receives the offer. However, the 316 official offer is not received until it receives the first reliable 317 response. The first reliable response (F3) must include an SDP as an 318 offer. 320 UAS should not include SDP in the responses F6 and F9. However, UAC 321 should prepare to receive SDP bodies in F6 and/or F9, and just ignore 322 them for the case that the peer does not conform to the recommended 323 implementation. 325 UAC UAS 326 | F1 INVITE (no SDP) | 327 |-------------------->| 328 | F2 1xx (SDP) | <- SDP may be included but it is not the 329 |<--------------------| offer. UAC may act as if it receives 330 | | the offer. 331 | F3 1xx-rel (SDP) | <- The first 1xx-rel must contain an SDP 332 |<--------------------| as the offer. 333 | F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel 334 |-------------------->| must contain an SDP as the answer. 335 | F5 2xx PRA (no SDP) | - 336 |<--------------------| | 337 | | | 338 | F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not 339 |<--------------------| | contain an SDP. 340 | F7 PRACK | | 341 |-------------------->| | UAC can send a new offer in an UPDATE 342 | F8 2xx PRA | | request after F4. 343 |<--------------------| v 344 | | 345 | F9 2xx INV (no SDP) | <- The final response should not 346 |<--------------------| contain an SDP. 347 | F10 ACK | 348 |-------------------->| 350 Figure 2 Example of Offer/Answer with 100rel Extension (2) 352 2.2. Offer/Answer Exchange in Early Dialog 354 When both UAs support the 100rel extension, they can update the 355 session in the early dialog once the first offer/answer exchange has 356 been completed. 358 From UA sending an INVITE request: 360 UA can send an UPDATE request with a new offer if both ends support 361 the UPDATE method. Support for the UPDATE method must be declared in 362 an Allow header in some prior messages in the dialog. 364 UA can send a PRACK request with a new offer only when acknowledging 365 the reliable provisional response with the answer to the offer in the 366 INVITE request. Compared to using the UPDATE method, using PRACK can 367 save messages to be exchanged between the UAs. However, as a PRACK 368 request should not be rejected, UA is recommended to send a PRACK 369 request only when it has strong reasons to assume the receiver will 370 accept it. For example, the procedure used in precondition extension 371 [5] is a case where a PRACK request should be used for updating the 372 session status in the early dialog. 374 From UA receiving an INVITE request: 376 UA can send an UPDATE request with a new offer if both ends support 377 UPDATE method. UAS can not send a new offer in the reliable 378 provisional response. So the UPDATE method is the only method for UAS 379 to update the early session. 381 2.3. Offer/Answer Exchange in Established Dialog 383 The re-INVITE and UPDATE methods can be used in the established 384 dialog to update the session. 386 The UPDATE method is simpler and can save at least one message 387 compared with INVITE method. But both ends must support the UPDATE 388 method for it to be used. 390 The INVITE method needs at least three messages to complete but no 391 extensions are needed. Additionally, the INVITE method allows the 392 peer to take time to decide whether it will accept a session update 393 or not by sending provisional responses. That is, re-INVITE allows 394 the UAS to interact with the user at the peer, while UPDATE needs to 395 be answered automatically by the UAS. It is noted that re-INVITE 396 should be answered immediately unless such a user interaction is 397 needed. Otherwise, some 3pcc flows will break. 399 3. Exceptional Case Handling 401 In RFC 3264 [3], the following restrictions are defined with regard 402 to sending a new offer. 404 "It MUST NOT generate a new offer if it has received an offer 405 which it has not yet answered or rejected. It MUST NOT generate a 406 new offer if it has generated a prior offer for which it has not 407 yet received an answer or a rejection." 409 Assuming that the above rules are guaranteed, there seems to be two 410 possible 'exceptional' cases to be considered in SIP offer/answer 411 usage, which are the 'message crossing' case and the 'glare' case. 412 One of the reasons why the usage of a SIP method to exchange 413 offer/answer needs to be carefully restricted in the RFCs is to make 414 sure that UA can detect and handle appropriately the 'exceptional' 415 cases to avoid the confusion. 417 3.1. Message Crossing Case Handling 419 When message packets are crossed in the transport network, an offer 420 may be received before the answer for the previous offer/answer 421 exchange as described in Figure 3. In such a case, UA A must detect 422 the session description of the offer2 is not the answer to the offer1. 424 A B 425 |offer1 | 426 |----------------->| 427 | answer1| 428 |<------\ /-------| 429 | \/ | 430 | /\ offer2| 431 |<------/ \-------| 433 Figure 3 Message Crossing Case 435 When offer2 is in an UPDATE request or a re-INVITE request, a session 436 description can never be the answer. Then UA A must reject the 437 message including offer2 with a 491 response with Retry-After header 438 field. 440 When offer2 is in a PRACK request, that is, when a PRACK request to 441 acknowledge the reliable provisional response with an answer to the 442 offer in the INVITE request contains a session description, UA A 443 knows it is an offer. As a PRACK request should not be rejected, UA A 444 is recommended to wait for the answer1 before sending a PRACK 445 response with the answer to the offer2. Note that if UA A does not 446 send a new offer until the reliable provisional response with an 447 answer to the offer in the INVITE request is acknowledged with a 448 PRACK request, this case never happens. Therefore, to make 449 implementations simple, a UA acting as a UAS for an INVITE 450 transaction is recommended not to send an UPDATE request with an 451 offer until the reliable response with an answer to the offer in the 452 INVITE request is acknowledged with a PRACK request. 454 When offer2 is in a reliable provisional response or a successful 455 final response, UA A knows it is not the answer to the offer1. For a 456 reliable response to an initial INVITE request, this case never 457 happens. For a reliable response to a re-INVITE request, UA A can 458 detect the offer2 is not the answer1. In this case, UA A can not 459 reject offer2 in a reliable response, it is recommended to wait for 460 answer1 before sending a PRACK request with the answer to offer2. 461 Note that this case only occurs when UA A, while waiting for an 462 answer, sends an INVITE request without session description. 464 3.2. Glare Case Handling 466 When both ends in a dialog send a new offer at nearly the same time, 467 UA may receive a new offer before it receives the answer to the offer 468 it sent as described in Figure 4. This case is called a 'glare' case 469 in general. 471 A B 472 |offer1 offer2| 473 |-------\ /-------| 474 | \/ | 475 | /\ | 476 |<------/ \------>| 478 Figure 4 Glare Case 480 When offer2 is in an UPDATE request or (re-)INVITE request, it must 481 be rejected with a 491 response. 483 When offer2 is in a PRACK request (within the current rules, only 484 possible if offer1 is in an UPDATE request), the PRACK may be 485 accepted with 200 or may be rejected with a 491 response. A 491 486 response is valid to satisfy the offer/answer model but it may delay 487 the completion of the reliable response transfer mechanism or, in 488 worst case, may result in the failure to complete the SIP transaction 489 because there is no clear retry rule when a PRACK request is rejected 490 with a 491 response. To avoid this glare condition, UA A should not 491 send an offer if it has already sent a reliable provisional response 492 containing an answer to a previous offer and has not received the 493 corresponding PRACK request. 495 To avoid a glare condition involving an offer in a response, when UA 496 A has sent a (re)INVITE request without session description, it 497 should not send an offer until it has received an offer in a reliable 498 response to the (re)INVITE, and sent an answer to that offer. 500 4. Content of Offers and Answers 502 While RFCs 3264[3] and 3312[5] give some guidance, questions remain 503 about exactly what should be included in an offer or answer. This is 504 especially a problem when the common "hold" feature has been 505 activated, and when there is the potential for a multimedia call. 507 Details of behavior depend on the capabilities and state of the User 508 Agent. The kinds of recommendations that can be made are limited by 509 the model of device capabilities and state that is presumed to exist. 511 This section focuses on a few key aspects of offers and answers that 512 have been identified as troublesome, and will consider other aspects 513 to be out of scope. This section considers: 515 - choice of supported media types and formats to include and exclude 517 - hold and resume of media 519 The following are out of scope for this document: 521 - NAT traversal and ICE 523 - specific codecs and their parameters 525 - the negotiation of secure media streams 527 - grouping of media streams 529 - preconditions 531 4.1. General Principle for Constructing Offers and Answers 533 A UA should send an offer that indicates what it, and its user, are 534 interested in using/doing at that time, without regard for what the 535 other party in the call may have indicated previously. 537 A UA should send an answer that includes as close an approximation to 538 what the UA and its user are interested in doing at that time, while 539 remaining consistent with the offer/answer rules of RFC 3264[3] and 540 other RFCs. 542 NOTE: "at that time" is important. The device may permit the 543 user to configure which supported media are to be used by 544 default. 546 In some cases a UA may not have direct knowledge of what it is 547 interested in doing at a particular time. If it is an intermediary it 548 may be able to delegate the decision. In the worst case it may apply 549 a default, such as assuming it wants to use all of its capabilities. 551 4.2. Choice of Media Types and Formats to Include and Exclude 553 4.2.1. Sending Initial INVITE with Offer 555 When a UAC sends an initial INVITE with an offer, it has complete 556 freedom to choose which media type(s) and media format(s) (payload 557 types in the case of RTP) it should include in the offer. 559 The media types may be all or a subset of the media the UAC is 560 capable of supporting, with the particular subset being determined by 561 the design and configuration [6] of the UAC combined with input from 562 the user interface of the UAC. 564 The media formats may be all or a subset of the media formats the UAC 565 is capable of supporting for the corresponding media type, with the 566 particular subset being determined by the design and configuration 567 [6] of the UAC combined with input from the user interface of the UAC. 569 Including all supported media formats will maximize the possibility 570 that the other party will have a supported format in common. But 571 including many can result in an unacceptably large SDP body. 573 4.2.2. Responding with Offer when Initial INVITE has no Offer 575 When a UAS has received an initial INVITE without an offer, it must 576 include an offer in the first reliable response to the INVITE. It has 577 largely the same options as when sending an initial INVITE with an 578 offer, but there are some differences. The choice may be governed by 579 both static (default) selections of media types as well as dynamic 580 selections made by a user via interaction with the device while it is 581 alerting. 583 NOTE: The offer may be sent in a provisional response, before 584 the user of the device has been alerted and had an opportunity 585 to select media options for the call. In this case the UAS 586 cannot include any call-specific options from the user of the 587 device. If there is a possibility that the user of the device 588 will wish to change what is offered before answering the call, 589 then special care should be taken. If PRACK and UPDATE are 590 supported by caller and callee then an initial offer can be sent 591 reliably, and changed with an UPDATE if the user desires a 592 change. If PRACK and UPDATE are not supported then the initial 593 offer cannot be changed until the call is fully established. In 594 that case either the offer should be delayed until the 200 is 595 sent, or else the offer should include the minimum set of media 596 the user is able to select. 598 4.2.3. Answering Initial INVITE with Offer 600 When a UAS receives an initial INVITE with an offer, what media lines 601 the answer may contain is constrained by RFC 3264.[3] The answer must 602 contain the same number of m-lines as the offer, and they must 603 contain the same media types. Each media line may be accepted, by 604 including a non-zero port number, or rejected by including a zero 605 port number in the answer. The media lines that are accepted should 606 typically be those that would have been offered had the INVITE not 607 contained an offer, but with those not offered removed. 609 The media formats the answer may contain are constrained by RFC 3264 610 [3]. For each accepted m-line in the answer, there must be at least 611 one media format in common with the corresponding m-line of the offer. 612 The UAS may also include other media formats it is able to support at 613 this time. However there is little benefit to including added types. 615 If the UAS does not wish to indicate support for any of the media 616 types in a particular media line of the offer it must reject the 617 corresponding media line, by setting the port number to zero. 619 4.2.4. Answering when Initial INVITE had no Offer 621 When a UAC has sent an initial INVITE without an offer, and then 622 receives a response with the first offer, it should answer in the 623 same way as a UAS receiving an initial INVITE with an offer. 625 4.2.5. Subsequent Offers and Answers 627 The guidelines above (sections 4.1. and 4.2.1. through 4.2.5. ) apply, 628 but constraints in RFC 3264 [3] must also be followed. The following 629 are of particular note because they have proven troublesome: 631 o The number of m-lines may not be reduced in a subsequent offer. 632 Previously rejected media streams must remain, or be reused to 633 offer the same or a different stream. 635 o In the o-line, only the version number may change, and if it 636 changes it must increment by one from the one previously sent as 637 an offer or answer. If it doesn't change then the entire SDP body 638 must be identical to what was previously sent as an offer or 639 answer. 641 o In the case of RTP, the mapping from a particular dynamic payload 642 type number to a particular codec within that media stream (m- 643 line) MUST NOT change for the duration of the session. 645 NOTE: This may be impossible for a B2BUA to follow in some cases 646 (e.g. 3pcc transfer) if it does not terminate media. 648 4.3. Hold and Resume of media 650 RFC 3264 [3] specifies (non-normatively) that "hold" should be 651 indicated in an established session by sending a new offer containing 652 "a=sendonly" for each media stream to be held. An answerer is then to 653 respond with "a=recvonly" to acknowledge that the hold request has 654 been understood. 656 Note that the use of sendonly/recvonly is not limited to hold. These 657 may be used for other reasons, such as devices that are only capable 658 of sending or receiving. So receiving an offer with "a=sendonly" must 659 not be treated as a certain indication that the offerer has placed 660 the media stream on hold. 662 This model is based on an assumption that the UA initiating the hold 663 will want to play Music on Hold, which is not always the case. A UA 664 may, if desired, initiate hold by offering "a=inactive" if it does 665 not intend to transmit any media while in hold status. 667 The rules of RFC 3264 [3] constrain what may be in an answer when the 668 offer contains "sendonly", "recvonly", or "inactive" in an a= line. 669 But they do not constrain what must be in a subsequent offer. The 670 General Principle for Constructing Offers and Answers (section 4.1. ) 671 is important here. The initiation of "hold" is a local action. It 672 should affect the desired state of the UA. It then affects what the 673 UA includes in offers and answers until the local state is reset. 675 The receipt of an offer containing "a=sendonly" or "a=inactive" and 676 the sending of a compatible answer should not change the desired 677 state of the recipient. However, a UA that has been "placed on hold" 678 may itself desire to initiate its own hold status, based on local 679 input. 681 If UA2 has previously been "placed on hold" by UA1, via receipt of 682 "a=sendonly", then it may initiate its own hold by sending a new 683 offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will 684 answer with "a=inactive" because that is the only valid answer that 685 reflects its desire not to receive media. 687 Once in this state, to resume a two way exchange of media each side 688 must reset its local hold status. If UA1 is first to go off hold it 689 will then send an offer with "a=sendrecv". The UA2 will respond with 690 its desired state of "a=sendonly" because that is a permitted 691 response. When UA2 desires to also resume, it will send an offer with 692 "a=sendrecv". In this case, because UA1 has the same desire it will 693 respond "a=sendrecv". 695 If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", 696 and subsequently wants to initiate its own hold, also using 697 "a=inactive", it need not send a new offer, since the only valid 698 response is "a=inactive" and that is already in effect. However, its 699 local desired state will now be either "inactive". This affects what 700 it will send in future offers and answers. 702 5. Remaining Issues or Best Practices on Offer/Answer 704 This document clarifies the offer/answer usage in SIP and summarizes 705 the correct or recommended behaviors along with the existing RFCs. To 706 create any new normative behaviors beyond these RFCs is not the 707 intent of this document. 709 However, through the scrutiny of the offer/answer model in SIP, some 710 issues are found to be unresolved within the current set of RFCs. 711 Those remaining issues are described in this section mainly for 712 further study. 714 5.1. Rejecting PRACK Offer 716 As stated in section 1.2. and 2.2. , it is recommended not to send an 717 offer in a PRACK request unless UAC has strong reasons to assume the 718 receiver will accept it. Even so, there may be the cases when the UAS 719 has to reject the offer for some reason. The current RFCs do not 720 provide the way to reject the offer and at the same time to 721 acknowledge the reliable response. 723 Several candidates were proposed to resolve this issue, such as 724 sending 2xx PRACK response without SDP to reject the offer. Some of 725 the candidates may also be adapted as a way to reject an unacceptable 726 offer in a response. Anyway, those candidates violate the current 727 rules and lose backward compatibility to some extent. It is beyond 728 the scope of this document and remains for further study. 730 5.2. Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE 731 Transaction 733 When a re-INVITE transaction fails, often the dialog remains with the 734 session bound to it. The issue here is what the session status is if 735 offer/answer exchange has been completed before the re-INVITE 736 transaction fails with the final failure response (Figure 5). One 737 option is to take those offer/answer exchanges not committed yet and 738 to make the session status rollback to the one before re-INVITE 739 transaction was initiated. Another option is to take those exchanges 740 committed and to keep the session status as it is even after re- 741 INVITE fails. There is no clear consensus on which one is the correct 742 behavior. 744 There are some cases where it is useful to exchange 745 offer(s)/answer(s) even before re-INVITE completes. The case of 746 adding a new media (like adding video to audio only session) which 747 requires permission from the peer through some user interaction is 748 one example. Precondition procedures can be another case which may 749 require several offer/answer exchanges in one re-INVITE transaction. 751 UAC UAS 752 | session established | 753 |<===================>| 754 | | 755 | F1 re-INVITE (SDP) | 756 |-------------------->| 757 | F2 1xx-rel (SDP) | 758 |<--------------------| 759 | F3 PRACK | <- PRACK request may include new offer and 760 |-------------------->| can complete the offer/answer with 761 | F4 2xx PRA | the answer in 2xx PRACK response. 762 |<--------------------| 763 | | <- UPDATE method can update the session 764 | | status before receiving the final 765 | F5 4xx/5xx/6xx INV | response to re-INVITE request (F1). 766 |<--------------------| 767 | F6 ACK | 768 |-------------------->| Issue: What is the correct session status 769 | | after re-INVITE transaction. 771 Figure 5 Commit/Rollback Issue with re-INVITE transaction 773 To make bad things worse, if a new offer from UAC and the final 774 response to re-INVITE are sent at nearly the same time, the UAS can 775 not know whether this new offer was sent before or after UAC received 776 the final failure response (Figure 6). Note that the ACK request to 777 the failure response is sent hop-by-hop basis, therefore even after 778 receiving the ACK request, UAS can not make sure that UPDATE request 779 was sent after the final response had been reached to the other end. 781 Sending a new UPDATE request from UAC to synchronize the status 782 anytime after the re-INVITE fails may be a good option. This solution, 783 however, requires that the UPDATE method be supported by both ends 784 and needs care to avoid flapping when each end tries to advertise 785 their different views of the session status. 787 To resolve this issue may be beyond the scope of this document and 788 require another normative document which is for further study. 790 UAC UAS 791 | session established | 792 |<===================>| 793 | | 794 | F1 re-INVITE (SDP) | 795 |-------------------->| 796 | F2 1xx-rel (SDP) | 797 |<--------------------| 798 | F3 PRACK | 799 |-------------------->| 800 | F4 2xx PRA | 801 |<--------------------| 802 | | 803 |UPDATE(SDP) 4xx INV | 804 |---------\ /--------| 805 | \/ | 806 | /\ | 807 |<--------/ \------->| 808 | | 810 Figure 6 Commit/Rollback Issue with Race Condition 812 6. Add New Offer/Answer Usage in SIP 814 It is not recommended to add new SIP methods for the offer/answer 815 exchange beyond the ways described in this document. However, it may 816 be requested to have new offer/answer exchange methods as SIP 817 extensions evolve. In this clause, what should be taken into 818 considerations is noted. 820 6.1. Explicit Usage 822 New method definitions should define offer/answer usage explicitly 823 without any ambiguity. 825 6.2. Rejection of an Offer 827 New method definitions should define how to reject an offer where 828 possible. 830 6.3. Backward Compatibility 832 New methods must keep backward compatibility. 834 6.4. Exceptional Case Handling 836 New methods should take care of how to handle exceptional cases, 837 message crossing case and glare case. 839 7. Security Considerations 841 There are not any security issues beyond the referenced RFCs. 843 8. References 845 8.1. Normative References 847 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 848 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 849 Session Initiation Protocol", RFC 3261, June 2002. 851 [2] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 852 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 853 June 2002. 855 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 856 SDP", RFC 3264, June 2002. 858 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 859 Method", RFC 3311, September 2002. 861 [5] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 862 Resource Management and Session Initiation Protocol (SIP)", RFC 863 3312, October 2002. 865 8.2. Informative References 867 [6] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent 868 Profile Data Set for Media Policy", draft-ietf-sipping-media- 869 policy-dataset-04 (work in progress), May 2007. 871 Author's Addresses 873 Takuya Sawada 874 KDDI Corporation 875 3-10-10, Iidabashi, Chiyoda-ku, Tokyo, Japan 877 Email: tu-sawada@kddi.com 879 Paul H. Kyzivat 880 Cisco Systems, Inc. 881 1414 Massachusetts Avenue 882 Boxborough, MA 01719 883 USA 885 Email: pkyzivat@cisco.com 887 Full Copyright Statement 889 Copyright (C) The IETF Trust (2007). 891 This document is subject to the rights, licenses and restrictions 892 contained in BCP 78, and except as set forth therein, the authors 893 retain all their rights. 895 This document and the information contained herein are provided on an 896 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 897 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 898 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 899 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 900 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 901 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 903 Intellectual Property Statement 905 The IETF takes no position regarding the validity or scope of any 906 Intellectual Property Rights or other rights that might be claimed to 907 pertain to the implementation or use of the technology described in 908 this document or the extent to which any license under such rights 909 might or might not be available; nor does it represent that it has 910 made any independent effort to identify any such rights. Information 911 on the procedures with respect to rights in RFC documents can be 912 found in BCP 78 and BCP 79. 914 Copies of IPR disclosures made to the IETF Secretariat and any 915 assurances of licenses to be made available, or the result of an 916 attempt made to obtain a general license or permission for the use of 917 such proprietary rights by implementers or users of this 918 specification can be obtained from the IETF on-line IPR repository at 919 http://www.ietf.org/ipr. 921 The IETF invites any interested party to bring to its attention any 922 copyrights, patents or patent applications, or other proprietary 923 rights that may cover technology that may be required to implement 924 this standard. Please address the information to the IETF at 925 ietf-ipr@ietf.org. 927 Acknowledgment 929 Funding for the RFC Editor function is provided by the IETF 930 Administrative Support Activity (IASA).