idnits 2.17.1 draft-ietf-sipping-sip-offeranswer-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 254: '... response, it MUST be responded to ...' RFC 2119 keyword, line 271: '... "The UAS MUST ensure that the se...' RFC 2119 keyword, line 558: '...me, either agent MAY generate a new of...' RFC 2119 keyword, line 559: '...on. However, it MUST NOT generate a n...' RFC 2119 keyword, line 561: '... MUST NOT generate a new offer if...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (June 6, 2011) is 4698 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sipping S. Okumura 3 Internet-Draft Softfront 4 Intended status: Informational T. Sawada 5 Expires: December 8, 2011 KDDI Corporation 6 P. Kyzivat 7 Cisco Systems, Inc. 8 June 6, 2011 10 SIP (Session Initiation Protocol) Usage of the Offer/Answer Model 11 draft-ietf-sipping-sip-offeranswer-18 13 Abstract 15 The Session Initiation Protocol (SIP) utilizes the offer/answer model 16 to establish and update multimedia sessions using the Session 17 Description Protocol (SDP). The description of the offer/answer 18 model in SIP is dispersed across multiple RFCs. This document 19 summarizes all the current usages of the offer/answer model in SIP 20 communication. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 8, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Summary of SIP usage of the Offer/Answer Model . . . . . . . . 3 58 2.1. Offer/Answer Exchange Pairs in SIP Messages . . . . . . . 3 59 2.2. Rejection of an Offer . . . . . . . . . . . . . . . . . . 5 60 2.3. Session Description which is not Offer nor Answer . . . . 7 61 3. Detailed Discussion of the Offer/Answer Model for SIP . . . . 7 62 3.1. Offer/Answer for the INVITE method with 100rel 63 extension . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.1.1. INVITE Request with SDP . . . . . . . . . . . . . . . 7 65 3.1.2. INVITE request without SDP . . . . . . . . . . . . . . 10 66 3.2. Offer/Answer Exchange in Early Dialog . . . . . . . . . . 11 67 3.3. Offer/Answer Exchange in an Established Dialog . . . . . . 12 68 3.4. Recovering From a Failed ReINVITE . . . . . . . . . . . . 12 69 4. Exceptional Case Handling . . . . . . . . . . . . . . . . . . 13 70 4.1. Message Crossing Case Handling . . . . . . . . . . . . . . 13 71 4.2. Glare Case Handling . . . . . . . . . . . . . . . . . . . 18 72 4.3. Interworking of UPDATE and re-INVITE . . . . . . . . . . . 21 73 5. Content of Offers and Answers . . . . . . . . . . . . . . . . 25 74 5.1. General Principle for Constructing Offers and Answers . . 25 75 5.2. Choice of Media Types and Formats to Include and 76 Exclude . . . . . . . . . . . . . . . . . . . . . . . . . 26 77 5.2.1. Sending an Initial INVITE with Offer . . . . . . . . . 26 78 5.2.2. Responding with an Offer when the Initial INVITE 79 has no Offer . . . . . . . . . . . . . . . . . . . . . 26 80 5.2.3. Answering an Initial INVITE with Offer . . . . . . . . 27 81 5.2.4. Answering when the Initial INVITE had no Offer . . . . 27 82 5.2.5. Subsequent Offers and Answers . . . . . . . . . . . . 28 83 5.3. Hold and Resume of media . . . . . . . . . . . . . . . . . 28 84 5.4. Behavior on receiving SDP with c=0.0.0.0 . . . . . . . . . 30 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 87 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 31 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 93 1. Introduction 95 SIP utilizes the offer/answer model to establish and update sessions. 96 The rules to govern the offer/answer behaviors in SIP are described 97 in the several RFCs. ([RFC3261], [RFC3262], [RFC3264], [RFC3311], 98 and [RFC6141].) 100 The primary purpose of this document is to describe all forms of SIP 101 usage of the offer/answer model in one document to help the readers 102 to fully understand it. Also, this document tries to incorporate the 103 results of the discussions on the controversial issues to avoid 104 repeating the same discussions later. 106 This document describes ambiguities in the current specifications and 107 the authors' understanding of the correct interpretation of these 108 specifications. This document is not intended to make any changes to 109 those specifications, but rather is intended to provide a reference 110 for future standards development work on the SIP offer/answer model, 111 and to developers looking for advice on how to implement in 112 compliance with the standards. 114 2. Summary of SIP usage of the Offer/Answer Model 116 The offer/answer model itself is independent from the higher layer 117 application protocols which utilize it. SIP is one of the 118 applications using the offer/answer model. [RFC3264] defines the 119 offer/answer model, but does not specify which SIP messages should 120 convey an offer or an answer. This should be defined in the SIP core 121 and extensions RFCs. 123 In theory, any SIP message can include a session description in its 124 body. But a session description in a SIP message is not necessarily 125 an offer or an answer. Only certain session description usages that 126 conform to the rules described in standards-track RFCs can be 127 interpreted as an offer or an answer. The rules for how to handle 128 the offer/answer model are defined in several RFCs. 130 The offer/answer model defines a mechanism for update of sessions. 131 In SIP, a dialog is used to associate an offer/answer exchange with 132 the session which it is to update. In other words, only the offer/ 133 answer exchange in the SIP dialog can update the session which is 134 managed by that dialog. 136 2.1. Offer/Answer Exchange Pairs in SIP Messages 138 Currently, the rules on the offer/answer model are defined in 139 [RFC3261], [RFC3262], [RFC3264], [RFC3311] and [RFC6141]. In these 140 RFCs, only the six patterns shown in Table 1 are defined for 141 exchanging an offer and an answer with SIP messages. 143 Note that an offer/answer exchange initiated by an INVITE request 144 must follow exactly one of the patterns 1, 2, 3, 4. When an initial 145 INVITE causes multiple dialogs due to forking, an offer/answer 146 exchange is carried out independently in each distinct dialog. When 147 an INVITE request contains no offer, only Pattern 2 or Pattern 4 148 apply. 'The first reliable non-failure message' must have an offer 149 if there is no offer in the INVITE request. This means that UA which 150 receives the INVITE request without an offer must include an offer in 151 the first reliable response with 100rel extension. If no reliable 152 provisional response has been sent, the UAS must include an offer 153 when sending 2xx response. 155 In Pattern 3, the first reliable provisional response may or may not 156 have an answer. When a reliable provisional response contains a 157 session description, and is the first to do so, then that session 158 description is the answer to the offer in the INVITE request. The 159 answer can not be updated, and a new offer can not be sent in a 160 subsequent reliable response for the same INVITE transaction. 162 In Pattern 5, a PRACK request can contain an offer only if the 163 reliable response which it acknowledges contains an answer to the 164 previous offer/answer exchange. 166 NOTE: It is legal to have UPDATE/2xx exchanges without offer/ 167 answer exchanges (Pattern 6). However when re-INVITEs are sent 168 for non-offer/answer purposes, an offer/answer exchange is 169 required. In that case the prior SDP will typically be repeated. 171 There may be ONLY ONE offer/answer negotiation in progress for a 172 single dialog at any point in time. Section 4 explains how to ensure 173 this. When an INVITE results in multiple dialogs each has a separate 174 offer/answer negotiation. 176 NOTE: This is when using a Content-Disposition of "session". 177 There may be a second offer/answer negotiation in progress using a 178 Content-Disposition of "early-session" [RFC3959]. That is not 179 addressed by this draft. 181 Offer Answer RFC Ini Est Early 182 ------------------------------------------------------------------- 183 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 184 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 185 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 186 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 187 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 188 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y 190 Table 1: Summary of SIP Usage of the Offer/Answer Model 192 In Table 1, '1xx-rel' corresponds to the reliable provisional 193 response which contains the 100rel option defined in [RFC3262]. 195 The 'Ini' column shows the ability to exchange the offer/answer to 196 initiate the session. 'Y' indicates that the pattern can be used in 197 the initial offer/answer exchange, while 'N' indicates that it can 198 not. Only the initial INVITE transaction can be used to exchange the 199 offer/answer to establish a multimedia session. 201 The 'Est' column shows the ability to update the established session. 203 The 'Early' column indicates which patterns may be used to modify the 204 established session in an early dialog. There are two ways to 205 exchange a subsequent offer/answer in an early dialog. 207 2.2. Rejection of an Offer 209 It is not always clear how to reject an offer when it is 210 unacceptable, and some methods do not allow explicit rejection of an 211 offer. For each of the patterns in Table 1, Table 2 shows how to 212 reject an offer. 214 When a UA receives an INVITE request with an unacceptable offer, it 215 should respond with a 488 response, preferably with Warning header 216 field indicating the reason of the rejection, unless another response 217 code is more appropriate to reject it. (Pattern 1 and Pattern 3.) 219 If this is a re-INVITE extra care must be taken, as detailed in 220 [RFC6141]. Specifically, if the offer contains any changes or 221 additions to media stream properties, and those have already been 222 used to transmit/receive media before the final response is sent, 223 then a 2xx response should be sent, with a syntactically correct 224 session description. This may optionally be followed by an UPDATE 225 request to rearrange the session parameters if both ends support the 226 UPDATE method. Alternatively the UA may send an error response to 227 the (re)INVITE request to terminate the dialog or to roll back the 228 offer-answer status before sending re-INVITE request. In this case 229 UAS should not continue to retransmit the unacknowledged reliable 230 provisional response, UAC should not continue to retransmit a PRACK 231 request. 233 When a UA receives an UPDATE request with an offer which it can not 234 accept, it should respond with a 488 response preferably with Warning 235 header field indicating the reason of the rejection, unless another 236 response code is more appropriate to reject it. (Pattern 6) 238 When a UA receives a PRACK request with an offer which it can not 239 accept, it may respond with a 200 response with a syntactically 240 correct session description. This may optionally be followed by an 241 UPDATE request to rearrange the session parameters if both ends 242 support the UPDATE method. Alternatively the UA may terminate the 243 dialog and send an error response to the INVITE request. (Pattern 5) 245 In addition, there is a possibility for UAC to receive a 488 response 246 for an PRACK request. In that case, UAC may send again a PRACK 247 request without an offer or send a CANCEL request to terminate the 248 INVITE transaction. 250 NOTE: In [RFC3262], the following restriction is defined with 251 regard to responding to a PRACK request. 253 "If the PRACK does match an unacknowledged reliable provisional 254 response, it MUST be responded to with a 2xx response." 256 This restriction is not clear. There are cases where it is 257 unacceptable to send a 2xx response. For example, the UAS may 258 need to send an authentication challenge in a 401 response. This 259 is an open issue and out of scope for this document. 261 When a UA receives a response with an offer which it can not accept, 262 the UA does not have a way to reject it explicitly. Therefore, a UA 263 should respond to the offer with the correct session description and 264 rearrange the session parameters by initiating a new offer/answer 265 exchange, or alternatively terminate the session. (Pattern 2 and 266 Pattern 4) When initiating a new offer/answer, a UA should take care 267 not to cause an infinite offer/answer loop. 269 In [RFC3262] section 14.2 UAS Behavior, 271 "The UAS MUST ensure that the session description overlaps with 272 its previous session description in media formats, transports, or 273 other parameters that require support from the peer. This is to 274 avoid the need for the peer to reject the session description." 275 This is a rule for an offer within 2xx response to a re-INVITE. This 276 rule should be applied to an offer within a reliable provisional 277 response and a PRACK request. 279 Offer Rejection 280 ------------------------------------------------------------------ 281 1. INVITE Req. (*) 488 INVITE Response 282 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 283 OR termination of dialog 284 3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 285 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 286 5. PRACK Req. (**) 200 PRACK Resp. followed by new offer 287 OR termination of dialog 288 6. UPDATE Req. 488 UPDATE Response 290 (*) If this was a re-INVITE, a failure response should not be sent if 291 media has already been exchanged using the new offer. 293 (**) A UA should only use PRACK to send an offer when it has strong 294 reasons to expect the receiver will accept the offer. 296 Table 2: Rejection of an Offer 298 2.3. Session Description which is not Offer nor Answer 300 As previously stated, a session description in a SIP message is not 301 necessarily an offer or an answer. For example, SIP can use a 302 session description to describe capabilities apart from offer/answer 303 exchange. Examples of this are a 200 OK response for OPTIONS and a 304 488 response for INVITE. 306 3. Detailed Discussion of the Offer/Answer Model for SIP 308 3.1. Offer/Answer for the INVITE method with 100rel extension 310 The INVITE method provides the basic procedure for offer/answer 311 exchange in SIP. Without the 100rel option, the rules are simple as 312 described in [RFC3261]. If an INVITE request includes a session 313 description, Pattern 1 is applied and if an INVITE request does not 314 include a session description, Pattern 2 is applied. 316 With 100rel, Pattern 3, 4 and 5 are added and this complicates the 317 rules. An INVITE request may cause multiple responses. Note that 318 even if both UAs support the 100rel extension, not all the 319 provisional responses may be sent reliably. 321 3.1.1. INVITE Request with SDP 323 When a UAC includes a SDP body in the INVITE request as an offer, 324 only the first SDP in a reliable non-failure response to the INVITE 325 request is the real answer. No other offer/answer exchanges can 326 occur within the messages (other responses and ACK) of the INVITE 327 transaction. 329 In [RFC3261] there are some descriptions about an offer/answer 330 exchange, but those cause a little confusion. We interpret those 331 descriptions as follows, 333 UAC behavior 334 1. If the first SDP that the UAC received is included in an an 335 unreliable provisional response to the INVITE request, 336 [RFC3261] (section 13.2.1, 2nd bullet) requires that this be 337 treated as an answer. However, because that same section 338 states that the answer has to be in a reliable non-failure 339 message, this SDP is not the true answer and therefore the 340 offer/answer exchange is not yet completed. 341 2. After the UAC has received the answer in a reliable 342 provisional response to the INVITE, [RFC3261] requires that 343 any SDP in subsequent responses be ignored. 344 3. If the second and subsequent SDP(including a real answer) is 345 different from the first SDP, UAC should consider that the SDP 346 is equal to the first SDP. Therefore, UAC should not switch 347 to the new SDP. 349 UAS behavior 350 1. [RFC3261] requires all SDP in the responses to the INVITE 351 request to be identical. 352 2. After UAS has sent the answer in a reliable provisional 353 response to the INVITE, UAS should not include any SDP in 354 subsequent responses to the INVITE. 355 3. [RFC3261] permits the UAS to send any provisional response 356 without SDP regardless of the transmission of the answer. 358 A session description in an unreliable response that precedes a 359 reliable response can be considered a "preview" of the answer that 360 will be coming. 362 NOTE: This "preview" session description rule applies to a single 363 offer/answer exchange. In parallel offer/answer exchanges (caused 364 by forking) a UA may obviously receive a different "preview" of an 365 answer in each dialog. UAs are expected to deal with this. 367 Although [RFC3261] says a UA should accept media once an INVITE with 368 an offer has been sent, in many cases, an answer (or, at least a 369 preview of it) is required in order for media to be accepted. Two 370 examples of why this might be required are: 372 o To avoid receiving media from undesired sources, some User Agents 373 assume symmetric RTP will be used, ignore all incoming media 374 packets until an address/port has been received from the other 375 end, and then use that address/port to filter incoming media 376 packets. 378 o In some networks, an intermediate node must authorize a media 379 stream before it can flow and requires a confirming answer to the 380 offer before doing so. 382 Therefore, a UAS should send a SDP answer reliably (if possible) 383 before it starts sending media. And, if neither the UAC nor the UAS 384 support 100rel, the UAS should send a preview of the answer before it 385 starts sending media. 387 UAC UAS 388 | F1 INVITE (SDP) | <- The offer in the offer/answer model 389 |-------------------->| 390 | F2 1xx (SDP) | <- The offer/answer exchange is not 391 |<--------------------| closed yet, but UAC acts as if it 392 | | ^ receives the answer. 393 | F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer 394 |<--------------------| | SDP. 395 | F4 PRACK (no SDP) | | 396 |-------------------->| | UAC must not send a new offer. 397 | F5 2xx PRA (no SDP) | | 398 |<--------------------| v 399 | | 400 | F6 1xx-rel (SDP) | <- The answer in the offer/ answer model 401 |<--------------------| - 402 | F7 PRACK | | UAC can send a new offer in a PRACK 403 |-------------------->| | request to acknowledge F6. 404 | F8 2xx PRA | | After F7 UAC and UAS can send a new 405 |<--------------------| v offer in an UPDATE request. 406 | | 407 | F9 1xx-rel | <- SDP should not be included in the 408 |<--------------------| subsequent 1xx-rel once offer/answer 409 | F10 PRACK | has been completed. 410 |-------------------->| 411 | F11 2xx PRA | 412 |<--------------------| 413 | | 414 | F12 2xx INV | <- SDP should not be included in the 415 |<--------------------| final response once offer/answer has 416 | F13 ACK | been completed. 417 |-------------------->| 419 Figure 1: Example of Offer/Answer with 100rel Extension (1) 421 For example, in Figure 1, only the SDP in F6 is the answer. The SDP 422 in the non-reliable response (F2) is the preview of the answer and 423 must be the same as the answer in F6. Receiving F2, the UAC should 424 act as if it receives the answer. However, offer/answer exchange is 425 not completed yet and the UAC must not send a new offer until it 426 receives the same SDP in a reliable non-failure response, which is 427 the real answer. After sending the SDP in F6, the UAS must prepare 428 to receive a new offer from the UAC in a PRACK request, or in an 429 UPDATE request if the UAS supports UPDATE. 431 The UAS does not include SDP in responses F9 and F12. However, the 432 UAC should prepare to receive SDP bodies in F9 and/or F12, and just 433 ignore them, to handle a peer that does not conform to the 434 recommended implementation. 436 3.1.2. INVITE request without SDP 438 When a UAC does not include an SDP body in the INVITE request, 439 [RFC3261] (section 13.2.1, first bullet) requires that the UAS 440 include an offer in the first reliable non-failure response. 441 However, a UAC might not expect an SDP in the other responses to the 442 INVITE request because RFC 3261 simply does not anticipate the 443 possibility. Therefore, the UAS ought not include any SDP in the 444 other responses to the INVITE request. 446 NOTE: In Figure 2, the UAS should not include SDP in the responses 447 F6 and F9. However, the UAC should prepare to receive SDP bodies 448 in F6 and/or F9, and just ignore them to handle a peer that does 449 not conform to the recommended implementation. 451 UAC UAS 452 | F1 INVITE (no SDP) | 453 |-------------------->| 454 | F2 1xx | 455 |<--------------------| 456 | | 457 | F3 1xx-rel (SDP) | <- The first 1xx-rel must contain SDP 458 |<--------------------| as the offer. 459 | F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel 460 |-------------------->| must contain SDP as the answer. 461 | F5 2xx PRA (no SDP) | - 462 |<--------------------| | 463 | | | 464 | F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not 465 |<--------------------| | contain SDP. 466 | F7 PRACK | | 467 |-------------------->| | UAC can send a new offer in an UPDATE 468 | F8 2xx PRA | | request after F4. 469 |<--------------------| v 470 | | 471 | F9 2xx INV (no SDP) | <- The final response should not 472 |<--------------------| contain SDP. 473 | F10 ACK | 474 |-------------------->| 476 Figure 2: Example of Offer/Answer with 100rel Extension (2) 478 Note that in the case that the UAC needs to prompt the user to accept 479 or reject the offer, the reliable provisional response with SDP as an 480 offer (Pattern 4) can result in the retransmission until the PRACK 481 request can be sent. The UAC should take care to avoid this 482 situation when it sends the INVITE request without SDP. 484 3.2. Offer/Answer Exchange in Early Dialog 486 When both UAs support the 100rel extension, they can update the 487 session in the early dialog once the first offer/answer exchange has 488 been completed. 490 From a UA sending an INVITE request: 492 A UA can send an UPDATE request with a new offer if both ends support 493 the UPDATE method. Note that if the UAS needs to prompt the user to 494 accept or reject the offer, the delay can result in retransmission of 495 the UPDATE request. 497 A UA can send a PRACK request with a new offer only when 498 acknowledging the reliable provisional response carrying the answer 499 to an offer in the INVITE request. Compared to using the UPDATE 500 method, using PRACK can reduce the number of messages exchanged 501 between the UAs. However, to avoid problems or delays caused by 502 PRACK offer rejection, the UA is recommended to send a PRACK request 503 only when it has strong reasons to expect the receiver will accept 504 it. For example, the procedure used in precondition extension 505 [RFC3312] is a case where a PRACK request should be used for updating 506 the session status in an early dialog. Note also that if a UAS needs 507 to prompt the user to accept or reject the offer, the delay can 508 result in retransmission of the PRACK request. 510 From a UA receiving an INVITE request: 512 A UA can send an UPDATE request with a new offer if both ends support 513 the UPDATE method. A UAS can not send a new offer in the reliable 514 provisional response, so the UPDATE method is the only method for a 515 UAS to update an early session. 517 3.3. Offer/Answer Exchange in an Established Dialog 519 Both the re-INVITE and UPDATE methods can be used in an established 520 dialog to update the session. 522 The UPDATE method is simpler and can save at least one message 523 compared with the INVITE method. But both ends must support the 524 UPDATE method for it to be used. 526 The INVITE method needs at least three messages to complete but no 527 extensions are needed. Additionally, the INVITE method allows the 528 peer to take time to decide whether it will accept a session update 529 or not by sending provisional responses. That is, re-INVITE allows 530 the UAS to interact with the user at the peer, while UPDATE needs to 531 be answered automatically by the UAS. It is noted that re-INVITE 532 should be answered immediately unless such a user interaction is 533 needed. Otherwise, some 3pcc (Third Party Call Control) [RFC3725] 534 flows will break. 536 3.4. Recovering From a Failed ReINVITE 538 [RFC3261] section 14.1 requires that the session parameters in effect 539 prior to a re-INVITE remain unchanged if the re-INVITE fails, as if 540 no re-INVITE had been issued. This remains the case even if multiple 541 offer/answer exchanges have occurred between the sending of the re- 542 INVITE and its failure, and even if media has been exchanged using 543 the proposed changes in the session. Because this can be difficult 544 to achieve in practice, a newer specification [RFC6141] recommends 545 the UAS to send a 2xx response to a re-INVITE in cases where rolling 546 back changes would be problematic. 548 Nevertheless, a UAC may receive a failure response to a re-INVITE 549 after proposed changes that must be rolled back have already been 550 used. In such a case, the UAC should send an UPDATE offering the SDP 551 that has been reinstated. (See [RFC6141] for details.) 553 4. Exceptional Case Handling 555 In [RFC3264], the following restrictions are defined with regard to 556 sending a new offer. 558 "At any time, either agent MAY generate a new offer that updates 559 the session. However, it MUST NOT generate a new offer if it has 560 received an offer which it has not yet answered or rejected. It 561 MUST NOT generate a new offer if it has generated a prior offer 562 for which it has not yet received an answer or a rejection." 564 Assuming that the above rules are guaranteed, there seem to be two 565 possible 'exceptional' cases to be considered in SIP offer/answer 566 usage: the 'message crossing' case, and the 'glare' case. One of the 567 reasons why the usage of SIP methods to exchange offer/answer needs 568 to be carefully restricted in the RFCs is to ensure that the UA can 569 detect and handle appropriately the 'exceptional' cases to avoid 570 incompatible behavior. 572 4.1. Message Crossing Case Handling 574 When message packets cross in the transport network, an offer may be 575 received before the answer for the previous offer/answer exchange, as 576 shown in Figure 3. In such a case, UA A must detect that the session 577 description SDP-2 is not the answer to offer1. 579 A B 580 |SDP-1 (offer1)| 581 M1 |----------------->| 582 |SDP-2 (answer1)| 583 M2 |<------\ /-------| 584 | \/ | 585 |SDP-3 /\(offer2)| 586 M3 |<------/ \-------| 588 Figure 3: Message Crossing Case 590 Because of the restrictions on placement of offers and answers 591 (summarized in Table 1) there are a limited number of valid exchanges 592 of messages that may lead to this message crossing case. These are 593 enumerated in Table 3. (This table only shows messages containing 594 offers or answers. There could be other messages, without session 595 descriptions, which are not shown.) 597 When a response to UPDATE request crosses a reliable response to 598 INVITE request, there are variants shown in Figures 4 and 5, which 599 are dependent on an INVITE (Mx) that contains no offer. These are 600 also included in Table 3. 602 A B 603 | | 604 |UPDATE(offer1) | 605 M1 |==============================>| 606 |re-INVITE(no offer) | 607 Mx |------------------------------>| --+ 608 | 2xx-UPD(answer1)| | 609 M2 |<===========\ /===============| | first reliable 610 | \/ 1xx-rel/2xx-INV| | response 611 | /\ (offer2)| | 612 M3 |<===========/ \===============| <-+ 613 |PRACK/ACK(answer2) | 614 My |------------------------------>| 615 | | 617 Figure 4: Avoidable message crossing cases 619 To avoid this message crossing condition shown in Figure 4, UA A 620 should not send this re-INVITE request until an UPDATE transaction 621 has been completed. If UA B encounters this message crossing 622 condition, it should reject this re-INVITE request with a 500 623 response. 625 A B 626 | | 627 |re-INVITE(no offer) | 628 Mx |------------------------------>| --+ 629 |UPDATE(offer1) | | 630 M1 |==============================>| | 631 | 2xx-UPD(answer1)| | 632 M2 |<===========\ /===============| | first reliable 633 | \/ 1xx-rel/2xx-INV| | response 634 | /\ (offer2)| | 635 M3 |<===========/ \===============| <-+ 636 |PRACK/ACK(answer2) | 637 My |------------------------------>| 638 | | 640 Figure 5: Avoidable message crossing cases 642 To avoid this message crossing condition shown in Figure 5, UA A 643 should not send this UPDATE request until an ACK or a PRACK 644 transaction associated with an offer-answer has been completed. If 645 UA B encounters this message crossing condition, it should reject 646 this UPDATE request with a 500 response. 648 The situation when PRACK request crosses UPDATE request is shown in 649 Figure 6. 651 A B 652 | | 653 | re-INVITE (no offer)| 654 1st reliable+-- |<------------------------------| 655 response | M1|1xx-rel(offer1) | 656 +-> |==============================>| --+ 657 | PRACK(answer1)| M3| Acknowledge 658 |<===========\ /===============| <-+ 659 | \/ | 660 | /\ UPDATE(offer2)| 661 |<===========/ \===============| M2 662 |500-UPD | 663 |------------------------------>| 664 |2xx-PRA | 665 |------------------------------>| 666 | | 668 Figure 6: Avoidable message crossing cases 670 To avoid the message crossing condition shown in Figure 6, UA B 671 should not send this UPDATE request until an PRACK transaction 672 associated with an offer-answer has been completed. If UA A 673 encounters this message crossing condition, it should reject this 674 UPDATE request with a 500 response. 676 The situation when a reliable provisional response to INVITE request 677 crosses UPDATE request is shown in Figure 7. 679 A B 680 | | 681 |re-INVITE(offer1) | 682 M1 |==============================>| 683 | 1xx-rel(answer1)| 684 |<===========\ /===============| M3 685 | \/ | 686 | /\ UPDATE(offer2)| 687 +-- |<===========/ \===============| M2 688 | |491-UPD | 689 Acknowledge | |------------------------------>| 690 | |PRACK | 691 +-> |------------------------------>| 692 | | 694 Figure 7: Avoidable message crossing cases 696 To avoid the message crossing condition shown in Figure 7, UA B 697 should not send this UPDATE request until an PRACK transaction 698 associated with an offer-answer has been completed. If UA A 699 encounters this message crossing condition, it should reject this 700 UPDATE request with a 491 response. 702 The situation when a 2xx response to INVITE request crosses UPDATE 703 request is shown in Figure 8. 705 A B 706 | | 707 |re-INVITE(offer1) | 708 |==============================>| 709 | 2xx-INV(answer1)| 710 |<===========\ /===============| 711 | \/ | 712 | /\ UPDATE(offer2)| 713 +-- |<===========/ \===============| 714 | |491-UPD | 715 Acknowledge | |------------------------------>| 716 | |ACK | 717 +-> |------------------------------>| 718 | | 720 Figure 8: Avoidable message crossing cases 722 This is a true glare. To avoid the message crossing condition shown 723 in Figure 8, UA B should not send the UPDATE request until it has 724 received an ACK request. But there is no problem even if UA B sends 725 it. If UA A encounters this message crossing condition, it should 726 reject this UPDATE request with a 491 response. 728 The situation when a response to UPDATE request crosses PRACK request 729 is shown in Figure 9. 731 A B 732 | | 733 | re-INVITE(offer0)| 734 |<------------------------------| 735 |1xx-rel(answer0) | 736 |------------------------------>| --+ 737 |UPDATE(offer1) | | 738 M1 |==============================>| | 739 | 2xx-UPD(answer1)| | Acknowledge 740 |<===========\ /===============| M3| 741 | \/ | | 742 | /\ PRACK(offer2)| M2| 743 |<===========/ \===============| <-+ 744 | | 746 Figure 9: Avoidable message crossing case 748 To avoid the message crossing condition shown in Figure 9, UA A 749 should not send this UPDATE request until an PRACK transaction 750 associated with an offer-answer has been completed. If UA B 751 encounters this message crossing condition, it should reject this 752 UPDATE request with a 491 response. 754 Table 3 summarize this section. Each action is described in 755 Section 4.3. 757 | M1 | M3 | M2 |Action |Action |Figure| 758 |(offer1)|(answer1) |(offer2) | of A | of B | | 759 +--------+----------+-----------+-------+-------+------+ 760 | UPDATE | 2xx-UPD | UPDATE |UAS-UcU| | | 761 | | +-----------+-------+ - | | 762 | | | INVITE |UAS-UcI| | | 763 | | +-----------+-------+-------+------+ 764 | | | 1xx-INV | | | | 765 | | +-----------+UAC-UI,|UAS-UsI| 4,5 | 766 | | | 2xx-INV |UAC-IU |UAS-IsU| | 767 | | +-----------+-------+-------+------+ 768 | | | PRACK (*)|UAC-IU |UAS-IcU| 9 | 769 +--------+----------+-----------+-------+-------+------+ 770 | PRACK | 2xx-PRA | UPDATE |UAS-IcU| | | 771 +--------+----------+-----------+-------+ | | 772 | 2xx-INV| ACK | UPDATE |UAS-IsU| - | | 773 | | +-----------+-------+ | | 774 | | | INVITE |UAS-IsI| | | 775 +--------+----------+-----------+-------+-------+------+ 776 | 1xx-rel| PRACK | UPDATE |UAS-IsU| | 6 | 777 +--------+----------+-----------+-------+UAC-IU +------+ 778 | INVITE | 1xx-rel | UPDATE (*)| | | 7 | 779 | +----------+-----------+UAS-IcU+-------+------+ 780 | | 2xx-INV | UPDATE (*)| | - | 8 | 781 +--------+----------+-----------+-------+-------+------+ 782 (*) invalid sequences if INVITE request is an initial one 784 Table 3: Offer / Answer Crossing Message Sequences 786 4.2. Glare Case Handling 788 When both ends in a dialog send a new offer at nearly the same time, 789 as described in Figure 10, a UA may receive a new offer before it 790 receives the answer to the offer it sent. This case is usually 791 called a 'glare' case. 793 A B 794 |offer1 offer2| 795 M1 |-------\ /-------| M2 796 | \/ | 797 | /\ | 798 |<------/ \------>| 800 Figure 10: Glare Case 802 When offer2 is in an UPDATE request or (re-)INVITE request, it must 803 be rejected with a 491 or 500 response. 805 There is a variant of Figure 7. When offer2 is in a PRACK request 806 (within the current rules, only possible if offer1 is in an UPDATE 807 request), as shown in Figure 11, UA A has a dilemma. 809 A B 810 | | 811 | re-INVITE(offer0)| 812 |<------------------------------| 813 |1xx-rel(answer0) | 814 |------------------------------>| --+ 815 |UPDATE(offer1) PRACK(offer2)| M2| Acknowledge 816 M1 |============\ /===============| <-+ 817 | \/ | 818 | /\ | 819 |<===========/ \==============>| 820 | 491-UPD| 821 |<------------------------------| 822 | | 824 Figure 11: Avoidable glare case 826 All PRACKs are supposed to be accepted with a 200 response, yet there 827 is no way to indicate the problem with a 200 response. At best it 828 could proceed on the assumption that the UPDATE will be rejected with 829 a 491. To avoid this glare condition shown in Figure 11, UA A should 830 not send this UPDATE request until an PRACK transaction associated 831 with an offer-answer has been completed. If UA B encounters this 832 glare condition it should reject this UPDATE request with a 491 833 response. 835 Glare can also occur when offer2 is in a 1xx or 2xx response. This 836 is a variant of Figure 5, as shown in Figure 12. 838 A B 839 | | 840 |re-INVITE(no offer) | 841 |------------------------------>| --+ 842 | 1xx-rel/2xx-INV| | 1st reliable 843 |UPDATE(offer1) (offer2)| M2| response 844 M1 |============\ /===============| <-+ 845 | \/ | 846 | /\ | 847 |<===========/ \==============>| 848 | 500-UPD| 849 |<------------------------------| 850 | | 852 Figure 12: Avoidable glare case 854 To avoid this glare condition shown in Figure 12, UA A should not 855 send this UPDATE request until an ACK or a PRACK transaction 856 associated with an offer-answer has been completed. If UA B 857 encounters this glare condition it should reject this UPDATE request 858 with a 500 response. 860 There is a variant of Figure 4, as shown in Figure 13. 862 A B 863 | | 864 |UPDATE(offer1) | 865 |==========\ | 866 |re-INVITE \ (no offer) | 867 |------------\----------------->| --+ 868 | \ 1xx-rel/2xx-INV| | 1st reliable 869 | \ (offer2)| | response 870 |<==============\===============| <-+ 871 | \ | 872 | \============>| 873 | 500-UPD| 874 |<------------------------------| 875 | | 877 Figure 13: Avoidable glare case 879 To avoid this glare condition shown in Figure 13, UA A should not 880 send this re-INVITE request until an UPDATE transaction has been 881 completed. If UA B encounters this glare condition it should reject 882 this UPDATE request with a 500 response. 884 Table 4 summarize this section. Each action is described in 885 Section 4.3. 887 | offer1 | offer2 |Action |Action |Figure| 888 | M1 | M2 | of A | of B | | 889 +-----------+-----------+-------+-------+------+ 890 | | re-INVITE |UAS-IcI|UAS-IcI| | 891 | re-INVITE +-----------+-------+-------+ | 892 | | UPDATE |UAS-IcU|UAS-UcI| | 893 +-----------+-----------+-------+-------+ | 894 | | UPDATE |UAS-UcU|UAS-UcU| | 895 | +-----------+-------+-------+------+ 896 | | 1xx-rel | | | | 897 | UPDATE +-----------+UAC-IU,|UAS-IsU|12,13 | 898 | | 2xx-INV |UAC-UI | | | 899 | +-----------+-------+-------+------+ 900 | | PRACK (*) |UAC-IU |UAS-IcU| 11 | 901 +-----------+-----------+-------+-------+------+ 902 (*) invalid sequences if INVITE request is an initial one 904 Table 4: Offer / Answer Glare Message Sequences 906 4.3. Interworking of UPDATE and re-INVITE 908 Almost all exceptional cases are caused by an interworking of UPDATE 909 and re-INVITE. The interworking is described in Section 5 of 910 [RFC3311]. And UAC Behavior sending an UPDATE is described in 911 Section 5.1 of [RFC3311]. There are two concerns in this section, 912 1. It seems to describe different rules for each of initial INVITE 913 and re-INVITE. But there is no particular reason why the rules 914 are separated. The lack of restrictions for sending a re-INVITE 915 request cause a lot of problems shown in Section 4.1. 916 2. It seems to describe that a UA may send an UPDATE request after 917 sending or receiving a PRACK request. But it should be "after 918 PRACK transaction is completed by 2xx response", because it 919 causes the message-crossing case shown in Figure 6 921 Since it is assumed that the language in this section itself is non- 922 normative and is justified as a corollary of 3261, we interpret it as 923 follows, 924 UAC-II: While an INVITE transaction is incomplete or ACK 925 transaction associated with an offer-answer is incomplete, 926 a UA must not send another INVITE request. 927 UAC-UU: While an UPDATE transaction is incomplete, a UA must not 928 send another UPDATE request. 930 UAC-UI: While an UPDATE transaction is incomplete, a UA should not 931 send a re-INVITE request. 932 UAC-IU: While an INVITE transaction is incomplete, and an ACK or a 933 PRACK transaction associated with an offer-answer is 934 incomplete, a UA should not send an UPDATE request. 936 When a 2xx response to an INVITE includes an offer, the ACK 937 transaction is considered to be associated with an offer-answer. 939 When a reliable provisional response to an INVITE includes an offer 940 or an answer, the PRACK transaction is considered to be associated 941 with an offer-answer. 943 UAS Behavior receiving an UPDATE is described in Section 5.2 of 944 [RFC3311]. There are two concerns in this section, 945 1. There are no description about the interworking of an UPDATE 946 request and an INVITE request without an offer. 947 2. There are no description about the interworking of an UPDATE 948 request and reliable response to INVITE with an offer. 950 We interpret this section as follows, 951 UAS-IcI: While an INVITE client transaction is incomplete or ACK 952 transaction associated with an offer-answer is incomplete, 953 a UA must reject another INVITE request with a 491 954 response. 955 UAS-IsI: While an INVITE server transaction is incomplete or ACK 956 transaction associated with an offer-answer is incomplete, 957 a UA must reject another INVITE request with a 500 958 response. 959 UAS-UcU: While an UPDATE client transaction is incomplete, a UA must 960 reject another UPDATE request with a 491 response. 961 UAS-UsU: While an UPDATE server transaction is incomplete, a UA must 962 reject another UPDATE request with a 500 response. 963 UAS-UcI: While an UPDATE client transaction is incomplete, a UA 964 should reject a re-INVITE request with a 491 response. 965 UAS-UsI: While an UPDATE server transaction is incomplete, a UA 966 should reject a re-INVITE request with a 500 response. 967 UAS-IcU: While an INVITE client transaction is incomplete, and an 968 ACK or a PRACK transaction associated with an offer-answer 969 is incomplete, a UA should reject an UPDATE request with a 970 491 response. 971 UAS-IsU: While an INVITE server transaction is incomplete, and an 972 ACK or a PRACK transaction associated with an offer-answer 973 is incomplete, a UA should reject an UPDATE request with a 974 500 response. 976 These rules are shown in following figures. 978 A B 979 | | 980 | UPDATE| 981 |<------------------------------| 982 |UPDATE | 983 |==============================>| 984 | 491| 985 |<==============================| 986 | | 988 Figure 14: Example of UAC-UU and UAS-UcU 990 A B 991 | | 992 |UPDATE CSeq:m | 993 |------------------------------>| 994 |UPDATE CSeq:n(>m) | 995 |==============================>| 996 | 500 (UPDATE CSeq:n)| 997 |<==============================| 998 | | 1000 Figure 15: Example of UAC-UU and UAS-UsU 1002 A B 1003 | | 1004 | UPDATE(offer1)| 1005 |<------------------------------| 1006 |reINVITE(no offer) | 1007 |==============================>| 1008 | 491 (INVITE)| 1009 |<==============================| 1010 | | 1012 Figure 16: Example of UAC-UI and UAS-UcI 1014 A B 1015 | | 1016 |UPDATE(offer1) | 1017 |------------------------------>| 1018 |reINVITE(no offer) | 1019 |==============================>| 1020 | 500 (INVITE)| 1021 |<==============================| 1022 | | 1024 Figure 17: Example of UAC-UU and UAS-UsI 1026 A B 1027 | | 1028 | reINVITE(no offer)| 1029 |<------------------------------| 1030 |1xx-rel(offer0) | 1031 |------------------------------>| 1032 |UPDATE(offer1) | 1033 |==============================>| 1034 | 491 (UPDATE)| 1035 |<==============================| 1036 | | 1038 Figure 18: Example of UAC-IU and UAS-IcU 1040 A B 1041 | | 1042 |reINVITE(no offer) | 1043 |------------------------------>| 1044 | 1xx-rel(offer0)| 1045 |<------------------------------| 1046 |UPDATE(offer1) | 1047 |==============================>| 1048 | 500 (UPDATE)| 1049 |<==============================| 1050 | | 1052 Figure 19: Example of UAC-IU and UAS-IsU 1054 In addition, it is assumed that the UPDATE request in this section 1055 include an offer. The interworking of a re-INVITE and an UPDATE 1056 without an offer is out of scope for this document. 1058 5. Content of Offers and Answers 1060 While [RFC3264] and [RFC3312] give some guidance, questions remain 1061 about exactly what should be included in an offer or answer. This is 1062 especially a problem when the common "hold" feature has been 1063 activated, and when there is the potential for a multimedia call. 1065 Details of behavior depend on the capabilities and state of the User 1066 Agent. The kinds of recommendations that can be made are limited by 1067 the model of device capabilities and state that is presumed to exist. 1069 This section focuses on a few key aspects of offers and answers that 1070 have been identified as troublesome, and will consider other aspects 1071 to be out of scope. This section considers: 1072 o choice of supported media types and formats to include and exclude 1073 o hold and resume of media 1075 The following are out of scope for this document: 1076 o NAT traversal and ICE 1077 o specific codecs and their parameters 1078 o the negotiation of secure media streams 1079 o grouping of media streams 1080 o preconditions 1082 5.1. General Principle for Constructing Offers and Answers 1084 A UA should send an offer that indicates what it, and its user, are 1085 interested in using/doing at that time, without regard for what the 1086 other party in the call may have indicated previously. This is the 1087 case even when the offer is sent in response to an INVITE or re- 1088 INVITE that contains no offer. (However in the case of re-INVITE the 1089 constraints of [RFC3261] and [RFC3264] must be observed.) 1091 A UA should send an answer that includes as close an approximation to 1092 what the UA and its user are interested in doing at that time, while 1093 remaining consistent with the offer/answer rules of [RFC3264] and 1094 other RFCs. 1096 NOTE: "at that time" is important. The device may permit the user 1097 to configure which supported media are to be used by default. 1099 In some cases a UA may not have direct knowledge of what it is 1100 interested in doing at a particular time. If it is an intermediary 1101 it may be able to delegate the decision. In the worst case it may 1102 apply a default, such as assuming it wants to use all of its 1103 capabilities. 1105 5.2. Choice of Media Types and Formats to Include and Exclude 1107 5.2.1. Sending an Initial INVITE with Offer 1109 When a UAC sends an initial INVITE with an offer, it has complete 1110 freedom to choose which media type(s) and media format(s) (payload 1111 types in the case of RTP) it should include in the offer. 1113 The media types may be all or a subset of the media the UAC is 1114 capable of supporting, with the particular subset being determined by 1115 the design and configuration (e.g., via [RFC6080]) of the UAC 1116 combined with input from the user interface of the UAC. 1118 The media formats may be all or a subset of the media formats the UAC 1119 is capable of supporting for the corresponding media type, with the 1120 particular subset being determined by the design and configuration of 1121 the UAC combined with input from the user interface of the UAC. 1123 Including all supported media formats will maximize the possibility 1124 that the other party will have a supported format in common. But 1125 including many can result in an unacceptably large SDP body. 1127 5.2.2. Responding with an Offer when the Initial INVITE has no Offer 1129 When a UAS has received an initial INVITE without an offer, it must 1130 include an offer in the first reliable response to the INVITE. It 1131 has largely the same options as when sending an initial INVITE with 1132 an offer, but there are some differences. The choice may be governed 1133 by both static (default) selections of media types as well as dynamic 1134 selections made by a user via interaction with the device while it is 1135 alerting. 1137 NOTE: The offer may be sent in a reliable provisional response, 1138 before the user of the device has been alerted and had an 1139 opportunity to select media options for the call. In this case 1140 the UAS cannot include any call-specific options from the user of 1141 the device. If there is a possibility that the user of the device 1142 will wish to change what is offered before answering the call, 1143 then special care should be taken. If PRACK and UPDATE are 1144 supported by caller and callee then an initial offer can be sent 1145 reliably, and changed with an UPDATE if the user desires a change. 1146 If PRACK and UPDATE are not supported then the initial offer 1147 cannot be changed until the call is fully established. In that 1148 case the offer in a 200 response for the initial INVITE should 1149 include only the media types and formats believed to be acceptable 1150 to the user. 1152 5.2.3. Answering an Initial INVITE with Offer 1154 When a UAS receives an initial INVITE with an offer, what media lines 1155 the answer may contain is constrained by [RFC3264]. The answer must 1156 contain the same number of m-lines as the offer, and they must 1157 contain the same media types. Each media line may be accepted, by 1158 including a non-zero port number, or rejected by including a zero 1159 port number in the answer. The media lines that are accepted should 1160 typically be those with types and formats the UAS would have included 1161 if it were the offerer. 1163 The media formats the answer may contain are constrained by 1164 [RFC3264]. For each accepted m-line in the answer, there must be at 1165 least one media format in common with the corresponding m-line of the 1166 offer. The UAS may also include other media formats it is able to 1167 support at this time. Doing so establishes an asymmetric media 1168 format situation, where these "other" media formats may only be sent 1169 from the offerer to the answerer. This asymmetric media situation is 1170 also limited because it cannot be sustained if there is a subsequent 1171 offer/answer exchange in the opposite direction. Also, there is 1172 limited value in including these other media formats because there is 1173 no assurance that the offerer will be able to use them. 1175 If the UAS does not wish to indicate support for any of the media 1176 types in a particular media line of the offer it must reject the 1177 corresponding media line, by setting the port number to zero. 1179 When the UAS wishes to reject all of the media lines in the offer, it 1180 may send a 488 failure response. Alternatively it may send a 1181 reliable non-failure response including all media lines with port 1182 numbers set to zero. 1184 5.2.4. Answering when the Initial INVITE had no Offer 1186 When a UAC has sent an initial INVITE without an offer, and then 1187 receives a response with the first offer, it should answer in the 1188 same way as a UAS receiving an initial INVITE with an offer. 1190 Because the offer arrives in a response to the INVITE, the UAC cannot 1191 reject the message containing the offer. If the UAC wishes to reject 1192 the entire offer, it must send a PRACK or ACK request including all 1193 the media lines with ports set to zero. Then, if it does not wish to 1194 continue the session it may send a CANCEL or BYE request to terminate 1195 the dialog. 1197 5.2.5. Subsequent Offers and Answers 1199 The guidelines above (Section 5.1 and Section 5.2.1 through 1200 Section 5.2.4) apply, but constraints in [RFC3264] must also be 1201 followed. The following are of particular note because they have 1202 proven troublesome: 1203 o The number of m-lines may not be reduced in a subsequent offer. 1204 Previously rejected media streams must remain, or be reused to 1205 offer the same or a different stream. (Section 6 of [RFC3264].) 1206 o In the o-line, only the version number may change, and if it 1207 changes it must increment by one from the one previously sent as 1208 an offer or answer. (Section 8 of [RFC3264].) If it doesn't 1209 change then the entire SDP body must be identical to what was 1210 previously sent as an offer or answer. Changing the o-line, 1211 except version number value, during the session is an error case. 1212 The behavior when receiving such a non-compliant offer/answer SDP 1213 body is implementation dependent. If a UA needs to negotiate a 1214 'new' SDP session, it should use the INVITE/Replaces method. 1215 o In the case of RTP, the mapping from a particular dynamic payload 1216 type number to a particular codec within that media stream 1217 (m-line) must not change for the duration of the session. 1218 (Section 8.3.2 of [RFC3264].) 1220 NOTE: This may be impossible for a B2BUA to follow in some 1221 cases (e.g. 3pcc transfer) if it does not terminate media. 1223 When the new offer is sent in response to an offerless (re)INVITE, it 1224 should be constructed according to the General Principle for 1225 Constructing Offers and Answers (Section 5.1 ): all codecs the UA is 1226 currently willing and able to use should be included, not just the 1227 ones that were negotiated by previous offer/answer exchanges. The 1228 same is true for media types - so if UA A initially offered audio and 1229 video to UA B, and they end up with only audio, and UA B sends an 1230 offerless (re)INVITE to UA A, A's resulting offer should most likely 1231 re-attempt video, by reusing the zeroed m-line used previously. 1233 NOTE: The behavior above is recommended, but it is not always 1234 achievable - for example in some interworking scenarios. Or, the 1235 offerer may simply not have enough resources to offer "everything" 1236 at that point. Even if the UAS is not able to offer any other SDP 1237 that the one currently being used, it should not reject the re- 1238 INVITE. Instead, it should generate an offer with the currently 1239 used SDP with o- line unchanged. 1241 5.3. Hold and Resume of media 1243 [RFC3264] specifies (using non-normative language) that "hold" should 1244 be indicated in an established session by sending a new offer 1245 containing "a=sendonly" for each media stream to be held. An 1246 answerer is then to respond with "a=recvonly" to acknowledge that the 1247 hold request has been understood. 1249 Note that the use of sendonly/recvonly is not limited to hold. These 1250 may be used for other reasons, such as devices that are only capable 1251 of sending or receiving. So receiving an offer with "a=sendonly" 1252 must not be treated as a certain indication that the offerer has 1253 placed the media stream on hold. 1255 This model is based on an assumption that the UA initiating the hold 1256 will want to play Music on Hold, which is not always the case. A UA 1257 may, if desired, initiate hold by offering "a=inactive" if it does 1258 not intend to transmit any media while in hold status. 1260 The rules of [RFC3264] constrain what may be in an answer when the 1261 offer contains "sendonly", "recvonly", or "inactive" in an a= line. 1262 But they do not constrain what must be in a subsequent offer. The 1263 General Principle for Constructing Offers and Answers (Section 5.1) 1264 is important here. The initiation of "hold" is a local action. It 1265 should reflect the desired state of the UA. It then affects what the 1266 UA includes in offers and answers until the local state is reset. 1268 The receipt of an offer containing "a=sendonly" or "a=inactive" and 1269 the sending of a compatible answer should not change the desired 1270 state of the recipient. However, a UA that has been "placed on hold" 1271 may itself desire to initiate its own hold status, based on local 1272 input. 1274 If UA2 has previously been "placed on hold" by UA1, via receipt of 1275 "a=sendonly", then it may initiate its own hold by sending a new 1276 offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will 1277 answer with "a=inactive" because that is the only valid answer that 1278 reflects its desire not to receive media. 1280 NOTE: Section 8.4 of [RFC3264] contains a conflicting 1281 recommendation that the offer contain "a=inactive" in this case. 1282 We interpret that recommendation to be non-normative. The use of 1283 "a=sendonly" in this case will never produce a worse outcome, and 1284 can produce a better outcome in useful cases. 1286 Once in this state, to resume a two way exchange of media each side 1287 must reset its local hold status. If UA1 is first to go off hold it 1288 will then send an offer with "a=sendrecv". The UA2 will respond with 1289 its desired state of "a=sendonly" because that is a permitted 1290 response. When UA2 desires to also resume, it will send an offer 1291 with "a=sendrecv". In this case, because UA1 has the same desire it 1292 will respond with "a=sendrecv". In the same case, when UA2 receives 1293 the offer with "a=sendrecv", if it has decided it wants to reset its 1294 local hold but has not yet signaled the intent, it may send 1295 "a=sendrecv" in the answer. 1297 If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", 1298 and subsequently wants to initiate its own hold, also using 1299 "a=inactive", it need not send a new offer, since the only valid 1300 response is "a=inactive" and that is already in effect. However, its 1301 local desired state will now be either "inactive" or "a=sendonly". 1302 This affects what it will send in future offers and answers. 1304 If a UA has occasion to send another offer in the session, without 1305 any desire to change the hold status (e.g. in response to a re- 1306 INVITE without an offer, or when sending a re-INVITE to refresh the 1307 session timer) it should follow the General Principle for 1308 Constructing Offers and Answers (Section 5.1). If it previously 1309 initiated a "hold" by sending "a=sendonly" or "a=inactive" then it 1310 should offer that again. If it had not previously initiated "hold" 1311 then it should offer "a=sendrecv", even if it had previously been 1312 forced to answer something else. Without this behavior it is 1313 possible to get "stuck on hold" in some cases, especially when a 3pcc 1314 is involved. 1316 5.4. Behavior on receiving SDP with c=0.0.0.0 1318 [RFC3264] requires that an agent be capable of receiving SDP with a 1319 connection address of 0.0.0.0, in which case it means that neither 1320 RTP nor RTCP should be sent to the peer. 1322 If a UA generates an answer to the offer received with "c=IN IP4 1323 0.0.0.0", the direction attribute of the accepted media stream in the 1324 answer must still be based on direction attribute of the offered 1325 stream and rules specified in [RFC3264] to form the direction a-line 1326 in the answer. There is no clear rule about the use of "c=IN IP4 1327 0.0.0.0" in the answer - it may be used or c-line with a valid IP 1328 address may be used. RTP/RTCP will not be sent toward an address of 1329 0.0.0.0 because it is an invalid address. 1331 6. IANA Considerations 1333 This document has no actions for IANA. 1335 7. Security Considerations 1337 This document clarifies ambiguities in the intended behavior of the 1338 two SIP User Agents engaged in a dialog. The primary specification 1339 of offer/answer behavior that is being clarified resides in [RFC3261] 1340 and [RFC3264], with extensions in [RFC3311], [RFC3312], and 1341 [RFC6141]. The focus of this document is on cases where ambiguities 1342 can result failed or degraded calls when there is no attacker. The 1343 clarifications exclude call flows that lead to difficulties, without 1344 legitimizing any formerly invalid call flows. Thus the security 1345 considerations of the above mentioned documents continue to apply and 1346 need not be extended to handle any additional cases. 1348 The offer/answer process can be disrupted in numerous ways by an 1349 attacker. SIP provides mechanisms to protect the offer/answer 1350 exchange from tampering by 3rd parties. Of note is Enhancements for 1351 Authenticated Identity Management in the Session Initiation Protocol 1352 (SIP) [RFC4474], as well as Section Section 26.3.2 (Security 1353 Solutions) of [RFC3261]. 1355 8. Acknowledgement 1357 The authors would like to thank Christer Holmberg, Rajeev Seth, 1358 Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo and 1359 Gao Yang for their thorough reviews and comments. Many of their 1360 suggestions and ideas have been incorporated in this document. 1362 9. References 1364 9.1. Normative References 1366 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1367 A., Peterson, J., Sparks, R., Handley, M., and E. 1368 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1369 June 2002. 1371 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1372 Provisional Responses in Session Initiation Protocol 1373 (SIP)", RFC 3262, June 2002. 1375 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1376 with Session Description Protocol (SDP)", RFC 3264, 1377 June 2002. 1379 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1380 UPDATE Method", RFC 3311, October 2002. 1382 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1383 "Integration of Resource Management and Session Initiation 1384 Protocol (SIP)", RFC 3312, October 2002. 1386 [RFC6141] Camarillo, G., Holmberg, C., and Y. Gao, "Re-INVITE and 1387 Target-Refresh Request Handling in the Session Initiation 1388 Protocol (SIP)", RFC 6141, March 2011. 1390 9.2. Informative References 1392 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1393 Camarillo, "Best Current Practices for Third Party Call 1394 Control (3pcc) in the Session Initiation Protocol (SIP)", 1395 BCP 85, RFC 3725, April 2004. 1397 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 1398 Session Initiation Protocol (SIP)", RFC 3959, 1399 December 2004. 1401 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1402 Authenticated Identity Management in the Session 1403 Initiation Protocol (SIP)", RFC 4474, August 2006. 1405 [RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session 1406 Initiation Protocol User Agent Profile Delivery", 1407 RFC 6080, March 2011. 1409 Authors' Addresses 1411 OKUMURA Shinji 1412 Softfront 1413 28-196, Noth9, West15, Chuo-ku 1414 Sapporo, Hokkaido 060-0009 1415 Japan 1417 Email: shinji.okumura@softfront.jp 1419 Takuya Sawada 1420 KDDI Corporation 1421 3-10-10, Iidabashi, Chiyoda-ku 1422 Tokyo 1423 Japan 1425 Email: tu-sawada@kddi.com 1426 Paul H. Kyzivat 1427 Cisco Systems, Inc. 1428 1414 Massachusetts Avenue 1429 Boxborough, MA 01719 1430 USA 1432 Email: pkyzivat@cisco.com