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