idnits 2.17.1 draft-ietf-sipping-sip-offeranswer-13.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 (May 10, 2010) is 5093 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-17 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 P. Kyzivat 5 Expires: November 11, 2010 Cisco Systems, Inc. 6 May 10, 2010 8 SIP (Session Initiation Protocol) Usage of the Offer/Answer Model 9 draft-ietf-sipping-sip-offeranswer-13 11 Abstract 13 The Session Initiation Protocol (SIP) utilizes the offer/answer model 14 to establish and update multimedia sessions using the Session 15 Description Protocol (SDP). The description of the offer/answer 16 model in SIP is dispersed across multiple RFCs. This document 17 summarizes all the current usages of the offer/answer model in SIP 18 communication. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 11, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Summary of SIP usage of the Offer/Answer Model . . . . . . . . 3 57 2.1. Offer/Answer Exchange Pairs in SIP Messages . . . . . . . 4 58 2.2. Rejection of an Offer . . . . . . . . . . . . . . . . . . 5 59 2.3. Session Description which is not Offer nor Answer . . . . 7 60 3. Detailed Discussion of the Offer/Answer Model for SIP . . . . 7 61 3.1. Offer/Answer for the INVITE method with 100rel 62 extension . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1.1. INVITE Request with SDP . . . . . . . . . . . . . . . 7 64 3.1.2. INVITE request without SDP . . . . . . . . . . . . . . 10 65 3.2. Offer/Answer Exchange in Early Dialog . . . . . . . . . . 11 66 3.3. Offer/Answer Exchange in an Established Dialog . . . . . . 12 67 3.4. Recovering From a Failed ReINVITE . . . . . . . . . . . . 12 68 4. Exceptional Case Handling . . . . . . . . . . . . . . . . . . 13 69 4.1. Message Crossing Case Handling . . . . . . . . . . . . . . 13 70 4.2. Glare Case Handling . . . . . . . . . . . . . . . . . . . 18 71 4.3. Interworking of UPDATE and reINVITE . . . . . . . . . . . 21 72 5. Content of Offers and Answers . . . . . . . . . . . . . . . . 24 73 5.1. General Principle for Constructing Offers and Answers . . 25 74 5.2. Choice of Media Types and Formats to Include and 75 Exclude . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 5.2.1. Sending an Initial INVITE with Offer . . . . . . . . . 25 77 5.2.2. Responding with an Offer when the Initial INVITE 78 has no Offer . . . . . . . . . . . . . . . . . . . . . 26 79 5.2.3. Answering an Initial INVITE with Offer . . . . . . . . 26 80 5.2.4. Answering when the Initial INVITE had no Offer . . . . 27 81 5.2.5. Subsequent Offers and Answers . . . . . . . . . . . . 27 82 5.3. Hold and Resume of media . . . . . . . . . . . . . . . . . 28 83 5.4. Behavior on receiving SDP with c=0.0.0.0 . . . . . . . . . 30 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 86 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 30 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 92 1. Introduction 94 SIP utilizes the offer/answer model to establish and update sessions. 95 The rules to govern the offer/answer behaviors in SIP are described 96 in the several RFCs. ([RFC3261], [RFC3262], [RFC3264], [RFC3311], 97 and [I-D.camarillo-sipcore-reinvite].) 99 The primary purpose of this document is to describe all forms of SIP 100 usage of the offer/answer model in one document to help the readers 101 to fully understand it. Also, this document tries to incorporate the 102 results of the discussions on the controversial issues to avoid 103 repeating the same discussions later. 105 This document does not make normative changes. Rather, it recommends 106 how to use the existing standards to best effect. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 This document only uses these key words when referencing normative 114 statements in existing RFCs. 116 2. Summary of SIP usage of the Offer/Answer Model 118 The offer/answer model itself is independent from the higher layer 119 application protocols which utilize it. SIP is one of the 120 applications using the offer/answer model. [RFC3264] defines the 121 offer/answer model, but does not specify which SIP messages should 122 convey an offer or an answer. This should be defined in the SIP core 123 and extensions RFCs. 125 In theory, any SIP message can include a session description in its 126 body. But a session description in a SIP message is not necessarily 127 an offer or an answer. Only certain session description usages that 128 conform to the rules described in standards-track RFCs can be 129 interpreted as an offer or an answer. The rules for how to handle 130 the offer/answer model are defined in several RFCs. 132 The offer/answer model defines a mechanism for update of sessions. 133 In SIP, a dialog is used to associate an offer/answer exchange with 134 the session which it is to update. In other words, only the offer/ 135 answer exchange in the SIP dialog can update the session which is 136 managed by that dialog. 138 2.1. Offer/Answer Exchange Pairs in SIP Messages 140 Currently, the rules on the offer/answer model are defined in 141 [RFC3261], [RFC3262], [RFC3264], [RFC3311] and 142 [I-D.camarillo-sipcore-reinvite]. In these RFCs, only the six 143 patterns shown in Table 1 are defined for exchanging an offer and an 144 answer with SIP messages. 146 Note that an offer/answer exchange initiated by an INVITE request 147 must follow exactly one of the patterns 1, 2, 3, 4. When an initial 148 INVITE causes multiple dialogs due to forking, an offer/answer 149 exchange is carried out independently in each distinct dialog. When 150 an INVITE request contains no offer, only Pattern 2 or Pattern 4 151 apply. 'The first reliable non-failure message' must have an offer 152 if there is no offer in the INVITE request. This means that UA which 153 receives the INVITE request without an offer must include an offer in 154 the first reliable response with 100rel extension. If no reliable 155 provisional response has been sent, the UAS must include an offer 156 when sending 2xx response. 158 In Pattern 3, the first reliable provisional response may or may not 159 have an answer. When a reliable provisional response contains a 160 session description, and is the first to do so, then that session 161 description is the answer to the offer in the INVITE request. The 162 answer can not be updated, and a new offer can not be sent in a 163 subsequent reliable response for the same INVITE transaction. 165 In Pattern 5, a PRACK request can contain an offer only if the 166 reliable response which it acknowledges contains an answer to the 167 previous offer/answer exchange. 169 NOTE: It is legal to have UPDATE/2xx exchanges without offer/ 170 answer exchanges (Pattern 6). However when re-INVITEs are sent 171 for non-offer/answer purposes, an offer/answer exchange is 172 required. In that case the prior SDP will typically be repeated. 174 There may be ONLY ONE offer/answer negotiation in progress for a 175 single dialog at any point in time. Section 4 explains how to ensure 176 this. When an INVITE results in multiple dialogs each has a separate 177 offer/answer negotiation. 179 NOTE: This is when using a Content-Disposition of "session". 180 There may be a second offer/answer negotiation in progress using a 181 Content-Disposition of "early-session" [RFC3959]. That is not 182 addressed by this draft. 184 Offer Answer RFC Ini Est Early 185 ------------------------------------------------------------------- 186 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N 187 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N 188 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N 189 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N 190 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y 191 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y 193 Table 1: Summary of SIP Usage of the Offer/Answer Model 195 In Table 1, '1xx-rel' corresponds to the reliable provisional 196 response which contains the 100rel option defined in [RFC3262]. 198 The 'Ini' column shows the ability to exchange the offer/answer to 199 initiate the session. 'Y' indicates that the pattern can be used in 200 the initial offer/answer exchange, while 'N' indicates that it can 201 not. Only the initial INVITE transaction can be used to exchange the 202 offer/answer to establish a multimedia session. 204 The 'Est' column shows the ability to update the established session. 206 The 'Early' column indicates which patterns may be used to modify the 207 established session in an early dialog. There are two ways to 208 exchange a subsequent offer/answer in an early dialog. 210 2.2. Rejection of an Offer 212 It is not always clear how to reject an offer when it is 213 unacceptable, and some methods do not allow explicit rejection of an 214 offer. For each of the patterns in Table 1, Table 2 shows how to 215 reject an offer. 217 When a UA receives an INVITE request with an unacceptable offer, it 218 should respond with a 488 response, preferably with Warning header 219 field indicating the reason of the rejection, unless another response 220 code is more appropriate to reject it. (Pattern 1 and Pattern 3.) 222 If this is a reINVITE extra care must be taken, as detailed in 223 [I-D.camarillo-sipcore-reinvite]. Specifically, if the offer 224 contains any changes or additions to media stream properties, and 225 those have already been used to transmit/receive media before the 226 final response is sent, then a 2xx response should be sent, with a 227 syntactically correct session description. This may optionally be 228 followed by an UPDATE request to rearrange the session parameters if 229 both ends support the UPDATE method. Alternatively the UA may send 230 an error response to the (re)INVITE request to terminate the dialog 231 or to roll back the offer-answer status before sending reINVITE 232 request. In this case UAS should not continue to retransmit the 233 unacknowledged reliable provisional response, UAC should not continue 234 to retransmit a PRACK request. 236 When a UA receives an UPDATE request with an offer which it can not 237 accept, it should respond with a 488 response preferably with Warning 238 header field indicating the reason of the rejection, unless another 239 response code is more appropriate to reject it. (Pattern 6) 241 When a UA receives a PRACK request with an offer which it can not 242 accept, it may respond with a 200 response with a syntactically 243 correct session description. This may optionally be followed by an 244 UPDATE request to rearrange the session parameters if both ends 245 support the UPDATE method. Alternatively the UA may terminate the 246 dialog and send an error response to the INVITE request. (Pattern 5) 247 The 488 response is another proposed solution, UAS may respond with a 248 488 response and then UAC should send again a PRACK request without 249 an offer. 251 NOTE: In [RFC3262], the following restriction is defined with 252 regard to responding to a PRACK request. 254 "If the PRACK does match an unacknowledged reliable provisional 255 response, it MUST be responded to with a 2xx response." 257 This description is not completely correct. There are cases where 258 it is unacceptable to send a 2xx response. For example, 401 259 response can not be avoided. 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 Offer Rejection 270 ------------------------------------------------------------------ 271 1. INVITE Req. (*) 488 INVITE Response 272 2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer 273 OR termination of dialog 274 3. INVITE Req. 488 INVITE Response (same as Pattern 1.) 275 4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer 276 5. PRACK Req. (**) 200 PRACK Resp. followed by new offer 277 OR termination of dialog 278 6. UPDATE Req. 488 UPDATE Response 280 (*) If this was a reINVITE, a failure response should not be sent if 281 media has already been exchanged using the new offer. 283 (**) A UA should only use PRACK to send an offer when it has strong 284 reasons to expect the receiver will accept the offer. 286 Table 2: Rejection of an Offer 288 2.3. Session Description which is not Offer nor Answer 290 As previously stated, a session description in a SIP message is not 291 necessarily an offer or an answer. For example, SIP can use a 292 session description to describe capabilities apart from offer/answer 293 exchange. Examples of this are 200 OK responses for OPTIONS and 488 294 responses for INVITE. 296 3. Detailed Discussion of the Offer/Answer Model for SIP 298 3.1. Offer/Answer for the INVITE method with 100rel extension 300 The INVITE method provides the basic procedure for offer/answer 301 exchange in SIP. Without the 100rel option, the rules are simple as 302 described in [RFC3261]. If an INVITE request includes a session 303 description, Pattern 1 is applied and if an INVITE request does not 304 include a session description, Pattern 2 is applied. 306 With 100rel, Pattern 3, 4 and 5 are added and this complicates the 307 rules. An INVITE request may cause multiple responses. Note that 308 even if both UAs support the 100rel extension, not all the 309 provisional responses may be sent reliably. 311 3.1.1. INVITE Request with SDP 313 When a UAC includes an SDP body in the INVITE request as an offer, 314 only the first SDP in a reliable non-failure response to the INVITE 315 request is the real answer. No other offer/answer exchanges can 316 occur within the messages (other responses and ACK) of the INVITE 317 transaction. 319 In [RFC3261] there are some descriptions about an offer/answer 320 exchange, but those cause a little confusion. We interpret those 321 descriptions as follows, 323 UAC behavior 324 1. If the first SDP that UAC received is included in an 325 unreliable provisional response to the INVITE request, UAC 326 MUST treat it as an answer. But the SDP is not a real answer, 327 therefore the offer/answer exchange is not yet completed. 328 2. After UAC has received the answer in a reliable provisional 329 response to the INVITE, any SDP in subsequent responses to the 330 INVITE MUST be ignored. 331 3. If the second and subsequent SDP(including a real answer) is 332 different from the first SDP, UAC should consider that the SDP 333 is equal to the first SDP. Therefore, UAC should not switch 334 to the new SDP. 336 UAS behavior 337 1. All SDP in the responses to the INVITE request MUST be the 338 same exactly. 339 2. After UAS has sent the answer in a reliable provisional 340 response to the INVITE, UAS should not include any SDP in 341 subsequent responses to the INVITE. 342 3. UAS MAY send any provisional response without a SDP regardless 343 of the transmission of the answer. 345 A session description in an unreliable response that precedes a 346 reliable response can be considered a "preview" of the answer that 347 will be coming. 349 NOTE: This "preview" session description rule applies to a single 350 offer/answer exchange. In parallel offer/answer exchanges (caused 351 by forking) a UA may obviously receive a different "preview" of an 352 answer in each dialog. UAs are expected to deal with this. 354 Although [RFC3261] says a UA should accept media once an INVITE with 355 an offer has been sent, in many cases, an answer (or, at least a 356 preview of it) is required in order for media to be accepted. Two 357 examples of why this might be required are: 359 o To avoid receiving media from undesired sources, some User Agents 360 assume symmetric RTP will be used, ignore all incoming media 361 packets until an address/port has been received from the other 362 end, and then use that address/port to filter incoming media 363 packets. 365 o In some networks, an intermediate node must authorize a media 366 stream before it can flow and requires a confirming answer to the 367 offer before doing so. 369 Therefore, a UAS should send a SDP answer reliably (if possible) 370 before it starts sending media. And, if neither the UAC nor the UAS 371 support 100rel, the UAS should send a preview of the answer before it 372 starts sending media. 374 UAC UAS 375 | F1 INVITE (SDP) | <- The offer in the offer/answer model 376 |-------------------->| 377 | F2 1xx (SDP) | <- The offer/answer exchange is not 378 |<--------------------| closed yet, but UAC acts as if it 379 | | ^ receives the answer. 380 | F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer 381 |<--------------------| | SDP. 382 | F4 PRACK (no SDP) | | 383 |-------------------->| | UAC must not send a new offer. 384 | F5 2xx PRA (no SDP) | | 385 |<--------------------| v 386 | | 387 | F6 1xx-rel (SDP) | <- The answer in the offer/ answer model 388 |<--------------------| - 389 | F7 PRACK | | UAC can send a new offer in a PRACK 390 |-------------------->| | request to acknowledge F6. 391 | F8 2xx PRA | | After F7 UAC and UAS can send a new 392 |<--------------------| v offer in an UPDATE request. 393 | | 394 | F9 1xx-rel | <- SDP should not be included in the 395 |<--------------------| subsequent 1xx-rel once offer/answer 396 | F10 PRACK | has been completed. 397 |-------------------->| 398 | F11 2xx PRA | 399 |<--------------------| 400 | | 401 | F12 2xx INV | <- SDP should not be included in the 402 |<--------------------| final response once offer/answer has 403 | F13 ACK | been completed. 404 |-------------------->| 406 Figure 1: Example of Offer/Answer with 100rel Extension (1) 408 For example, in Figure 1, only the SDP in F6 is the answer. The SDP 409 in the non-reliable response (F2) is the preview of the answer and 410 must be the same as the answer in F6. Receiving F2, the UAC should 411 act as if it receives the answer. However, offer/answer exchange is 412 not completed yet and the UAC must not send a new offer until it 413 receives the same SDP in a reliable non-failure response, which is 414 the real answer. After sending the SDP in F6, the UAS must prepare 415 to receive a new offer from the UAC in a PRACK request, or in an 416 UPDATE request if the UAS supports UPDATE. 418 The UAS does not include SDP in responses F9 and F12. However, the 419 UAC should prepare to receive SDP bodies in F9 and/or F12, and just 420 ignore them, to handle a peer that does not conform to the 421 recommended implementation. 423 3.1.2. INVITE request without SDP 425 When a UAC does not include a SDP body in the INVITE request, it 426 expects an offer to be received with the first reliable non-failure 427 response. And a UAS MUST include an offer in the first reliable non- 428 failure response and should not include any SDP in the other 429 responses to the INVITE request. The UAC will send the answer in the 430 request to acknowledge the response, i.e. PRACK or ACK request of 431 the reliable response. Other than that, no offer/answer exchanges 432 can occur in the messages within the INVITE transaction. 434 NOTE: The UAS should not include SDP in the responses F6 and F9. 435 However, the UAC should prepare to receive SDP bodies in F6 and/or 436 F9, and just ignore them to handle a peer that does not conform to 437 the recommended implementation. 439 UAC UAS 440 | F1 INVITE (no SDP) | 441 |-------------------->| 442 | F2 1xx | 443 |<--------------------| 444 | | 445 | F3 1xx-rel (SDP) | <- The first 1xx-rel must contain SDP 446 |<--------------------| as the offer. 447 | F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel 448 |-------------------->| must contain SDP as the answer. 449 | F5 2xx PRA (no SDP) | - 450 |<--------------------| | 451 | | | 452 | F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not 453 |<--------------------| | contain SDP. 454 | F7 PRACK | | 455 |-------------------->| | UAC can send a new offer in an UPDATE 456 | F8 2xx PRA | | request after F4. 457 |<--------------------| v 458 | | 459 | F9 2xx INV (no SDP) | <- The final response should not 460 |<--------------------| contain SDP. 461 | F10 ACK | 462 |-------------------->| 464 Figure 2: Example of Offer/Answer with 100rel Extension (2) 466 Note that in the case that the UAC needs to prompt the user to accept 467 or reject the offer, the reliable provisional response with SDP as an 468 offer (Pattern 4) can result in the retransmission until the PRACK 469 request can be sent. The UAC should take care to avoid this 470 situation when it sends the INVITE request without SDP. 472 3.2. Offer/Answer Exchange in Early Dialog 474 When both UAs support the 100rel extension, they can update the 475 session in the early dialog once the first offer/answer exchange has 476 been completed. 478 From a UA sending an INVITE request: 480 A UA can send an UPDATE request with a new offer if both ends support 481 the UPDATE method. Note that if the UAS needs to prompt the user to 482 accept or reject the offer, the delay can result in retransmission of 483 the UPDATE request. 485 A UA can send a PRACK request with a new offer only when 486 acknowledging the reliable provisional response carrying the answer 487 to an offer in the INVITE request. Compared to using the UPDATE 488 method, using PRACK can reduce the number of messages exchanged 489 between the UAs. However, to avoid problems or delays caused by 490 PRACK offer rejection, the UA is recommended to send a PRACK request 491 only when it has strong reasons to expect the receiver will accept 492 it. For example, the procedure used in precondition extension 493 [RFC3312] is a case where a PRACK request should be used for updating 494 the session status in an early dialog. Note also that if a UAS needs 495 to prompt the user to accept or reject the offer, the delay can 496 result in retransmission of the PRACK request. 498 From a UA receiving an INVITE request: 500 A UA can send an UPDATE request with a new offer if both ends support 501 the UPDATE method. A UAS can not send a new offer in the reliable 502 provisional response, so the UPDATE method is the only method for a 503 UAS to update an early session. 505 3.3. Offer/Answer Exchange in an Established Dialog 507 Both the re-INVITE and UPDATE methods can be used in an established 508 dialog to update the session. 510 The UPDATE method is simpler and can save at least one message 511 compared with the INVITE method. But both ends must support the 512 UPDATE method for it to be used. 514 The INVITE method needs at least three messages to complete but no 515 extensions are needed. Additionally, the INVITE method allows the 516 peer to take time to decide whether it will accept a session update 517 or not by sending provisional responses. That is, re-INVITE allows 518 the UAS to interact with the user at the peer, while UPDATE needs to 519 be answered automatically by the UAS. It is noted that re-INVITE 520 should be answered immediately unless such a user interaction is 521 needed. Otherwise, some 3pcc flows will break. 523 3.4. Recovering From a Failed ReINVITE 525 If a reINVITE fails, the session parameters in effect prior to the 526 reINVITE MUST remain unchanged, as if no re-INVITE had been issued. 527 ([RFC3261] section 14.1.) This remains the case even if multiple 528 offer/answer exchanges have occurred between the sending of the 529 reINVITE and its failure, and even if media has been exchanged using 530 the proposed changes in the session. Because this can be difficult 531 to achieve in practice, newer specifications call for the UAS to send 532 a 2xx response to a reINVITE in cases where rolling back changes 533 would be problematic. 535 Nevertheless, a UAC may receive a failure response to a reINVITE 536 after proposed changes that must be rolled back have already been 537 used. In such a case, the UAC should send an UPDATE offering the SDP 538 that has been reinstated. (See [I-D.camarillo-sipcore-reinvite] for 539 details.) 541 4. Exceptional Case Handling 543 In [RFC3264], the following restrictions are defined with regard to 544 sending a new offer. 546 "At any time, either agent MAY generate a new offer that updates 547 the session. However, it MUST NOT generate a new offer if it has 548 received an offer which it has not yet answered or rejected. It 549 MUST NOT generate a new offer if it has generated a prior offer 550 for which it has not yet received an answer or a rejection." 552 Assuming that the above rules are guaranteed, there seem to be two 553 possible 'exceptional' cases to be considered in SIP offer/answer 554 usage: the 'message crossing' case, and the 'glare' case. One of the 555 reasons why the usage of SIP methods to exchange offer/answer needs 556 to be carefully restricted in the RFCs is to ensure that the UA can 557 detect and handle appropriately the 'exceptional' cases to avoid 558 incompatible behavior. 560 4.1. Message Crossing Case Handling 562 When message packets cross in the transport network, an offer may be 563 received before the answer for the previous offer/answer exchange, as 564 shown in Figure 3. In such a case, UA A must detect that the session 565 description SDP-2 is not the answer to offer1. 567 A B 568 |SDP-1 (offer1)| 569 M1 |----------------->| 570 |SDP-2 (answer1)| 571 M2 |<------\ /-------| 572 | \/ | 573 |SDP-3 /\(offer2)| 574 M3 |<------/ \-------| 576 Figure 3: Message Crossing Case 578 Because of the restrictions on placement of offers and answers 579 (summarized in Table 1) there are a limited number of valid exchanges 580 of messages that may lead to this message crossing case. These are 581 enumerated in Table 3. (This table only shows messages containing 582 offers or answers. There could be other messages, without session 583 descriptions, which are not shown.) 585 When a response to UPDATE request crosses a reliable response to 586 INVITE request, there are variants shown in Figures 4 and 5, which 587 are dependent on an INVITE (Mx) that contains no offer. These are 588 also included in Table 3. 590 A B 591 | | 592 |SDP-1 offer1(UPD)| 593 M1 |==============================>| 594 |re-INV (no offer)| 595 Mx |------------------------------>| --+ 596 |SDP-2 answer1 (2xx-UPD)| | 597 M2 |<===========\ /===============| | first reliable 598 | \/ offer2| | response 599 |SDP-3 /\ (1xx-rel/2xx)| | 600 M3 |<===========/ \===============| <-+ 601 |SDP-4 answer2 (PRACK/ACK)| 602 My |------------------------------>| 603 | | 605 Figure 4: Avoidable message crossing cases 607 To avoid this message crossing condition shown in Figure 4, UA A 608 should not send this reINVITE request at this point. If UA B 609 encounters this message crossing condition, it should reject this 610 reINVITE request with a 500 response. 612 A B 613 | | 614 |re-INV (no offer)| 615 Mx |------------------------------>| --+ 616 |SDP-1 offer1(UPD)| | 617 M1 |==============================>| | 618 |SDP-2 answer1 (2xx-UPD)| | 619 M2 |<===========\ /===============| | first reliable 620 | \/ offer2| | response 621 |SDP-3 /\ (1xx-rel/2xx)| | 622 M3 |<===========/ \===============| <-+ 623 |SDP-4 answer2 (PRACK/ACK)| 624 My |------------------------------>| 625 | | 627 Figure 5: Avoidable message crossing cases 629 To avoid this message crossing condition shown in Figure 5, UA A 630 should not send this UPDATE request at this point. If UA B 631 encounters this message crossing condition, it should reject this 632 UPDATE request with a 500 response. 634 The situation when PRACK request crosses UPDATE request is shown in 635 Figure 6. 637 A B 638 | | 639 | re-INV (no offer)| 640 1st reliable+-- |<------------------------------| 641 response | M1|1xx-rel (offer1) | 642 +-> |==============================>| --+ 643 | answer1(PRA)| M3| Acknowledge 644 |<===========\ /===============| <-+ 645 | \/ | 646 | /\ offer2(UPD)| 647 |<===========/ \===============| M2 648 |500 (UPD) | 649 |------------------------------>| 650 |2xx-PRA | 651 |------------------------------>| 652 | | 654 Figure 6: Avoidable message crossing cases 656 To avoid the message crossing condition shown in Figure 6, UA B 657 should not send this UPDATE request at this point. If UA A 658 encounters this message crossing condition, it should reject this 659 UPDATE request with a 500 response. 661 The situation when a reliable provisional response to INVITE request 662 crosses UPDATE request is shown in Figure 7. 664 A B 665 | | 666 |re-INV (offer1) | 667 M1 |==============================>| 668 | answer1 (1xx-rel)| 669 |<===========\ /===============| M3 670 | \/ | 671 | /\ offer1(UPD)| 672 +-- |<===========/ \===============| M2 673 | |491 (UPD) | 674 Acknowledge | |------------------------------>| 675 | |PRACK | 676 +-> |------------------------------>| 677 | | 679 Figure 7: Avoidable message crossing cases 681 To avoid the message crossing condition shown in Figure 7, UA B 682 should not send this UPDATE request at this point. If UA A 683 encounters this message crossing condition, it should reject this 684 UPDATE request with a 491 response. 686 The situation when a 2xx response to INVITE request crosses UPDATE 687 request is shown in Figure 8. 689 A B 690 | | 691 |re-INV (offer1) | 692 |==============================>| 693 | answer1 (2xx)| 694 |<===========\ /===============| 695 | \/ | 696 | /\ offer1(UPD)| 697 +-- |<===========/ \===============| 698 | |491 (UPD) | 699 Acknowledge | |------------------------------>| 700 | |ACK | 701 +-> |------------------------------>| 702 | | 704 Figure 8: Avoidable message crossing cases 706 To avoid the message crossing condition shown in Figure 8, UA B 707 should not send this UPDATE request at this point. If UA A 708 encounters this message crossing condition, it should reject this 709 UPDATE request with a 491 response. 711 The situation when a response to UPDATE request crosses PRACK request 712 is shown in Figure 9. 714 A B 715 | | 716 | re-INV (offer0)| 717 |<------------------------------| 718 |1xx-rel (answer0) | 719 |------------------------------>| --+ 720 |offer1(UPD) | | 721 M1 |==============================>| | 722 | answer1 (2xx-UPD)| | Acknowledge 723 |<===========\ /===============| M3| 724 | \/ | | 725 | /\ offer2(PRA)| M2| 726 |<===========/ \===============| <-+ 727 | | 729 Figure 9: Avoidable message crossing case 731 To avoid the message crossing condition shown in Figure 9, UA A 732 should not send this UPDATE request at this point. If UA B 733 encounters this message crossing condition, it should reject this 734 UPDATE request with a 491 response. 736 Table 3 summarize this section. Each action is described in 737 Section 4.3. 739 | M1 | M3 | M2 |Action |Action |Figure| 740 |(offer1)|(answer1) |(offer2) | of A | of B | | 741 +--------+----------+-----------+-------+-------+------+ 742 | UPDATE | 2xx-UPD | UPDATE |UAS-UcU| | | 743 | | +-----------+ | - | | 744 | | | INVITE |UAS-UcI| | | 745 | | +-----------+-------+-------+------+ 746 | | | 1xx-INV | | | | 747 | | +-----------+UAC-UI,|UAS-UsI| 4,5 | 748 | | | 2xx-INV |UAC-IU |UAS-IsU| | 749 | | +-----------+-------+-------+------+ 750 | | | PRACK (*)|UAC-IU |UAS-IcU| 9 | 751 +--------+----------+-----------+-------+-------+------+ 752 | PRACK | 2xx-PRA | UPDATE |UAS-IcU| | | 753 +--------+----------+-----------+ | | | 754 | 2xx-INV| ACK | UPDATE |UAS-IsU| - | | 755 | | +-----------+ | | | 756 | | | INVITE |UAS-IsI| | | 757 +--------+----------+-----------+ +-------+------+ 758 | 1xx-rel| PRACK | UPDATE |UAS-IsU|UAC-IU | 6 | 759 +--------+----------+-----------+ | +------+ 760 | INVITE | 1xx-rel | UPDATE (*)|UAS-IcU|UAC-IU | 7 | 761 | +----------+-----------+ | +------+ 762 | | 2xx-INV | UPDATE (*)|UAS-IcU|UAC-IU | 8 | 763 +--------+----------+-----------+-------+-------+------+ 764 (*) invalid sequences if INVITE request is an initial one 766 Table 3: Offer / Answer Crossing Message Sequences 768 4.2. Glare Case Handling 770 When both ends in a dialog send a new offer at nearly the same time, 771 as described in Figure 10, a UA may receive a new offer before it 772 receives the answer to the offer it sent. This case is usually 773 called a 'glare' case. 775 A B 776 |offer1 offer2| 777 M1 |-------\ /-------| M2 778 | \/ | 779 | /\ | 780 |<------/ \------>| 782 Figure 10: Glare Case 784 When offer2 is in an UPDATE request or (re-)INVITE request, it must 785 be rejected with a 491 or 500 response. 787 There is a variant of Figure 7. When offer2 is in a PRACK request 788 (within the current rules, only possible if offer1 is in an UPDATE 789 request), as shown in Figure 11, UA A has a dilemma. 791 A B 792 | | 793 | re-INV (offer0)| 794 |<------------------------------| 795 |1xx-rel (answer0) | 796 |------------------------------>| --+ 797 |offer1(UPD) offer2(PRA)| M2| Acknowledge 798 M1 |============\ /===============| <-+ 799 | \/ | 800 | /\ | 801 |<===========/ \==============>| 802 | 491 (UPD)| 803 |<------------------------------| 804 | | 806 Figure 11: Avoidable glare case 808 All PRACKs are supposed to be accepted with 200 response, yet there 809 is no way to indicate the problem with a 200 response. At best it 810 could proceed on the assumption that its INVITE will be rejected with 811 a 491. To avoid this glare condition shown in Figure 11, UA A should 812 not send this UPDATE request at this point. If UA B encounters this 813 glare condition it should reject this UPDATE request with a 491 814 response. 816 Glare can also occur when offer2 is in a 1xx or 2xx response. This 817 is a variant of Figure 5, as shown in Figure 12. 819 A B 820 | | 821 |re-INV (no offer) | 822 |------------------------------>| --+ 1st reliable 823 |offer1(UPD) offer2| M2| response 824 M1 |============\ /===============| <-+ 825 | \/ (1xx-rel/2xx)| 826 | /\ | 827 |<===========/ \==============>| 828 | 500 (UPD)| 829 |<------------------------------| 830 | | 831 Figure 12: Avoidable glare case 833 To avoid this glare condition shown in Figure 12, UA A should not 834 send this UPDATE request at this point. If UA B encounters this 835 glare condition it should reject this UPDATE request with a 500 836 response. 838 There is a variant of Figure 4, as shown in Figure 13. 840 A B 841 | | 842 |offer1(UPD) | 843 |==========\ | 844 |re-INV \ | 845 |------------\----------------->| --+ 846 |(no offer) \ | |1st reliable 847 | \ offer2| | response 848 |<==============\===============| <-+ 849 | \ (1xx-rel/2xx)| 850 | \ | 851 | \===========>| 852 | 500 (UPD)| 853 |<------------------------------| 854 | | 856 Figure 13: Avoidable glare case 858 To avoid this glare condition shown in Figure 13, UA A should not 859 send this reINVITE request at this point. If UA B encounters this 860 glare condition it should reject this UPDATE request with a 500 861 response. 863 Table 4 summarize this section. Each action is described in 864 Section 4.3. 866 | offer1 | offer2 |Action |Action |Figure| 867 | M1 | M2 | of A | of B | | 868 +----------+----------+-------+-------+------+ 869 | | reINVITE |UAS-IcI|UAS-IcI| | 870 | reINVITE +----------+ | | | 871 | | UPDATE |UAS-IcU|UAS-UcI| | 872 +----------+----------+ | | | 873 | | UPDATE |UAS-UcU|UAS-UcU| | 874 | +----------+-------+ +------+ 875 | | 1xx-rel | | | | 876 | UPDATE +----------+UAC-IU,|UAS-IsU|12,13 | 877 | | 2xx-INV |UAC-UI | | | 878 | +----------+-------+ +------+ 879 | | PRACK (*)|UAC-IU |UAS-IcU| 11 | 880 +----------+----------+-------+-------+------+ 881 (*) invalid sequences if INVITE request is an initial one 883 Table 4: Offer / Answer Glare Message Sequences 885 4.3. Interworking of UPDATE and reINVITE 887 Almost all exceptional cases are caused by an interworking of UPDATE 888 and reINVITE. The interworking is described in Section 5 of 889 [RFC3311]. And UAC Behavior sending an UPDATE is described in 890 Section 5.1 of [RFC3311]. There are two concerns in this section, 891 1. It seems to describe different rules for each of initial INVITE 892 and reINVITE. But there is no particular reason why the rules 893 are separated. The lack of restrictions for sending a reINVITE 894 request cause a lot of the problems shown in Section 4.1. 895 2. It seems to describe that a UA may send an UPDATE request after 896 sending or receiving a PRACK request. But it should be "after 897 PRACK transaction is completed by 2xx response", because it 898 causes the message-crossing case shown in Figure 6 900 Since it is assumed that the language in this section itself is non- 901 normative and is justified as a corollary of 3261, we interpret it as 902 follows, 903 UAC-II: While an INVITE transaction is incomplete, a UA must not 904 send an another INVITE request. 905 UAC-UU: While an UPDATE transaction is incomplete, a UA must not 906 send an another UPDATE request. 908 UAC-UI: While an UPDATE transaction is incomplete, a UA should not 909 send a reINVITE request. 910 UAC-IU: While an INVITE transaction is incomplete and a PRACK 911 transaction associated with offer-answer is incomplete, a 912 UA should not send an UPDATE request. 914 UAS Behavior receiving an UPDATE is described in Section 5.2 of 915 [RFC3311]. There are two concerns in this section, 916 1. There are no description about the interworking of an UPDATE 917 request and an INVITE request without an offer. 918 2. There are no description about the interworking of an UPDATE 919 request and reliable response to INVITE with an offer. 921 We interpret this section as follows, 922 UAS-IcI: While an INVITE client transaction is incomplete, a UA must 923 reject an another INVITE request with a 491 response. 924 UAS-IsI: While an INVITE server transaction is incomplete, a UA must 925 reject an another INVITE request with a 500 response. 926 UAS-UcU: While an UPDATE client transaction is incomplete, a UA must 927 reject an another UPDATE request with a 491 response. 928 UAS-UsU: While an UPDATE server transaction is incomplete, a UA must 929 reject an another UPDATE request with a 500 response. 930 UAS-UcI: While an UPDATE client transaction is incomplete, a UA 931 should reject a reINVITE request with a 491 response. 932 UAS-UsI: While an UPDATE server transaction is incomplete, a UA 933 should reject a reINVITE request with a 500 response. 934 UAS-IcU: While an INVITE client transaction is incomplete, and a 935 PRACK transaction associated with offer-answer is 936 incomplete, a UA should reject an UPDATE request with a 491 937 response. 938 UAS-IsU: While an INVITE server transaction is incomplete, and a 939 PRACK transaction associated with offer-answer is 940 incomplete, a UA should reject an UPDATE request with a 500 941 response. 943 A B 944 | | 945 | UPDATE| 946 |<------------------------------| 947 |UPDATE | 948 |==============================>| 949 | 491| 950 |<==============================| 951 | | 953 Figure 14: Example of UAC-UU and UAS-UcU 955 A B 956 | | 957 |UPDATE CSeq:m | 958 |------------------------------>| 959 |UPDATE CSeq:n(>m) | 960 |==============================>| 961 | 500 (UPDATE CSeq:n)| 962 |<==============================| 963 | | 965 Figure 15: Example of UAC-UU and UAS-UsU 967 A B 968 | | 969 | UPDATE(offer1)| 970 |<------------------------------| 971 |reINVITE(no offer) | 972 |==============================>| 973 | 491 (INVITE)| 974 |<==============================| 975 | | 977 Figure 16: Example of UAC-UI and UAS-UcI 979 A B 980 | | 981 |UPDATE(offer1) | 982 |------------------------------>| 983 |reINVITE(no offer) | 984 |==============================>| 985 | 500 (INVITE)| 986 |<==============================| 987 | | 989 Figure 17: Example of UAC-UU and UAS-UsI 991 A B 992 | | 993 | reINVITE(no offer)| 994 |<------------------------------| 995 |1xx-rel(offer0) | 996 |------------------------------>| 997 |UPDATE(offer1) | 998 |==============================>| 999 | 491 (UPDATE)| 1000 |<==============================| 1001 | | 1003 Figure 18: Example of UAC-IU and UAS-IcU 1005 A B 1006 | | 1007 |reINVITE(no offer) | 1008 |------------------------------>| 1009 | 1xx-rel(offer0)| 1010 |<------------------------------| 1011 |UPDATE(offer1) | 1012 |==============================>| 1013 | 500 (UPDATE)| 1014 |<==============================| 1015 | | 1017 Figure 19: Example of UAC-IU and UAS-IsU 1019 In addition, it is assumed that the UPDATE request in this section 1020 include a offer. The interworking of a reINVITE and an UPDATE 1021 without an offer is out of scope for this document. 1023 5. Content of Offers and Answers 1025 While [RFC3264] and [RFC3312] give some guidance, questions remain 1026 about exactly what should be included in an offer or answer. This is 1027 especially a problem when the common "hold" feature has been 1028 activated, and when there is the potential for a multimedia call. 1030 Details of behavior depend on the capabilities and state of the User 1031 Agent. The kinds of recommendations that can be made are limited by 1032 the model of device capabilities and state that is presumed to exist. 1034 This section focuses on a few key aspects of offers and answers that 1035 have been identified as troublesome, and will consider other aspects 1036 to be out of scope. This section considers: 1038 o choice of supported media types and formats to include and exclude 1039 o hold and resume of media 1041 The following are out of scope for this document: 1042 o NAT traversal and ICE 1043 o specific codecs and their parameters 1044 o the negotiation of secure media streams 1045 o grouping of media streams 1046 o preconditions 1048 5.1. General Principle for Constructing Offers and Answers 1050 A UA should send an offer that indicates what it, and its user, are 1051 interested in using/doing at that time, without regard for what the 1052 other party in the call may have indicated previously. This is the 1053 case even when the offer is sent in response to an INVITE or re- 1054 INVITE that contains no offer. (However in the case of re-INVITE the 1055 constraints of [RFC3261] and [RFC3264] must be observed.) 1057 A UA should send an answer that includes as close an approximation to 1058 what the UA and its user are interested in doing at that time, while 1059 remaining consistent with the offer/answer rules of [RFC3264] and 1060 other RFCs. 1062 NOTE: "at that time" is important. The device may permit the user 1063 to configure which supported media are to be used by default. 1065 In some cases a UA may not have direct knowledge of what it is 1066 interested in doing at a particular time. If it is an intermediary 1067 it may be able to delegate the decision. In the worst case it may 1068 apply a default, such as assuming it wants to use all of its 1069 capabilities. 1071 5.2. Choice of Media Types and Formats to Include and Exclude 1073 5.2.1. Sending an Initial INVITE with Offer 1075 When a UAC sends an initial INVITE with an offer, it has complete 1076 freedom to choose which media type(s) and media format(s) (payload 1077 types in the case of RTP) it should include in the offer. 1079 The media types may be all or a subset of the media the UAC is 1080 capable of supporting, with the particular subset being determined by 1081 the design and configuration (e.g., via 1082 [I-D.ietf-sipping-config-framework]) of the UAC combined with input 1083 from the user interface of the UAC. 1085 The media formats may be all or a subset of the media formats the UAC 1086 is capable of supporting for the corresponding media type, with the 1087 particular subset being determined by the design and configuration of 1088 the UAC combined with input from the user interface of the UAC. 1090 Including all supported media formats will maximize the possibility 1091 that the other party will have a supported format in common. But 1092 including many can result in an unacceptably large SDP body. 1094 5.2.2. Responding with an Offer when the Initial INVITE has no Offer 1096 When a UAS has received an initial INVITE without an offer, it must 1097 include an offer in the first reliable response to the INVITE. It 1098 has largely the same options as when sending an initial INVITE with 1099 an offer, but there are some differences. The choice may be governed 1100 by both static (default) selections of media types as well as dynamic 1101 selections made by a user via interaction with the device while it is 1102 alerting. 1104 NOTE: The offer may be sent in a provisional response, before the 1105 user of the device has been alerted and had an opportunity to 1106 select media options for the call. In this case the UAS cannot 1107 include any call-specific options from the user of the device. If 1108 there is a possibility that the user of the device will wish to 1109 change what is offered before answering the call, then special 1110 care should be taken. If PRACK and UPDATE are supported by caller 1111 and callee then an initial offer can be sent reliably, and changed 1112 with an UPDATE if the user desires a change. If PRACK and UPDATE 1113 are not supported then the initial offer cannot be changed until 1114 the call is fully established. In that case either the offer 1115 should be delayed until the 200 is sent, or else the offer should 1116 include the minimum set of media the user is able to select. 1118 5.2.3. Answering an Initial INVITE with Offer 1120 When a UAS receives an initial INVITE with an offer, what media lines 1121 the answer may contain is constrained by [RFC3264]. The answer must 1122 contain the same number of m-lines as the offer, and they must 1123 contain the same media types. Each media line may be accepted, by 1124 including a non-zero port number, or rejected by including a zero 1125 port number in the answer. The media lines that are accepted should 1126 typically be those with types and formats the UAS would have included 1127 if it were the offerer. 1129 The media formats the answer may contain are constrained by 1130 [RFC3264]. For each accepted m-line in the answer, there must be at 1131 least one media format in common with the corresponding m-line of the 1132 offer. The UAS may also include other media formats it is able to 1133 support at this time. Doing so establishes an asymmetric media 1134 format situation, where these "other" media formats may only be sent 1135 from the offerer to the answerer. This asymmetric media situation is 1136 also limited because it cannot be sustained if there is a subsequent 1137 offer/answer exchange in the opposite direction. Also, there is 1138 limited value in including these other media formats because there is 1139 no assurance that the offerer will be able to use them. 1141 If the UAS does not wish to indicate support for any of the media 1142 types in a particular media line of the offer it must reject the 1143 corresponding media line, by setting the port number to zero. 1145 When the UAS wishes to reject all of the media lines in the offer, it 1146 may send a 488 failure response. Alternatively it may send a 1147 reliable non-failure response including all media lines with port 1148 numbers set to zero. 1150 5.2.4. Answering when the Initial INVITE had no Offer 1152 When a UAC has sent an initial INVITE without an offer, and then 1153 receives a response with the first offer, it should answer in the 1154 same way as a UAS receiving an initial INVITE with an offer. 1156 Because the offer arrives in a response to the INVITE, the UAC cannot 1157 reject the message containing the offer. If the UAC wishes to reject 1158 the entire offer, it must send a PRACK or ACK request including all 1159 the media lines with ports set to zero. Then, if it does not wish to 1160 continue the session it may send a CANCEL or BYE request to terminate 1161 the dialog. 1163 5.2.5. Subsequent Offers and Answers 1165 The guidelines above (Section 5.1 and Section 5.2.1 through 1166 Section 5.2.4) apply, but constraints in [RFC3264] must also be 1167 followed. The following are of particular note because they have 1168 proven troublesome: 1169 o The number of m-lines may not be reduced in a subsequent offer. 1170 Previously rejected media streams must remain, or be reused to 1171 offer the same or a different stream. (Section 6 of [RFC3264].) 1172 o In the o-line, only the version number may change, and if it 1173 changes it must increment by one from the one previously sent as 1174 an offer or answer. (Section 8 of [RFC3264].) If it doesn't 1175 change then the entire SDP body must be identical to what was 1176 previously sent as an offer or answer. Changing the o-line, 1177 except version number value, during the session is an error case. 1178 The behavior when receiving such a non-compliant offer/answer SDP 1179 body is implementation dependent. If a UA needs to negotiate a 1180 'new' SDP session, it should use the INVITE/Replaces method. 1182 o In the case of RTP, the mapping from a particular dynamic payload 1183 type number to a particular codec within that media stream 1184 (m-line) must not change for the duration of the session. 1185 (Section 8.3.2 of [RFC3264].) 1187 NOTE: This may be impossible for a B2BUA to follow in some 1188 cases (e.g. 3pcc transfer) if it does not terminate media. 1190 When the new offer is sent in response to an offerless (re)INVITE, it 1191 should be constructed according to the General Principle for 1192 Constructing Offers and Answers (Section 5.1 ): all codecs the UA is 1193 currently willing and able to use should be included, not just the 1194 ones that were negotiated by previous offer/answer exchanges. The 1195 same is true for media types - so if UA A initially offered audio and 1196 video to UA B, and they end up with only audio, and UA B sends an 1197 offerless (re)INVITE to UA A, A's resulting offer should most likely 1198 re-attempt video, by reusing the zeroed m-line used previously. 1200 NOTE: The behavior above is recommended, but it is not always 1201 achievable - for example in some interworking scenarios. Or, the 1202 offerer may simply not have enough resources to offer "everything" 1203 at that point. Even if the UAS is not able to offer any other SDP 1204 that the one currently being used, it should not reject the re- 1205 INVITE. Instead, it should generate an offer with the currently 1206 used SDP with o- line unchanged. 1208 5.3. Hold and Resume of media 1210 [RFC3264] specifies (using non-normative language) that "hold" should 1211 be indicated in an established session by sending a new offer 1212 containing "a=sendonly" for each media stream to be held. An 1213 answerer is then to respond with "a=recvonly" to acknowledge that the 1214 hold request has been understood. 1216 Note that the use of sendonly/recvonly is not limited to hold. These 1217 may be used for other reasons, such as devices that are only capable 1218 of sending or receiving. So receiving an offer with "a=sendonly" 1219 must not be treated as a certain indication that the offerer has 1220 placed the media stream on hold. 1222 This model is based on an assumption that the UA initiating the hold 1223 will want to play Music on Hold, which is not always the case. A UA 1224 may, if desired, initiate hold by offering "a=inactive" if it does 1225 not intend to transmit any media while in hold status. 1227 The rules of [RFC3264] constrain what may be in an answer when the 1228 offer contains "sendonly", "recvonly", or "inactive" in an a= line. 1229 But they do not constrain what must be in a subsequent offer. The 1230 General Principle for Constructing Offers and Answers (Section 5.1) 1231 is important here. The initiation of "hold" is a local action. It 1232 should reflect the desired state of the UA. It then affects what the 1233 UA includes in offers and answers until the local state is reset. 1235 The receipt of an offer containing "a=sendonly" or "a=inactive" and 1236 the sending of a compatible answer should not change the desired 1237 state of the recipient. However, a UA that has been "placed on hold" 1238 may itself desire to initiate its own hold status, based on local 1239 input. 1241 If UA2 has previously been "placed on hold" by UA1, via receipt of 1242 "a=sendonly", then it may initiate its own hold by sending a new 1243 offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will 1244 answer with "a=inactive" because that is the only valid answer that 1245 reflects its desire not to receive media. 1247 NOTE: Section 8.4 of [RFC3264] contains a conflicting 1248 recommendation that the offer contain "a=inactive" in this case. 1249 We interpret that recommendation to be non-normative. The use of 1250 "a=sendonly" in this case will never produce a worse outcome, and 1251 can produce a better outcome in useful cases. 1253 Once in this state, to resume a two way exchange of media each side 1254 must reset its local hold status. If UA1 is first to go off hold it 1255 will then send an offer with "a=sendrecv". The UA2 will respond with 1256 its desired state of "a=sendonly" because that is a permitted 1257 response. When UA2 desires to also resume, it will send an offer 1258 with "a=sendrecv". In this case, because UA1 has the same desire it 1259 will respond with "a=sendrecv". In the same case, when UA2 receives 1260 the offer with "a=sendrecv", if it has decided it wants to reset its 1261 local hold but has not yet signaled the intent, it may send 1262 "a=sendrecv" in the answer. 1264 If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive", 1265 and subsequently wants to initiate its own hold, also using 1266 "a=inactive", it need not send a new offer, since the only valid 1267 response is "a=inactive" and that is already in effect. However, its 1268 local desired state will now be either "inactive" or "a=sendonly". 1269 This affects what it will send in future offers and answers. 1271 If a UA has occasion to send another offer in the session, without 1272 any desire to change the hold status (e.g. in response to a re- 1273 INVITE without an offer, or when sending a re-INVITE to refresh the 1274 session timer) it should follow the General Principle for 1275 Constructing Offers and Answers (Section 5.1). If it previously 1276 initiated a "hold" by sending "a=sendonly" or "a=inactive" then it 1277 should offer that again. If it had not previously initiated "hold" 1278 then it should offer "a=sendrecv", even if it had previously been 1279 forced to answer something else. Without this behavior it is 1280 possible to get "stuck on hold" in some cases, especially when a 1281 third-party call controller is involved. 1283 5.4. Behavior on receiving SDP with c=0.0.0.0 1285 [RFC3264] specifies that an agent MUST be capable of receiving SDP 1286 with a connection address of 0.0.0.0, in which case it means that 1287 neither RTP nor RTCP should be sent to the peer. 1289 If a UA generates an answer to the offer received with "c=IN IP4 1290 0.0.0.0", the direction attribute of the accepted media stream in the 1291 answer must still be based on direction attribute of the offered 1292 stream and rules specified in [RFC3264] to form the direction a-line 1293 in the answer. There is no clear rule about the use of "c=IN IP4 1294 0.0.0.0" in the answer - it may be used or c-line with a valid IP 1295 address may be used. RTP/RTCP will not be sent toward an address of 1296 0.0.0.0 because it is an invalid address. 1298 6. IANA Considerations 1300 This document has no actions for IANA. 1302 7. Security Considerations 1304 There are not any security issues beyond the referenced RFCs. 1306 8. Acknowledgement 1308 The authors would like to thank Christer Holmberg, Rajeev Seth, 1309 Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo and 1310 Yang Gao for their thorough reviews and comments. Many of their 1311 suggestions and ideas have been incorporated in this document. Also, 1312 a big thank you to Sawada Takuya, who was first author of this 1313 document. 1315 9. References 1317 9.1. Normative References 1319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1320 Requirement Levels", BCP 14, RFC 2119, March 1997. 1322 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1323 A., Peterson, J., Sparks, R., Handley, M., and E. 1324 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1325 June 2002. 1327 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1328 Provisional Responses in Session Initiation Protocol 1329 (SIP)", RFC 3262, June 2002. 1331 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1332 with Session Description Protocol (SDP)", RFC 3264, 1333 June 2002. 1335 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1336 UPDATE Method", RFC 3311, October 2002. 1338 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 1339 "Integration of Resource Management and Session Initiation 1340 Protocol (SIP)", RFC 3312, October 2002. 1342 [I-D.camarillo-sipcore-reinvite] 1343 Camarillo, G., Holmberg, C., and G. yang, "Re-INVITE and 1344 Target-refresh Request Handling in the Session Initiation 1345 Protocol (SIP)", draft-camarillo-sipcore-reinvite-01 (work 1346 in progress), October 2009. 1348 9.2. Informative References 1350 [RFC3959] Camarillo, G., "The Early Session Disposition Type for the 1351 Session Initiation Protocol (SIP)", RFC 3959, 1352 December 2004. 1354 [I-D.ietf-sipping-config-framework] 1355 Channabasappa, S., "A Framework for Session Initiation 1356 Protocol User Agent Profile Delivery", 1357 draft-ietf-sipping-config-framework-17 (work in progress), 1358 February 2010. 1360 Authors' Addresses 1362 OKUMURA Shinji 1363 Softfront 1364 28-196, Noth9, West15, Chuo-ku 1365 Sapporo, Hokkaido 060-0009 1366 Japan 1368 Email: shinji.okumura@softfront.jp 1370 Paul H. Kyzivat 1371 Cisco Systems, Inc. 1372 1414 Massachusetts Avenue 1373 Boxborough, MA 01719 1374 USA 1376 Email: pkyzivat@cisco.com