idnits 2.17.1 draft-roach-mmusic-pof-pan-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3264, updated by this document, for RFC5378 checks: 2002-01-31) -- 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 (February 14, 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. B. Roach 3 Internet-Draft Mozilla 4 Updates: 3264 (if approved) S. Nandakumar 5 Intended status: Standards Track Cisco 6 Expires: August 18, 2014 February 14, 2014 8 Using Partial Offers and Partial Answers in a Multimedia Session 9 draft-roach-mmusic-pof-pan-02 11 Abstract 13 Whenever two hosts have the ability to set up and control a session 14 on a peer-to-peer basis, situations can arise in which both parties 15 attempt to change session parameters "at the same time," such that 16 the session control messages cross on the wire. When this happens, 17 implementations need to invoke extraordinary procedures to return the 18 shared state of the session to a common view between the endpoints. 20 For real-time communications, these session control messages are 21 typically exchanged using the session description protocol (SDP), 22 using an Offer/Answer model. This document expands the offer/answer 23 model to include the ability to exchange information relating to 24 discrete media streams within the session. By reducing the amount of 25 session data, the frequency of session state conflicts can be 26 reduced; and, for certain types of operations, conflicts can be 27 eliminated altogether. 29 This document updates RFC 3264. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 18, 2014. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Adding a Stream . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Changing a Stream . . . . . . . . . . . . . . . . . . . . 5 70 3.3. Removing a Stream . . . . . . . . . . . . . . . . . . . . 6 71 4. Use With Other Protocols . . . . . . . . . . . . . . . . . . 6 72 4.1. High-Level Sketch: Use With JSEP/WebRTC . . . . . . . . . 7 73 4.2. High-Level Sketch: Use With SIP . . . . . . . . . . . . . 7 74 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Common Procedures . . . . . . . . . . . . . . . . . . . . 8 76 5.2. Generating a Partial Offer . . . . . . . . . . . . . . . 8 77 5.3. Processing a Partial Offer . . . . . . . . . . . . . . . 10 78 5.4. Processing a Partial Answer . . . . . . . . . . . . . . . 12 79 5.5. Updating the Shared View of Session State . . . . . . . . 13 80 5.6. Receiving a Full Offer with a Partial Offer Pending . . . 13 81 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6.1. Adding Streams . . . . . . . . . . . . . . . . . . . . . 15 83 6.1.1. Full Offer/Answer Procedures . . . . . . . . . . . . 15 84 6.1.2. Partial Offer/Answer Procedures . . . . . . . . . . . 16 85 6.2. Removing Streams . . . . . . . . . . . . . . . . . . . . 19 86 6.2.1. Full Offer/Answer Procedures . . . . . . . . . . . . 19 87 6.2.2. Partial Offer/Answer Procedures . . . . . . . . . . . 20 88 6.3. Changing a Stream . . . . . . . . . . . . . . . . . . . . 22 89 6.3.1. Full Offer/Answer Procedures . . . . . . . . . . . . 22 90 6.3.2. Partial Offer/Answer Procedures . . . . . . . . . . . 23 91 6.4. Both Sides Simultaneously Add Streams . . . . . . . . . . 25 92 6.4.1. Full Offer/Answer Procedures . . . . . . . . . . . . 25 93 6.4.2. Partial Offer/Answer Procedures . . . . . . . . . . . 25 94 6.5. Removing a Stream with Pseudo-Glare . . . . . . . . . . . 28 95 6.5.1. Full Offer/Answer Procedures . . . . . . . . . . . . 28 96 6.5.2. Partial Offer/Answer Procedures . . . . . . . . . . . 28 97 6.6. Changing a Stream with Glare . . . . . . . . . . . . . . 31 98 6.6.1. Full Offer/Answer Procedures . . . . . . . . . . . . 31 99 6.6.2. Partial Offer/Answer Procedures . . . . . . . . . . . 31 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 104 9.2. Informative References . . . . . . . . . . . . . . . . . 33 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 107 1. Introduction 109 The SDP [RFC4566] offer/answer model defined in [RFC3264] briefly 110 mentions "glare" as a potential issue in the use of offer/answer 111 exchanges, although it relegates the problem to the "higher layer 112 protocol" to resolve. In SIP [RFC3261], resolving state after a 113 glare condition is performed via a timer-based back-off mechanism. 114 For WebRTC, detection of glare comes in the form of an 115 "InvalidStateError" exception. Actual resolution of glare is 116 currently undefined; the present assumption is that the applications 117 that make use of RTCWEB are responsible for handling glare in a 118 sensible fashion. 120 The penalty for glare isn't simply code complexity; it results in 121 delays in updating sessions state, which can end up visible to users, 122 leading to a less optimal user experience. 124 Many of the emerging uses for both SIP and RTCWEB involve sessions 125 with a large number of media streams (corresponding to a large number 126 of participants), with streams being added and removed frequently 127 (corresponding to arrival and departure of participants). This kind 128 of session churn increases the incidence of glare significantly. The 129 ability to signal group membership (e.g., BUNDLE and LS) for new and 130 changed media sections is of particular importance in these contexts. 132 To reduce the incidence of glare under these circumstances, this 133 document defines a procedure via which partial offer/answer exchanges 134 may take place. These exchanges operate on one or more media 135 sections at a time, rather than an entire SDP body. These operations 136 are defined in a way that can completely avoid glare for stream 137 additions and removals, and which reduces the chance of glare for 138 changes to active streams. This approach requires all media sections 139 to contain an "a=mid" [RFC5888] attribute. 141 This document focuses on the application of this technique for use in 142 RTCWEB and WebRTC. The author anticipates that future work will 143 describe its use in conjunction with SIP and SIP-derived technologies 144 (such as multiparty conferencing and telepresence). 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 3. Mechanism Overview 154 The core of this mechanism is the concept of "partial offers" and 155 "partial answers." Syntactically, these entities are SDP fragments, 156 consisting of exactly one o= line; one or more media sections; and 157 any i=, c=, b=, k=, and a= lines associated with the media sections. 158 They are formatted exactly as they would be if they were part of a 159 larger SDP document, with one key exception: unlike SDP, in an SDP 160 fragment, the ordering of media sections relative to each other is 161 not significant. Note that SDP fragments contain only that 162 information that pertains to media. Other than the mandatory o= 163 line, they never contain any session-level information. Within the 164 o= line, only the field is allowed to be changed from 165 its previous value. Any changes to session-level information other 166 than [RFC5888] group membership are expected to use a full offer/ 167 answer exchange rather than the partial offer/partial answer 168 mechanism defined by this document. 170 Further, the port numbers associated with an SDP BUNDLE MUST NOT be 171 changed using this mechanism. Due to their inherent inter-media- 172 section dependencies, such changes require the use of a full offer/ 173 answer exchange. 175 Using this mechanism has three key prerequisites: (1) all offer/ 176 answer exchanges in the session prior to sending a partial offer have 177 contained "a=mid" attributes for each media section; (2) both sides 178 are known to support the partial offer/answer technique (either 179 because they are part of a single domain of control, or because use 180 of this technique has been explicitly signaled); and (3) all partial 181 offers and partial answers are sent using a technique that guarantees 182 in-order and reliable delivery. 184 The use of an SDP fragment body will be explicitly signaled, e.g., 185 using a different MIME type for SIP, or using a different "type" 186 field for the WebRTC API. 188 3.1. Adding a Stream 190 To add a stream glarelessly, a party creates a "partial offer" 191 consisting of an o= line and one or more media sections, including 192 all of the corresponding i=, c=, b=, k=, and a= lines. Each media 193 section contains an "a=mid" attribute, indicating an MID that has not 194 yet been used in the session. 196 Upon receipt of a partial offer, an implementation processes each 197 media section independently. For each media section, the recipient 198 examines the MID in it. If the MID does not match any existing MID 199 in the session, then it represents a new media stream. Assuming the 200 recipient does not have an outstanding, unanswered partial offer that 201 also adds a stream, this new media section is simply appended to the 202 end of the existing session description, the SDP sess-version is 203 increased, and an answering media section is created. Once all 204 answering media sections have been processed, they are concatenated 205 into a partial answer. This partial answer consists of one or more 206 media sections, each containing an MID matching the one from the 207 partial offer. 209 If the recipient of a partial offer that contains a new MID has also 210 sent a partial offer adding a new stream to the session, then 211 ambiguity can arise regarding the canonical ordering of media 212 sections within the session description. In this situation, both 213 partial offer/answer exchanges are allowed to complete independently 214 (as no fundamental data glare has occurred). However, the order in 215 which they are appended to the session description is synchronized by 216 performing a lexical comparison among each media section's MID 217 attribute: the media sections are appended to the session in 218 lexically increasing order. 220 If the new stream needs to be added to an existing group, it does so 221 by using the "a=in-group" attribute defined in 222 [I-D.roach-mmusic-groupid], indicating the ID of a group that has 223 already been established within the session. If the new stream needs 224 to be added to a new group, then such a group may be created by 225 adding an "a=in-group" attribute that contains a group ID that is not 226 yet present in the session. In both cases, the session-level 227 membership of the group is semantically updated to reflect the new 228 member of the group (and, if necessary, the creation of a new group). 230 3.2. Changing a Stream 232 Partial offers may also be generated for modification of one or more 233 existing streams. In this case, the MID in the media section of a 234 partial offer will match an existing MID in the session description. 236 Upon receipt of a partial offer, an implementation examines the MID 237 of each media section in it. If the MID of any given media section 238 matches an existing MID in the session, then it represents a 239 modification to that media section. Assuming the recipient does not 240 have an outstanding, unanswered partial offer that also modifies that 241 exact same stream, this media section is treated as an independent 242 renegotiation of that stream. The SDP version is increased, and an 243 answering media section is created for inclusion in the resulting 244 partial answer. This media section for the partial answer has an MID 245 matching the one from the partial offer. 247 If the recipient of a partial offer that contains an existing MID has 248 also sent a partial offer to change that exact same stream, and 249 neither the received nor the sent partial offer contains a port 250 number of zero, then a legitimate glare condition has arisen. Normal 251 glare recovery procedures -- e.g., using a tie-breaker token or a 252 back-off timer -- must be engaged to resolve the conflict. 254 Implementors should note that changing more than one stream in a 255 single offer increases the chance of glare, thereby partially 256 negating the advantage of this protocol extension. The decision to 257 include more than one stream in a partial offer needs to be carefully 258 evaluated against this drawback. 260 3.3. Removing a Stream 262 To remove one or more a streams in a way that eliminates the chance 263 of glare, an implementation generates a new partial offer, containing 264 one or more media sections. Each media section contains an MID 265 matching the stream it wants to remove, and indicates a transport 266 port of zero, indicating that the stream is being deactivated. 268 If the recipient of a partial offer that contains an existing MID has 269 also sent a partial offer to change that exact same stream, and 270 either one of the received or the sent partial offer contains a port 271 number of zero, then the stream is deactivated. At this point, both 272 partial offers are discarded, the corresponding media section in the 273 session is modified by changing its port to zero, and a partial 274 answer is generated representing this single change. 276 4. Use With Other Protocols 278 Note that this document simply defines the extensions to the SDP 279 offer/answer model for dealing with partial offers and partial 280 answers. In the same way that [RFC3264] does not define specific 281 SIP, JSEP, or WebRTC handling, neither does this document. In order 282 for this technique to be useful, protocol-specific mechanisms need to 283 be defined. This additional work is left to appropriate venues, such 284 as the W3C WebRTC WG, the RTCWEB WG, and the SIPCORE WG. If the 285 higher-level protocol allows the use of unordered message delivery, 286 it is that protocol's responsibility to ensure that the result of 287 partial offer/partial answer exchanges is a shared and identical 288 session state between the parties involved. 290 To assist in understanding the mechanism being proposed, we describe, 291 in a very high-level and non-normative way, how this mechanism might 292 be applied to a couple of specific higher-level signaling systems. 294 4.1. High-Level Sketch: Use With JSEP/WebRTC 296 For WebRTC, we envision that such additional specification would add 297 a new constraint to createOffer, requesting that a partial offer be 298 generated (if possible). The resulting RTCSessionDescription would 299 contain only the media sections that have changed since the most 300 recent offer/answer exchange, and would have a type of 301 "partialOffer." When createAnswer is called after receipt of a 302 partialOffer, it would create a partialAnswer, containing only the 303 media sections referenced in the partial offer, that can be provided 304 to the remote party. 306 4.2. High-Level Sketch: Use With SIP 308 For SIP, partial offers and partial answers will likely be provided 309 in SIP UPDATE [RFC3311] or INFO [RFC6086] messages, containing a 310 special "application/sdpfrag" MIME type [I-D.ivov-dispatch-sdpfrag], 311 and a content-disposition that indicates that the contents are a 312 partial offer (rather than, say, a trickle ice candidate). Although 313 INVITE may seem like a natural fit for this kind of behavior, its 314 current definition includes strong glare resolution behaviors that 315 makes it unsuitable for this purpose. Naturally, any such mechanism 316 will be paired with a SIP feature tag that allows for negotiation of 317 support for partial offers and answers. 319 5. Protocol Operation 321 The following sections formally defines the procedures for generating 322 and processing partial offers and partial answers. 324 At any time during an ongoing session, either agent in the session 325 MAY generate a new partial offer that updates the session, subject to 326 the restrictions described in the following sections. However, it 327 MUST NOT generate a new partial offer if it has received any partial 328 or full offer which it has not yet answered or rejected. 330 An agent also MUST NOT generate a partial offer if it has sent a 331 partial or full offer which has not yet been accepted or rejected. 333 OPEN ISSUE: It seems like we might be able to have multiple 334 outstanding sent partial offers at once, as long as they don't try 335 to act on the same media section. The reason it's disallowed in 336 the above paragraph is that having several partial offers 337 potentially outstanding in both directions makes it very, very, 338 very complicated to resolve the ordering of media sections if 339 these partial offers in opposite directions overlap temporally. 341 In the situations described as "glare" below, the higher layer 342 protocol needs to provide a means for resolving such conditions. 343 This will generally be the same mechanism used to resolve the glare 344 conditions described in [RFC3264]. 346 5.1. Common Procedures 348 For all of the procedures described in the following sections, 349 whenever an o= line is included in a partial offer or partial answer, 350 its , , , , and values MUST be identical to those sent in the most recent 352 full offer or full answer generated by this agent for this session. 353 The value MUST be larger than the value in all 354 previously sent offers, partial offers, answers, and partial offers 355 generated by this agent for this session. 357 Whenever the procedures in the following sections indicate that a 358 media section is to be included in a partial offer or partial answer, 359 that media section MUST consist of an m= line along with all i=, c=, 360 b=, k=, and a= lines associated with that media section. If a line 361 is absent from a media section in a partial offer or partial answer, 362 it MUST be interpreted as an explicit removal of that value from the 363 media section. Recipients of such messages MUST NOT assume that a 364 previously-established but omitted value is still in effect. 366 5.2. Generating a Partial Offer 367 Whenever an agent wishes to change the state of the media in an 368 ongoing session -- whether through addition, modification, or removal 369 of a stream -- it does so through either an offer or a partial offer. 370 In deciding which to use, the implementation first verifies that it 371 has received positive confirmation that the remote implementation 372 supports the partial offer/partial answer mechanism. The means of 373 negotiating such support is left to the higher-level protocol that 374 makes use of the offer/answer model. The implementation then 375 verifies that all media sessions in the current session are 376 associated with unique MID values. Finally, the implementation 377 evaluates whether the changes it needs to make can be performed 378 exclusively using the values present in a media section, without any 379 modifications necessary to session-level values (except for the sess- 380 version value on the session-level o= line). 382 If all three of the criteria described above are true, then the 383 implementation MAY send a partial offer to make the changes it wants 384 to request. If any of these criteria are not true, then the 385 implementation MUST use a full offer, according to the procedures 386 described in [RFC3264]. 388 Once the agent determines that the change it wishes to make is 389 eligible to use the partial offer mechanism, it forms a new SDP 390 fragment by following these steps: 392 1. The agent creates a new partial offer consisting of one o=line 393 and any media section described in the following three steps. 395 2. For each media section to be changed, the agent creates a media 396 section to be included in the partial offer. This media section 397 MUST contain an "a=mid" attribute containing an MID that matches 398 the media section that is being modified. The media section also 399 contains the modifications that the agent wishes to make, as 400 described in section 8.3 of [RFC3264]. This media section MUST 401 contain "a=in-group" attributes [I-D.roach-mmusic-groupid] for 402 each group of which the media section is a member. 404 3. For each new media section to be added, the agent creates a new 405 media section to be added to the aforementioned partial offer. 406 This media section MUST contain an "a=mid" attribute, and the MID 407 present in this attribute MUST contain at least 120 bits of 408 randomness (e.g., 22 base-64 encoded characters, or 19 characters 409 selected randomly from the 79 valid token characters). The 410 remainder of the media section contains the various values that 411 the agent wishes to have associated with the corresponding media, 412 and is created according to the procedures described in section 413 5.1 or 5.2 of [RFC3264], as appropriate. The media section MUST 414 contain "a=in-group" attributes [I-D.roach-mmusic-groupid] for 415 every group of which the media section is a member. 417 4. For each existing media section to be removed, the agent creates 418 a new media section to be added to the aforementioned partial 419 offer. This media section MUST contain an "a=mid" attribute 420 containing an MID that matches the media section that is being 421 removed, and MUST contain a value of 0 (zero). Except for 422 the required "a=mid" attribute, this media section MAY omit any 423 or all i=, c=, b=, k=, and a= lines, and MAY list only one m= 424 line value. 426 Once the preceding steps have been followed to create a partial 427 offer, the agent makes use of the high-level signaling protocol to 428 convey the offer to the remote agent. 430 5.3. Processing a Partial Offer 432 Upon receipt of a partial offer, an agent first determines whether it 433 has sent any full offers for the corresponding session. If it has, 434 then the partial offer represents a glare condition that is resolved 435 via the higher-level protocol. It then verifies whether it has 436 received any partial or full offers to which it has not yet sent an 437 answer or a rejection. If so, then it rejects the partial offer as 438 invalid behavior. 440 The agent then examines the o= line in the received partial offer. 441 If the value is less than the most recently received 442 full (non-partial) offer or answer, then the partial offer is stale 443 and MUST be rejected. The means for rejecting the partial offer are 444 left to the higher-level protocol. 446 After such validation takes place, the agent iterates through each 447 media section and performs the following steps: 449 1. If the MID present in the received media section matches a media 450 section already present in the ongoing session and has a non-zero 451 port number, it represents a change to an existing media stream. 453 * If the MID matches the MID of a media section in a partial 454 offer that the agent has sent, AND the sent media section 455 contains a port number of zero, then the incoming partial 456 offer is rejected, as any such changes have been "overtaken by 457 events:" the stream will be deactivated momentarily. 459 * The recipient verifies that the MID does not match the MID of 460 any media section in any partial offers that it has sent but 461 has not yet received a partial answer or rejection for, unless 462 the media section in the sent partial offer has a port number 463 of zero. If this verification fails, then the received 464 partial offer represents a glare condition that is resolved 465 via the higher-level protocol. 467 * If the media section contains an "a=in-group:BUNDLE" 468 attribute, then the recipient verifies that the port number in 469 the media section is matches the port number of the other 470 sections in the bundle. If it does not, then the partial 471 offer is rejected. 473 * After the preceding verifications have succeeded, the agent 474 creates media section to include in the partial answer. To 475 reject the media section in the partial offer, the agent 476 generates a media section with a port number set to zero; 477 otherwise, the agent forms the media section by following the 478 procedures described in section 6.1 or 6.2 of [RFC3264], as 479 appropriate. 481 * Finally, the agent examines the "a=in-group" lines of the 482 changing media section. If the media section is currently in 483 any group that is not indicated in an "a=in-group" line, then 484 the media section is removed from that group. If an "a=in- 485 group" attribute indicates a group ID that does not yet exist, 486 then that group is created. If an "a=in-group" line indicates 487 a group that the media section is not yet in, then the media 488 section is added to that group. 490 2. If the MID present in the received media section matches a media 491 section already present in the ongoing session and has a port 492 number of zero, then it represents the removal of an existing 493 media stream. The agent creates a media section to include in 494 the partial answer. With the exception of the "a=mid" attribute, 495 this media section MAY omit any or all i=, c=, b=, k=, and a= 496 lines, and MAY indicate a single payload type. [RFC5888] group 497 membership information is adjusted to reflect removal of the 498 stream. 500 3. If the MID present in the received media section does not match 501 any media section already present in the ongoing session, then it 502 represents a new media stream. 504 * If the received media section contains a port number of zero, 505 then the recipient MUST reject the partial offer as invalid 506 behavior: this mechanism does not support the atomic addition 507 and removal of the same stream. 509 * If the above validation succeeds, the agent creates a media 510 section to include in the partial answer. To reject the media 511 section in the partial offer, the agent generates a media 512 section with a port number set to zero; otherwise, the agent 513 forms the media section by following the procedures described 514 in section 6.1 or 6.2 of [RFC3264], as appropriate. 516 * The agent also examines the "a=in-group" lines of the new 517 media section. If an "a=in-group" attribute indicates a group 518 ID that does not yet exist, then that group is created. The 519 new media section is then added to every group indicated in an 520 "a=in-group" attribute. If the media section contains an "a 521 =in-group:BUNDLE" attribute, then the recipient verifies that 522 the port number in the media section is matches the port 523 number of the other sections in the bundle. If it does not, 524 then the partial offer is rejected. 526 All media sections that are formed in the foregoing steps MUST 527 contain an "a=mid" attribute matching the MID that was present in the 528 corresponding media section from the partial offer. 530 If the preceding steps have been performed for each media section 531 without resulting in a rejection, then the agent forms a partial 532 answer consisting of a single o= line, and all of the media sections 533 that were generated as part of the preceding steps. Note that this 534 processing will always yield the same number of media sections in a 535 partial answer as were present in the partial offer. Unlike normal 536 SDP processing, however, the order of the media sections in a partial 537 answer is not significant. This partial answer is then sent to the 538 remote agent using the high-level protocol. 540 If the above processing results in a successful partial answer, then 541 the agent's view of the session is updated as described in 542 Section 5.5. 544 5.4. Processing a Partial Answer 546 When a partial answer is received, the offerer matches each media 547 section in the partial answer to its corresponding media section 548 according to its MID. The agent MUST NOT assume that the order of 549 the sections in the received partial answer matches the order of the 550 sections it sent in the partial offer. However, it can expect that 551 each section in the partial offer has a corresponding section in the 552 receive partial answer. 554 For each media section, the agent then updates its local view of 555 session state as described in Section 5.5, and follows the process 556 described in section 7 of [RFC3264]. 558 5.5. Updating the Shared View of Session State 560 Whenever a partial offer or answer is processed, the agent performs 561 the following steps to ensure that a common view of session state is 562 maintained: 564 1. The remote session's value is updated according to 565 the value received in the o= line of the sdpfrag. 567 2. Any changed or removed media sections are modified in-place. 568 Their position in the overall session description remains the 569 same as it was before. 571 3. If any partial offers (either sent or received) are still 572 pending, then the following step is skipped until after the 573 corresponding answer is sent or received (as appropriate). Any 574 new media sections are not applied to the session, and are 575 quarantined until that time. This avoids the need to re-index 576 media sections under the circumstances that the offer is 577 rejected. 579 4. Any added media sections are appended to the existing session. 580 The order in which they are appended is determined by lexically 581 sorting them according to their MID values. This is not 582 necessarily the same order in which they appear in the sdpfrag. 583 If the recipient of a partial offer had a sent a partial offer to 584 which it had not yet received a response when the partial offer 585 was received, then it must take additional steps to ensure a 586 common view of the media section ordering: the media sections for 587 the sent partial offer and the received partial answer are 588 treated as a single list, sorted lexically according to their 589 respective MID values, and appended to the session in that order. 590 When that agent receives the corresponding partial answer, the 591 media section ordering remains the same as was established by the 592 partial offer. 594 5.6. Receiving a Full Offer with a Partial Offer Pending 595 For completeness, this document notes that an agent that receives a 596 full offer with a sent partial offer pending is in a glare condition; 597 this is resolved via the higher-level protocol. 599 6. Examples 601 The SDP examples given in these examples deviate from actual on-the- 602 wire SDP notation in several ways. This is done to facilitate 603 readability and to conform to the restrictions imposed by the RFC 604 formatting rules. These deviations are as follows: 606 o Any line that is indented (compared to the initial line in the SDP 607 block) is a continuation of the preceding line. The line break 608 and indent are to be interpreted as a single space character. 610 o Empty lines in any SDP example are inserted to make functional 611 divisions in the SDP clearer, and are not actually part of the SDP 612 syntax. 614 o Excepting the above two conventions, line endings are to be 615 interpreted as pairs (that is, an ASCII 13 followed by an 616 ASCII 10). 618 o Any text starting with the string "//" to the end of the line is 619 inserted for the benefit of the reader, and is not actually part 620 of the SDP syntax. 622 For the use-cases that follow, a full Offer/Answer SDP is shown 623 followed by application of the procedures defined in this document to 624 generate Partial Offers and Answers in carrying out the use-case. 626 As a pre-condition, the SDP below represents the stable state of 627 system after a successful [RFC3264] Offer/Answer negotiation to setup 628 a communication session with one audio (G.711) and one video (VP8) 629 stream. 631 This SDP serves as base SDP for generating Offers/Partial Offers and 632 shall be terms as Base-SDP going forward. 634 v=0 635 o=- 20518 0 IN IP4 203.0.113.1 636 s= 637 t=0 0 638 c=IN IP4 203.0.113.2 639 a=ice-ufrag:F7gI 640 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 641 a=fingerprint:sha-1 642 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 644 m=audio 55400 RTP/SAVPF 0 645 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 646 a=rtpmap:0 PCMU/8000 647 a=sendrecv 648 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 649 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 651 m=video 55600 RTP/SAVPF 120 652 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 653 a=rtpmap:98 VP8/90000 654 a=sendrecv 655 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 656 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 658 6.1. Adding Streams 660 6.1.1. Full Offer/Answer Procedures 662 The following SDP shows an offer that adds an audio media section 663 with Opus codec to the Base-SDP: 665 v=0 666 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 667 s= 668 t=0 0 669 c=IN IP4 203.0.113.1 670 a=ice-ufrag:F7gI 671 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 672 a=fingerprint:sha-1 673 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 675 m=audio 55400 RTP/SAVPF 0 676 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 677 a=rtpmap:0 PCMU/8000 678 a=sendrecv 679 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 680 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 682 m=video 55600 RTP/SAVPF 120 683 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 684 a=rtpmap:120 VP8/90000 685 a=sendrecv 686 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 687 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 689 m=audio 55800 RTP/SAVPF 109 // New audio media line for opus 690 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 691 a=rtpmap:109 opus/48000/2 692 a=sendrecv 693 a=candidate:0 1 UDP 2113667327 203.0.113.2 55800 typ host 694 a=candidate:1 2 UDP 2113667326 203.0.113.2 55801 typ host 696 The following shows answer for the above Offer accepting the changes: 698 v=0 699 o=- 20518 1 IN IP4 198.51.100.2 // Version number is incremented 700 s= 701 t=0 0 702 c=IN IP4 203.0.113.2 703 a=ice-ufrag:c300d85b 704 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 705 a=fingerprint:sha-1 706 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 708 m=audio 60600 RTP/SAVPF 0 709 a=mid:4TOnU45h09BqsacSCyQwuFttyBkSFQGW 710 a=rtpmap:0 PCMU/8000 711 a=sendrecv 712 a=candidate:0 1 UDP 2113667327 192.0.2.2 60600 typ host 713 a=candidate:1 2 UDP 2113667326 192.0.2.2 60401 typ host 715 m=video 60602 RTP/SAVPF 120 716 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 717 a=rtpmap:120 VP8/90000 718 a=sendrecv 719 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 720 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 722 m=audio 60604 RTP/SAVPF 109 // New audio media line for Opus 723 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 724 a=rtpmap:109 opus/48000/2 725 a=sendrecv 726 a=candidate:0 1 UDP 2113667327 203.0.113.2 60604 typ host 727 a=candidate:1 2 UDP 2113667326 203.0.113.2 60605 typ host 729 6.1.2. Partial Offer/Answer Procedures 731 In order to add an audio media section with Opus codec the Offerer 732 generates the following Partial Offer: 734 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 735 m=audio 55800 RTP/SAVPF 109 // New audio media line for Opus 736 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 737 a=rtpmap:109 opus/48000/2 738 a=sendrecv 739 a=candidate:0 1 UDP 2113667327 203.0.113.2 55800 typ host 740 a=candidate:1 2 UDP 2113667326 203.0.113.2 55801 typ host 742 On receiving the above Partial Offer, the Answerer follows the 743 validations defined in the Section 5.3 to generate a Partial Answer. 744 Since the content of the "a=mid" attribute doesn't match any existing 745 values and the Port Number is non zero, thus generated Partial Answer 746 reflects accepting the new audio stream. 748 Below shows Partial Answer generated by the Answerer in response to 749 the above Partial Offer. 751 o=- 20518 1 IN IP4 198.51.100.2 752 m=audio 60604 RTP/SAVPF 109 // Answerer accepts the new media stream. 753 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 754 a=rtpmap:109 opus/48000/2 755 a=sendrecv 756 a=candidate:0 1 UDP 2113667327 203.0.113.2 60604 typ host 757 a=candidate:1 2 UDP 2113667326 203.0.113.2 60605 typ host 759 On successful Partial Offer/Answer exchange, the Offerer appends the 760 media section offered in the Partial Offer to its Base-SDP. Also 761 is updated as per o= line received. Updated SDP at 762 the Offerer is shown below. 764 v=0 765 o=- 20518 1 IN IP4 198.51.100.1 // Version number updated 766 s= 767 t=0 0 768 c=IN IP4 203.0.113.1 769 a=ice-ufrag:F7gI 770 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 771 a=fingerprint:sha-1 772 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 774 m=audio 55400 RTP/SAVPF 0 775 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 776 a=rtpmap:0 PCMU/8000 777 a=sendrecv 778 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 779 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 781 m=video 55600 RTP/SAVPF 120 782 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 783 a=rtpmap:120 VP8/90000 784 a=sendrecv 785 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 786 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 788 m=audio 55800 RTP/SAVPF 109 // Appended per Partial Offer 789 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 790 a=rtpmap:109 opus/48000/2 791 a=sendrecv 792 a=candidate:0 1 UDP 2113667327 203.0.113.2 55800 typ host 793 a=candidate:1 2 UDP 2113667326 203.0.113.2 55801 typ host 795 Identical steps are performed by the Answerer on the media section in 796 the Partial Answer as shown below. 798 v=0 799 o=- 20518 1 IN IP4 198.51.100.2 // Version number updated 800 s= 801 t=0 0 802 c=IN IP4 203.0.113.2 803 a=ice-ufrag:c300d85b 804 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 805 a=fingerprint:sha-1 806 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 808 m=audio 60600 RTP/SAVPF 0 809 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 810 a=rtpmap:0 PCMU/8000 811 a=sendrecv 812 a=candidate:0 1 UDP 2113667327 192.0.2.2 60600 typ host 813 a=candidate:1 2 UDP 2113667326 192.0.2.2 60601 typ host 815 m=video 60602 RTP/SAVPF 120 816 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 817 a=rtpmap:120 VP8/90000 818 a=sendrecv 819 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 820 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 822 m=audio 60604 RTP/SAVPF 109 // Appended per Partial Answer 823 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 824 a=rtpmap:109 opus/48000/2 825 a=sendrecv 826 a=candidate:0 1 UDP 2113667327 203.0.113.2 60604 typ host 827 a=candidate:1 2 UDP 2113667326 203.0.113.2 60605 typ host 829 6.2. Removing Streams 831 6.2.1. Full Offer/Answer Procedures 833 The following SDP shows an offer that removes the audio media section 834 with PCMU Codec from the Base-SDP: 836 v=0 837 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 838 s= 839 t=0 0 840 c=IN IP4 203.0.113.1 841 a=ice-ufrag:F7gI 842 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 843 a=fingerprint:sha-1 844 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 846 m=audio 0 RTP/SAVPF 0 // Port is set to zero. 847 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 848 a=rtpmap:0 PCMU/8000 849 a=sendrecv 850 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 851 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 853 m=video 55600 RTP/SAVPF 120 854 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 855 a=rtpmap:98 VP8/90000 856 a=sendrecv 857 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 858 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 860 The following shows answer for the above Offer accepting the changes: 862 v=0 863 o=- 20518 1 IN IP4 198.51.100.2 // Version number is incremented 864 s= 865 t=0 0 866 c=IN IP4 203.0.113.2 867 a=ice-ufrag:c300d85b 868 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 869 a=fingerprint:sha-1 870 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 872 m=audio 0 RTP/SAVPF 0 // Removal of stream is accepted 873 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 874 a=rtpmap:0 PCMU/8000 876 m=video 60602 RTP/SAVPF 120 877 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 878 a=rtpmap:120 VP8/90000 879 a=sendrecv 880 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 881 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 883 6.2.2. Partial Offer/Answer Procedures 885 In order to remove the audio media section from the Base-SDP the 886 Offerer generates the following Partial Offer: 888 o=- 20518 1 IN IP4 198.51.100.1 // Version number incremented 889 m=audio 0 RTP/SAVPF 0 // Port is set to zero 890 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW // mid attribute is included 891 a=rtpmap:0 PCMU/8000 893 On receiving the above Partial Offer, the Answerer follows the 894 validations defined in the Section 5.3 to generate a Partial Answer 895 that accepts the removal of the corresponding media section. 897 Below shows the Partial Answer generated by the Answerer in response 898 to the above Partial Offer. 900 o=- 20518 1 IN IP4 198.51.100.2 901 m=audio 0 RTP/SAVPF 0 // Removal of stream is accepted 902 a=mid:AOnU45h09BqsacSCyQwuFttyBkSFQGW 903 a=rtpmap:0 PCMU/8000 904 On successful Partial Offer/Answer exchange, the Offerer updates its 905 Base-SDP to reflect removing of the audio media stream. Also is updated as per o= line received. Updated SDP at the 907 Offerer is shown below. 909 v=0 910 o=- 20518 1 IN IP4 198.51.100.1 // Version number updated 911 s= 912 t=0 0 913 c=IN IP4 203.0.113.1 914 a=ice-ufrag:F7gI 915 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 916 a=fingerprint:sha-1 917 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 919 m=audio 0 RTP/SAVPF 0 // Port is updated to zero 920 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 921 a=rtpmap:0 PCMU/8000 923 m=video 55600 RTP/SAVPF 120 924 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 925 a=rtpmap:98 VP8/90000 926 a=sendrecv 927 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 928 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 930 Identical steps are performed by the Answerer on the media section in 931 the Partial Answer as shown below. 933 v=0 934 o=- 20518 1 IN IP4 198.51.100.2 // Version number updated 935 s= 936 t=0 0 937 c=IN IP4 203.0.113.2 938 a=ice-ufrag:c300d85b 939 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 940 a=fingerprint:sha-1 941 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 943 m=audio 0 RTP/SAVPF 0 // Port is updated to zero 944 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 945 a=rtpmap:0 PCMU/8000 947 m=video 60602 RTP/SAVPF 120 948 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 949 a=rtpmap:120 VP8/90000 950 a=sendrecv 951 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 952 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 954 6.3. Changing a Stream 956 6.3.1. Full Offer/Answer Procedures 958 The following SDP shows an offer that marks video stream as sendonly: 960 v=0 961 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 962 s= 963 t=0 0 964 c=IN IP4 203.0.113.1 965 a=ice-ufrag:F7gI 966 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 967 a=fingerprint:sha-1 968 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 970 m=audio 55400 RTP/SAVPF 0 971 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 972 a=rtpmap:0 PCMU/8000 973 a=sendrecv 974 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 975 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 977 m=video 55600 RTP/SAVPF 120 978 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 979 a=rtpmap:120 VP8/90000 980 a=sendonly // Video stream is marked as sendonly. 981 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 982 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 984 The following shows answer for the above Offer accepting the changes. 986 v=0 987 o=- 20518 1 IN IP4 198.51.100.2 // Version number is incremented 988 s= 989 t=0 0 990 c=IN IP4 203.0.113.2 991 a=ice-ufrag:c300d85b 992 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 993 a=fingerprint:sha-1 994 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 996 m=audio 60600 RTP/SAVPF 0 997 a=mid:AOnU45h09BqsacSCyQwuFttyBkSFQGW 998 a=rtpmap:0 PCMU/8000 999 a=sendrecv 1000 a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host 1001 a=candidate:1 2 UDP 2113667326 192.0.2.2 60401 typ host 1003 m=video 60602 RTP/SAVPF 120 1004 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1005 a=rtpmap:120 VP8/90000 1006 a=recvonly // Answerer accepts the change and marks 1007 // the stream as recvonly. 1008 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 1009 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 1011 6.3.2. Partial Offer/Answer Procedures 1013 In order to mark video stream as sendonly, an Partial Offer is 1014 generated: 1016 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 1017 m=video 55600 RTP/SAVPF 120 1018 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1019 a=rtpmap:120 VP8/90000 1020 a=sendonly // Video stream is marked as sednonly. 1021 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 1022 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 1024 Since the content of "a=mid" attribute in the Partial Offer matches, 1025 the Answerer generates an Partial Answer with media section 1026 corresponding to the video stream accepting the changes, as shown 1027 below. 1029 o=- 20518 1 IN IP4 198.51.100.2 1030 m=video 60602 RTP/SAVPF 120 1031 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1032 a=rtpmap:120 VP8/90000 1033 a=recvonly // Answerer accepts the change and marks 1034 // the stream as recvonly on the Answer. 1036 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 1037 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 1039 On successful Partial Offer/Answer exchange, the Offerer updates the 1040 video media section by changing the direction attribute to sendonly. 1041 Also is updated as per o= line received, 1043 v=0 1044 o=- 20518 1 IN IP4 198.51.100.1 // Version number updated 1045 s= 1046 t=0 0 1047 c=IN IP4 203.0.113.1 1048 a=ice-ufrag:F7gI 1049 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 1050 a=fingerprint:sha-1 1051 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 1053 m=audio 55400 RTP/SAVPF 0 1054 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1055 a=rtpmap:0 PCMU/8000 1056 a=sendrecv 1057 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 1058 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 1060 m=video 55600 RTP/SAVPF 120 1061 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1062 a=rtpmap:120 VP8/90000 1063 a=sendonly // direction updated as per Partial O/A exchange 1064 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 1065 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 1067 Identical steps are performed by the Answerer on the media section in 1068 the Partial Answer as shown below. 1070 v=0 1071 o=- 20518 1 IN IP4 198.51.100.2 // Version number updated 1072 s= 1073 t=0 0 1074 c=IN IP4 203.0.113.2 1075 a=ice-ufrag:c300d85b 1076 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 1077 a=fingerprint:sha-1 1078 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 1080 m=audio 60600 RTP/SAVPF 0 1081 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1082 a=rtpmap:0 PCMU/8000 1083 a=sendrecv 1084 a=candidate:0 1 UDP 2113667327 192.0.2.2 60400 typ host 1085 a=candidate:1 2 UDP 2113667326 192.0.2.2 60401 typ host 1087 m=video 60602 RTP/SAVPF 120 1088 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1089 a=rtpmap:120 VP8/90000 1090 a=recvonly // direction updated as per Partial O/A exchange 1091 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 1092 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 1094 6.4. Both Sides Simultaneously Add Streams 1096 Let Alice and Bob be the peers communicating.In this scenario both 1097 the parties attempt to add a new media stream at the same time. 1099 6.4.1. Full Offer/Answer Procedures 1101 This scenario results in the glare situation and should be resolved 1102 by the higher-level protocol. 1104 6.4.2. Partial Offer/Answer Procedures 1106 Alice sends a Partial Offer, shown below, to add an audio media 1107 section for Opus Codec. 1109 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 1110 m=audio 55800 RTP/SAVPF 109 // New audio media line for Opus 1111 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1112 a=rtpmap:109 opus/48000/2 1113 a=sendrecv 1114 a=candidate:0 1 UDP 2113667327 203.0.113.2 55800 typ host 1115 a=candidate:1 2 UDP 2113667326 203.0.113.2 55801 typ host 1117 At the same time, Bob sends the following Partial Offer to add an 1118 video media section for H.264 Codec. 1120 o=- 20518 1 IN IP4 198.51.100.2 // Version number is incremented 1121 m=video 60604 RTP/SAVPF 99 // New video media line for H.264 1122 a=mid:u1LS6AUZIugkXCT3S7aRFNEZOfUV18hT 1123 a=rtpmap:99 H264/90000 1124 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 1125 a=sendrecv 1126 a=candidate:2 1 UDP 2113667327 192.0.2.2 60604 typ host 1127 a=candidate:3 2 UDP 2113667326 192.0.2.2 60605 typ host 1129 On receiving the Partial Offer from Bob, Alice verifies from the 1130 content of "a=mid" value as an indication of new media being added. 1131 It generates the Partial Answer accepting Bob's request to add the 1132 new video stream. 1134 o=- 20518 1 IN IP4 198.51.100.1 1135 m=video 55900 RTP/SAVPF 99 // Alice accepts Bob's Partial Offer 1136 a=mid:u1LS6AUZIugkXCT3S7aRFNEZOfUV18hT // MID from Partial Offer 1137 a=rtpmap:99 H264/90000 1138 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 1139 a=sendrecv 1140 a=candidate:2 1 UDP 2113667327 192.0.2.2 55900 typ host 1141 a=candidate:3 2 UDP 2113667326 192.0.2.2 55901 typ host 1143 Symmetrically Bob carries out similar actions on Alice's Partial 1144 Offer and generates an Partial Answer as shown below. 1146 o=- 20518 1 IN IP4 198.51.100.2 1147 m=audio 60606 RTP/SAVPF 109 // Bob accepts Alice's Partial Offer 1148 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW // MID from Partial Offer 1149 a=rtpmap:109 opus/48000/2 1150 a=sendrecv 1151 a=candidate:0 1 UDP 2113667327 203.0.113.2 60606 typ host 1152 a=candidate:1 2 UDP 2113667326 203.0.113.2 60607 typ host 1154 On successful Partial Offer/Answer exchange, Alice appends to the 1155 Base-SDP, the two media sections that correspond to audio and video 1156 streams negotiated as part of aforementioned Partial Offer/Answer 1157 exchanges. Also is incremented to reflect the shared 1158 state. The media sections are appended in the lexically increasing 1159 order. 1161 v=0 1162 o=- 20518 2 IN IP4 198.51.100.1 // Version number updated 1163 s= 1164 t=0 0 1165 c=IN IP4 203.0.113.1 1166 a=ice-ufrag:F7gI 1167 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 1168 a=fingerprint:sha-1 1169 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 1171 m=audio 55400 RTP/SAVPF 0 1172 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1173 a=rtpmap:0 PCMU/8000 1174 a=sendrecv 1175 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 1176 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 1178 m=video 55600 RTP/SAVPF 120 1179 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1180 a=rtpmap:120 VP8/90000 1181 a=sendrecv 1182 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 1183 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 1185 m=audio 55800 RTP/SAVPF 109 // New audio media line for Opus 1186 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1187 a=rtpmap:109 opus/48000/2 1188 a=sendrecv 1189 a=candidate:0 1 UDP 2113667327 203.0.113.2 55800 typ host 1190 a=candidate:1 2 UDP 2113667326 203.0.113.2 55801 typ host 1192 m=video 55900 RTP/SAVPF 99 // Alice accepts Bob's Partial Offer 1193 a=mid:u1LS6AUZIugkXCT3S7aRFNEZOfUV18hT 1194 a=rtpmap:99 H264/90000 1195 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 1196 a=sendrecv 1197 a=candidate:2 1 UDP 2113667327 192.0.2.2 55900 typ host 1198 a=candidate:3 2 UDP 2113667326 192.0.2.2 55901 typ host 1200 Similarly, below SDP shows Bob's Base-SDP updated. 1202 v=0 1203 o=- 20518 2 IN IP4 198.51.100.2 // Version number updated 1204 s= 1205 t=0 0 1206 c=IN IP4 203.0.113.2 1207 a=ice-ufrag:c300d85b 1208 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 1209 a=fingerprint:sha-1 1210 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 1212 m=audio 60600 RTP/SAVPF 0 1213 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1214 a=rtpmap:0 PCMU/8000 1215 a=sendrecv 1216 a=candidate:0 1 UDP 2113667327 192.0.2.2 60600 typ host 1217 a=candidate:1 2 UDP 2113667326 192.0.2.2 60601 typ host 1219 m=video 60602 RTP/SAVPF 120 1220 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1221 a=rtpmap:120 VP8/90000 1222 a=sendrecv 1223 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 1224 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 1226 m=audio 60606 RTP/SAVPF 109 // Bob accepts Alice's Partial Offer 1227 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1228 a=rtpmap:109 opus/48000/2 1229 a=sendrecv 1230 a=candidate:0 1 UDP 2113667327 203.0.113.2 60606 typ host 1231 a=candidate:1 2 UDP 2113667326 203.0.113.2 60607 typ host 1233 m=video 60604 RTP/SAVPF 99 // New video media line for H.264 1234 a=mid:u1LS6AUZIugkXCT3S7aRFNEZOfUV18hT 1235 a=rtpmap:99 H264/90000 1236 a=fmtp:99 profile-level-id=4d0028;packetization-mode=1 1237 a=sendrecv 1238 a=candidate:2 1 UDP 2113667327 192.0.2.2 60604 typ host 1239 a=candidate:3 2 UDP 2113667326 192.0.2.2 60605 typ host 1241 6.5. Removing a Stream with Pseudo-Glare 1243 In this example, Alice attempts to change the direction of the video 1244 stream to recvonly and Bob attempts to de-activate the same video 1245 stream simultaneously. 1247 6.5.1. Full Offer/Answer Procedures 1249 This scenario results in the glare situation and should be resolved 1250 by the higher-level protocol. 1252 6.5.2. Partial Offer/Answer Procedures 1253 The term pseudo-glare signifies those scenarios wherein both parties 1254 attempt to operate on a stream at the same time, but the final 1255 session state can be unambiguously resolved by both sides without any 1256 further signaling. 1258 Such an scenario arises when one side tries to change a media section 1259 and simultaneously the other party attempts to remove that media 1260 section. 1262 Below represents the Partial Offer from Alice to change the direction 1263 attribute of the video section to recvonly. 1265 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 1266 m=video 55600 RTP/SAVPF 120 1267 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1268 a=rtpmap:120 VP8/90000 1269 a=recvonly // direction changed to recvonly 1270 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 1271 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 1273 At the same time, Bob sends the following Partial Offer to remove the 1274 same media section: 1276 o=- 20518 1 IN IP4 198.51.100.2 // Version number is incremented 1277 m=video 0 RTP/SAVPF 120 // Port number is set to 0. 1278 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1279 a=rtpmap:120 VP8/90000 1281 On validating the Partial Offer from Alice, Bob concludes the media 1282 section matches the one in the Partial Offer sent by him. By 1283 following the procedures in Section 5.3, Bob rejects Alice Partial 1284 Offer since the video media section will be disabled momentarily. 1286 Bob sends the Partial Answer by setting port number to zero as 1287 response to Alice's Partial Offer. 1289 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 1290 m=video 0 RTP/SAVPF 120 // Alice's Partial Offer rejected 1291 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1292 a=rtpmap:120 VP8/90000 1294 The processing by Alice is insignificant, because it will eventually 1295 be overtaken by Bob's rejection of her Partial Offer and thus the 1296 Partial Offer/Answer exchange concludes by removing the video 1297 section. 1299 Finally the Base-SDPs are updated by both the parties ending up in 1300 the shared state. 1302 // Alice's Base-SDP updated 1303 v=0 1304 o=- 20518 1 IN IP4 198.51.100.1 // Version number updated 1305 s= 1306 t=0 0 1307 c=IN IP4 203.0.113.1 1308 a=ice-ufrag:F7gI 1309 a=ice-pwd:x9cml/YzichV2+XlhiMu8g 1310 a=fingerprint:sha-1 1311 42:89:c5:c6:55:9d:6e:c8:e8:83:55:2a:39:f9:b6:eb:e9:a3:a9:e7 1313 m=audio 55400 RTP/SAVPF 0 1314 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1315 a=rtpmap:0 PCMU/8000 1316 a=sendrecv 1317 a=candidate:0 1 UDP 2113667327 203.0.113.2 55400 typ host 1318 a=candidate:1 2 UDP 2113667326 203.0.113.2 55401 typ host 1320 m=video 0 RTP/SAVPF 120 // Video stream removed 1321 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1322 a=rtpmap:120 VP8/90000 1323 a=sendrecv 1324 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 1325 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 1327 // Bob's Base-SDP 1328 v=0 1329 o=- 20518 1 IN IP4 198.51.100.2 // Version number updated. 1330 s= 1331 t=0 0 1332 c=IN IP4 203.0.113.2 1333 a=ice-ufrag:c300d85b 1334 a=ice-pwd:de4e99bd291c325921d5d47efbabd9a2 1335 a=fingerprint:sha-1 1336 91:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:03 1338 m=audio 60600 RTP/SAVPF 0 1339 a=mid:ATOnU45h09BqsacSCyQwuFttyBkSFQGW 1340 a=rtpmap:0 PCMU/8000 1341 a=sendrecv 1342 a=candidate:0 1 UDP 2113667327 192.0.2.2 60600 typ host 1343 a=candidate:1 2 UDP 2113667326 192.0.2.2 60601 typ host 1345 m=video 0 RTP/SAVPF 120 // Port is zero per Bob's Partial Offer 1346 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1347 a=rtpmap:120 VP8/90000 1348 a=sendrecv 1349 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 1350 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 1352 6.6. Changing a Stream with Glare 1354 In this example both Alice and Bob attempt to update the same media 1355 section that conflicts each others actions. 1357 6.6.1. Full Offer/Answer Procedures 1359 This scenario results in the glare situation and should be resolved 1360 by the higher-level protocol. 1362 6.6.2. Partial Offer/Answer Procedures 1364 To explain this scenario, say Alice attempts to update the video 1365 section's direction to be sendonly and Bob also attempts to perform 1366 the same action. 1368 This results in a conflict situation since both the parties can't 1369 have the same media section with sendonly direction, since it 1370 violates rules defined in [RFC3264] 1372 Partial Offer's generated by Alice and Bob for the above scenario is 1373 shown below. 1375 // Alice's Partial Offer 1376 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 1377 m=video 55600 RTP/SAVPF 120 1378 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1379 a=rtpmap:120 VP8/90000 1380 a=sendonly // direction changed to sendonly 1381 a=candidate:0 1 UDP 2113667327 203.0.113.2 55600 typ host 1382 a=candidate:1 2 UDP 2113667326 203.0.113.2 55601 typ host 1384 // Bob's Partial Offer 1385 o=- 20518 1 IN IP4 198.51.100.1 // Version number is incremented 1386 m=video 60602 RTP/SAVPF 120 1387 a=mid:0Ny4mOBV2MWTH1JYRRNORarcTbG11QxV 1388 a=rtpmap:120 VP8/90000 1389 a=sendonly // direction changed to sendonly 1390 a=candidate:2 1 UDP 2113667327 192.0.2.2 60602 typ host 1391 a=candidate:3 2 UDP 2113667326 192.0.2.2 60603 typ host 1393 This results in a glare situation under Partial Offer/Answer exchange 1394 due to the conflicting nature of the actions. To resolve this 1395 situation assistance from the higher level application protocol is 1396 required. 1398 7. Security Considerations 1400 TBD 1402 8. IANA Considerations 1404 TBD -- I don't think we actually need any for this mechanism. 1406 9. References 1408 9.1. Normative References 1410 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1411 Requirement Levels", BCP 14, RFC 2119, March 1997. 1413 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1414 A., Peterson, J., Sparks, R., Handley, M., and E. 1415 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1416 June 2002. 1418 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1419 with Session Description Protocol (SDP)", RFC 3264, June 1420 2002. 1422 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1423 Description Protocol", RFC 4566, July 2006. 1425 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1426 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1428 9.2. Informative References 1430 [I-D.ivov-dispatch-sdpfrag] 1431 Ivov, E. and A. Roach, "Internet Media Type application/ 1432 sdpfrag", draft-ivov-dispatch-sdpfrag-03 (work in 1433 progress), October 2013. 1435 [I-D.roach-mmusic-groupid] 1436 Roach, A. and M. Thomson, "An Extension for Identification 1437 of Groups in the Session Description Protocol (SDP).", 1438 draft-roach-mmusic-groupid-00 (work in progress), December 1439 2013. 1441 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 1442 UPDATE Method", RFC 3311, October 2002. 1444 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1445 Initiation Protocol (SIP) INFO Method and Package 1446 Framework", RFC 6086, January 2011. 1448 Authors' Addresses 1450 Adam Roach 1451 Mozilla 1452 Dallas, TX 1453 US 1455 Phone: +1 650 903 0800 x863 1456 Email: adam@nostrum.com 1458 Suhas Nandakumar 1459 Cisco 1460 170 West Tasman Drive 1461 San Jose, CA 95134 1462 USA 1464 Email: snandaku@cisco.com