idnits 2.17.1 draft-uberti-rtcweb-rfc8829bis-02.txt: -(4657): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4806): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. 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 == Line 3857 has weird spacing: '... mid a1...' == Line 3858 has weird spacing: '... attr candi...' == Line 3864 has weird spacing: '... mid a1...' == Line 3865 has weird spacing: '... attr candi...' == Line 3872 has weird spacing: '... mid a1...' == (11 more instances...) -- The document date (1 March 2022) is 786 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) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 8829 (Obsoleted by RFC 9429) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uberti 3 Internet-Draft Clubhouse 4 Obsoletes: 8829 (if approved) C. Jennings 5 Intended status: Standards Track Cisco 6 Expires: 2 September 2022 E. Rescorla, Ed. 7 Mozilla 8 1 March 2022 10 JavaScript Session Establishment Protocol (JSEP) 11 draft-uberti-rtcweb-rfc8829bis-02 13 Abstract 15 This document describes the mechanisms for allowing a JavaScript 16 application to control the signaling plane of a multimedia session 17 via the interface specified in the W3C RTCPeerConnection API and 18 discusses how this relates to existing signaling protocols. 20 This specification obsoletes RFC 8829. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 2 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 57 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 6 58 1.3. Changes from RFC 8829 . . . . . . . . . . . . . . . . . . 7 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 7 62 3.2. Session Descriptions and State Machine . . . . . . . . . 8 63 3.3. Session Description Format . . . . . . . . . . . . . . . 11 64 3.4. Session Description Control . . . . . . . . . . . . . . . 11 65 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 66 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 67 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 68 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 70 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 71 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 14 72 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 73 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 74 3.5.5. ICE Versions . . . . . . . . . . . . . . . . . . . . 16 75 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 76 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 17 77 3.6.2. Interpreting imageattr Attributes . . . . . . . . . . 17 78 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 19 79 3.8. Interactions with Forking . . . . . . . . . . . . . . . . 20 80 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 21 81 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 21 82 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 22 84 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 22 85 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 25 86 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 25 87 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 25 88 4.1.5. onaddtrack Event . . . . . . . . . . . . . . . . . . 25 89 4.1.6. createDataChannel . . . . . . . . . . . . . . . . . . 26 90 4.1.7. ondatachannel Event . . . . . . . . . . . . . . . . . 26 91 4.1.8. createOffer . . . . . . . . . . . . . . . . . . . . . 26 92 4.1.9. createAnswer . . . . . . . . . . . . . . . . . . . . 27 93 4.1.10. SessionDescriptionType . . . . . . . . . . . . . . . 28 94 4.1.10.1. Use of Provisional Answers . . . . . . . . . . . 29 95 4.1.10.2. Rollback . . . . . . . . . . . . . . . . . . . . 30 96 4.1.11. setLocalDescription . . . . . . . . . . . . . . . . . 30 97 4.1.12. setRemoteDescription . . . . . . . . . . . . . . . . 31 98 4.1.13. currentLocalDescription . . . . . . . . . . . . . . . 31 99 4.1.14. pendingLocalDescription . . . . . . . . . . . . . . . 31 100 4.1.15. currentRemoteDescription . . . . . . . . . . . . . . 32 101 4.1.16. pendingRemoteDescription . . . . . . . . . . . . . . 32 102 4.1.17. canTrickleIceCandidates . . . . . . . . . . . . . . . 32 103 4.1.18. setConfiguration . . . . . . . . . . . . . . . . . . 33 104 4.1.19. addIceCandidate . . . . . . . . . . . . . . . . . . . 34 105 4.1.20. onicecandidate Event . . . . . . . . . . . . . . . . 34 106 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 35 107 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 35 108 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 35 109 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 35 110 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 36 111 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 36 112 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 36 113 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 37 114 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 37 115 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 37 116 5.1.2. Profile Names and Interoperability . . . . . . . . . 37 117 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 39 118 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 39 119 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 45 120 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 49 121 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 49 122 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 49 123 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 50 124 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 50 125 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 56 126 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 58 127 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 58 128 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 58 129 5.5. Processing a Local Description . . . . . . . . . . . . . 59 130 5.6. Processing a Remote Description . . . . . . . . . . . . . 60 131 5.7. Processing a Rollback . . . . . . . . . . . . . . . . . . 60 132 5.8. Parsing a Session Description . . . . . . . . . . . . . . 61 133 5.8.1. Session-Level Parsing . . . . . . . . . . . . . . . . 62 134 5.8.2. Media Section Parsing . . . . . . . . . . . . . . . . 63 135 5.8.3. Semantics Verification . . . . . . . . . . . . . . . 66 136 5.9. Applying a Local Description . . . . . . . . . . . . . . 67 137 5.10. Applying a Remote Description . . . . . . . . . . . . . . 68 138 5.11. Applying an Answer . . . . . . . . . . . . . . . . . . . 72 139 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 75 140 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76 141 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 76 142 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 80 143 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 90 144 8. Security Considerations . . . . . . . . . . . . . . . . . . . 97 145 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 146 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 147 10.1. Normative References . . . . . . . . . . . . . . . . . . 97 148 10.2. Informative References . . . . . . . . . . . . . . . . . 102 149 Appendix A. SDP ABNF Syntax . . . . . . . . . . . . . . . . . . 104 150 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106 153 1. Introduction 155 This document describes how the W3C Web Real-Time Communication 156 (WebRTC) RTCPeerConnection interface [W3C.webrtc] is used to control 157 the setup, management, and teardown of a multimedia session. 159 1.1. General Design of JSEP 161 WebRTC call setup has been designed to focus on controlling the media 162 plane, leaving signaling-plane behavior up to the application as much 163 as possible. The rationale is that different applications may prefer 164 to use different protocols, such as the existing SIP call signaling 165 protocol, or something custom to the particular application, perhaps 166 for a novel use case. In this approach, the key information that 167 needs to be exchanged is the multimedia session description, which 168 specifies the transport and media configuration information necessary 169 to establish the media plane. 171 With these considerations in mind, this document describes the 172 JavaScript Session Establishment Protocol (JSEP), which allows for 173 full control of the signaling state machine from JavaScript. As 174 described above, JSEP assumes a model in which a JavaScript 175 application executes inside a runtime containing WebRTC APIs (the 176 "JSEP implementation"). The JSEP implementation is almost entirely 177 divorced from the core signaling flow, which is instead handled by 178 the JavaScript making use of two interfaces: (1) passing in local and 179 remote session descriptions and (2) interacting with the Interactive 180 Connectivity Establishment (ICE) state machine [RFC8445]. The 181 combination of the JSEP implementation and the JavaScript application 182 is referred to throughout this document as a "JSEP endpoint". 184 In this document, the use of JSEP is described as if it always occurs 185 between two JSEP endpoints. Note, though, that in many cases it will 186 actually be between a JSEP endpoint and some kind of server, such as 187 a gateway or Multipoint Control Unit (MCU). This distinction is 188 invisible to the JSEP endpoint; it just follows the instructions it 189 is given via the API. 191 JSEP's handling of session descriptions is simple and 192 straightforward. Whenever an offer/answer exchange is needed, the 193 initiating side creates an offer by calling a createOffer API. The 194 application then uses that offer to set up its local configuration 195 via the setLocalDescription API. The offer is finally sent off to 196 the remote side over its preferred signaling mechanism (e.g., 197 WebSockets); upon receipt of that offer, the remote party installs it 198 using the setRemoteDescription API. 200 To complete the offer/answer exchange, the remote party uses the 201 createAnswer API to generate an appropriate answer, applies it using 202 the setLocalDescription API, and sends the answer back to the 203 initiator over the signaling channel. When the initiator gets that 204 answer, it installs it using the setRemoteDescription API, and 205 initial setup is complete. This process can be repeated for 206 additional offer/answer exchanges. 208 Regarding ICE [RFC8445], JSEP decouples the ICE state machine from 209 the overall signaling state machine. The ICE state machine must 210 remain in the JSEP implementation because only the implementation has 211 the necessary knowledge of candidates and other transport 212 information. Performing this separation provides additional 213 flexibility in protocols that decouple session descriptions from 214 transport. For instance, in traditional SIP, each offer or answer is 215 self-contained, including both the session descriptions and the 216 transport information. However, [RFC8840] allows SIP to be used with 217 Trickle ICE [RFC8838], in which the session description can be sent 218 immediately and the transport information can be sent when available. 219 Sending transport information separately can allow for faster ICE and 220 DTLS startup, since ICE checks can start as soon as any transport 221 information is available rather than waiting for all of it. JSEP's 222 decoupling of the ICE and signaling state machines allows it to 223 accommodate either model. 225 Although it abstracts signaling, the JSEP approach requires that the 226 application be aware of the signaling process. While the application 227 does not need to understand the contents of session descriptions to 228 set up a call, the application must call the right APIs at the right 229 times, convert the session descriptions and ICE information into the 230 defined messages of its chosen signaling protocol, and perform the 231 reverse conversion on the messages it receives from the other side. 233 One way to make life easier for the application is to provide a 234 JavaScript library that hides this complexity from the developer; 235 said library would implement a given signaling protocol along with 236 its state machine and serialization code, presenting a higher-level 237 call-oriented interface to the application developer. For example, 238 libraries exist to provide implementations of the SIP [RFC3261] and 239 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] signaling 240 protocols atop the JSEP API. Thus, JSEP provides greater control for 241 the experienced developer without forcing any additional complexity 242 on the novice developer. 244 1.2. Other Approaches Considered 246 One approach that was considered instead of JSEP was to include a 247 lightweight signaling protocol. Instead of providing session 248 descriptions to the API, the API would produce and consume messages 249 from this protocol. While providing a more high-level API, this put 250 more control of signaling within the JSEP implementation, forcing it 251 to have to understand and handle concepts like signaling glare (see 252 [RFC3264], Section 4). 254 A second approach that was considered but not chosen was to decouple 255 the management of the media control objects from session 256 descriptions, instead offering APIs that would control each component 257 directly. This was rejected based on the argument that requiring 258 exposure of this level of complexity to the application programmer 259 would not be beneficial; it would (1) result in an API where even a 260 simple example would require a significant amount of code to 261 orchestrate all the needed interactions and (2) create a large API 262 surface that would need to be agreed upon and documented. In 263 addition, these API points could be called in any order, resulting in 264 a more complex set of interactions with the media subsystem than the 265 JSEP approach, which specifies how session descriptions are to be 266 evaluated and applied. 268 One variation on JSEP that was considered was to keep the basic 269 session-description-oriented API but to move the mechanism for 270 generating offers and answers out of the JSEP implementation. 271 Instead of providing createOffer/createAnswer methods within the 272 implementation, this approach would instead expose a getCapabilities 273 API, which would provide the application with the information it 274 needed in order to generate its own session descriptions. This 275 increases the amount of work that the application needs to do; it 276 needs to know how to generate session descriptions from capabilities, 277 and especially how to generate the correct answer from an arbitrary 278 offer and the supported capabilities. While this could certainly be 279 addressed by using a library like the one mentioned above, it 280 basically forces the use of said library even for a simple example. 281 Providing createOffer/createAnswer avoids this problem. 283 1.3. Changes from RFC 8829 285 When [RFC8829] was published, inconsistencies regarding BUNDLE 286 [RFC9143] operation were identified with regard to both the 287 specification text as well as implementation behavior. The former 288 concern was addressed via an update to [RFC9143]. For the latter 289 concern, it was observed that some implementations implemented the 290 "max-bundle" bundle policy defined in [RFC8829] by assuming that 291 bundling had already been negotiated, rather than marking "m=" 292 sections as bundle-only as indicated by the specification. In order 293 to prevent unexpected changes to applications relying on the pre- 294 standard behavior, the decision was made to deprecate "max-bundle" 295 and instead introduce an identically defined "must-bundle" policy 296 that, when selected, provides the behavior originally specified by 297 [RFC8829]. 299 2. Terminology 301 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 302 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 303 "OPTIONAL" in this document are to be interpreted as described in 304 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 305 capitals, as shown here. 307 3. Semantics and Syntax 309 3.1. Signaling Model 311 JSEP does not specify a particular signaling model or state machine, 312 other than the generic need to exchange session descriptions in the 313 fashion described by [RFC3264] (offer/answer) in order for both sides 314 of the session to know how to conduct the session. JSEP provides 315 mechanisms to create offers and answers, as well as to apply them to 316 a session. However, the JSEP implementation is totally decoupled 317 from the actual mechanism by which these offers and answers are 318 communicated to the remote side, including addressing, 319 retransmission, forking, and glare handling. These issues are left 320 entirely up to the application; the application has complete control 321 over which offers and answers get handed to the implementation, and 322 when. 324 +-----------+ +-----------+ 325 | Web App |<--- App-Specific Signaling -->| Web App | 326 +-----------+ +-----------+ 327 ^ ^ 328 | SDP | SDP 329 V V 330 +-----------+ +-----------+ 331 | JSEP |<----------- Media ------------>| JSEP | 332 | Impl. | | Impl. | 333 +-----------+ +-----------+ 335 Figure 1: JSEP Signaling Model 337 3.2. Session Descriptions and State Machine 339 In order to establish the media plane, the JSEP implementation needs 340 specific parameters to indicate what to transmit to the remote side, 341 as well as how to handle the media that is received. These 342 parameters are determined by the exchange of session descriptions in 343 offers and answers, and there are certain details to this process 344 that must be handled in the JSEP APIs. 346 Whether a session description applies to the local side or the remote 347 side affects the meaning of that description. For example, the list 348 of codecs sent to a remote party indicates what the local side is 349 willing to receive, which, when intersected with the set of codecs 350 the remote side supports, specifies what the remote side should send. 351 However, not all parameters follow this rule; some parameters are 352 declarative, and the remote side must either accept them or reject 353 them altogether. An example of such a parameter is the TLS 354 fingerprints [RFC8122] as used in the context of DTLS [RFC6347]; 355 these fingerprints are calculated based on the local certificate(s) 356 offered and are not subject to negotiation. 358 In addition, various RFCs put different conditions on the format of 359 offers versus answers. For example, an offer may propose an 360 arbitrary number of "m=" sections (i.e., media descriptions as 361 described in [RFC4566], Section 5.14), but an answer must contain the 362 exact same number as the offer. 364 Lastly, while the exact media parameters are known only after an 365 offer and an answer have been exchanged, the offerer may receive ICE 366 checks, and possibly media (e.g., in the case of a re-offer after a 367 connection has been established) before it receives an answer. To 368 properly process incoming media in this case, the offerer's media 369 handler must be aware of the details of the offer before the answer 370 arrives. 372 Therefore, in order to handle session descriptions properly, the JSEP 373 implementation needs: 375 1. To know if a session description pertains to the local or remote 376 side. 378 2. To know if a session description is an offer or an answer. 380 3. To allow the offer to be specified independently of the answer. 382 JSEP addresses this by adding both setLocalDescription and 383 setRemoteDescription methods and having session description objects 384 contain a type field indicating the type of session description being 385 supplied. This satisfies the requirements listed above for both the 386 offerer, who first calls setLocalDescription(sdp [offer]) and then 387 later setRemoteDescription(sdp [answer]), and the answerer, who first 388 calls setRemoteDescription(sdp [offer]) and then later 389 setLocalDescription(sdp [answer]). 391 During the offer/answer exchange, the outstanding offer is considered 392 to be "pending" at the offerer and the answerer, as it may be either 393 accepted or rejected. If this is a re-offer, each side will also 394 have "current" local and remote descriptions, which reflect the 395 result of the last offer/answer exchange. Sections 4.1.14, 4.1.16, 396 4.1.13, and 4.1.15 provide more detail on pending and current 397 descriptions. 399 JSEP also allows for an answer to be treated as provisional by the 400 application. Provisional answers provide a way for an answerer to 401 communicate initial session parameters back to the offerer, in order 402 to allow the session to begin, while allowing a final answer to be 403 specified later. This concept of a final answer is important to the 404 offer/answer model; when such an answer is received, any extra 405 resources allocated by the caller can be released, now that the exact 406 session configuration is known. These "resources" can include things 407 like extra ICE components, Traversal Using Relays around NAT (TURN) 408 candidates, or video decoders. Provisional answers, on the other 409 hand, do no such deallocation; as a result, multiple dissimilar 410 provisional answers, with their own codec choices, transport 411 parameters, etc., can be received and applied during call setup. 412 Note that the final answer itself may be different than any received 413 provisional answers. 415 In [RFC3264], the constraint at the signaling level is that only one 416 offer can be outstanding for a given session, but at the JSEP level, 417 a new offer can be generated at any point. For example, when using 418 SIP for signaling, if one offer is sent and is then canceled using a 419 SIP CANCEL, another offer can be generated even though no answer was 420 received for the first offer. To support this, the JSEP media layer 421 can provide an offer via the createOffer method whenever the 422 JavaScript application needs one for the signaling. The answerer can 423 send back zero or more provisional answers and then finally end the 424 offer/answer exchange by sending a final answer. The state machine 425 for this is as follows: 427 setRemote(OFFER) setLocal(PRANSWER) 428 /-----\ /-----\ 429 | | | | 430 v | v | 431 +---------------+ | +---------------+ | 432 | |----/ | |----/ 433 | have- | setLocal(PRANSWER) | have- | 434 | remote-offer |------------------- >| local-pranswer| 435 | | | | 436 | | | | 437 +---------------+ +---------------+ 438 ^ | | 439 | | setLocal(ANSWER) | 440 setRemote(OFFER) | | 441 | V setLocal(ANSWER) | 442 +---------------+ | 443 | | | 444 | |<---------------------------+ 445 | stable | 446 | |<---------------------------+ 447 | | | 448 +---------------+ setRemote(ANSWER) | 449 ^ | | 450 | | setLocal(OFFER) | 451 setRemote(ANSWER) | | 452 | V | 453 +---------------+ +---------------+ 454 | | | | 455 | have- | setRemote(PRANSWER) |have- | 456 | local-offer |------------------- >|remote-pranswer| 457 | | | | 458 | |----\ | |----\ 459 +---------------+ | +---------------+ | 460 ^ | ^ | 461 | | | | 462 \-----/ \-----/ 463 setLocal(OFFER) setRemote(PRANSWER) 465 Figure 2: JSEP State Machine 467 Aside from these state transitions, there is no other difference 468 between the handling of provisional ("pranswer") and final ("answer") 469 answers. 471 3.3. Session Description Format 473 JSEP's session descriptions use Session Description Protocol (SDP) 474 syntax for their internal representation. While this format is not 475 optimal for manipulation from JavaScript, it is widely accepted and 476 is frequently updated with new features; any alternate encoding of 477 session descriptions would have to keep pace with the changes to SDP, 478 at least until the time that this new encoding eclipsed SDP in 479 popularity. 481 However, to provide for future flexibility, the SDP syntax is 482 encapsulated within a SessionDescription object, which can be 483 constructed from SDP and be serialized out to SDP. If future 484 specifications agree on a JSON format for session descriptions, we 485 could easily enable this object to generate and consume that JSON. 487 As detailed below, most applications should be able to treat the 488 SessionDescriptions produced and consumed by these various API calls 489 as opaque blobs; that is, the application will not need to read or 490 change them. 492 3.4. Session Description Control 494 In order to give the application control over various common session 495 parameters, JSEP provides control surfaces that tell the JSEP 496 implementation how to generate session descriptions. This avoids the 497 need for JavaScript to modify session descriptions in most cases. 499 Changes to these objects result in changes to the session 500 descriptions generated by subsequent createOffer/createAnswer calls. 502 3.4.1. RtpTransceivers 504 RtpTransceivers allow the application to control the RTP media 505 associated with one "m=" section. Each RtpTransceiver has an 506 RtpSender and an RtpReceiver, which an application can use to control 507 the sending and receiving of RTP media. The application may also 508 modify the RtpTransceiver directly, for instance, by stopping it. 510 RtpTransceivers generally have a 1:1 mapping with "m=" sections, 511 although there may be more RtpTransceivers than "m=" sections when 512 RtpTransceivers are created but not yet associated with an "m=" 513 section, or if RtpTransceivers have been stopped and disassociated 514 from "m=" sections. An RtpTransceiver is said to be associated with 515 an "m=" section if its media identification (mid) property is non- 516 null; otherwise, it is said to be disassociated. The associated "m=" 517 section is determined using a mapping between transceivers and "m=" 518 section indices, formed when creating an offer or applying a remote 519 offer. 521 An RtpTransceiver is never associated with more than one "m=" 522 section, and once a session description is applied, an "m=" section 523 is always associated with exactly one RtpTransceiver. However, in 524 certain cases where an "m=" section has been rejected, as discussed 525 in Section 5.2.2 below, that "m=" section will be "recycled" and 526 associated with a new RtpTransceiver with a new MID value. 528 RtpTransceivers can be created explicitly by the application or 529 implicitly by calling setRemoteDescription with an offer that adds 530 new "m=" sections. 532 3.4.2. RtpSenders 534 RtpSenders allow the application to control how RTP media is sent. 535 An RtpSender is conceptually responsible for the outgoing RTP 536 stream(s) described by an "m=" section. This includes encoding the 537 attached MediaStreamTrack, sending RTP media packets, and generating/ 538 processing the RTP Control Protocol (RTCP) for the outgoing RTP 539 streams(s). 541 3.4.3. RtpReceivers 543 RtpReceivers allow the application to inspect how RTP media is 544 received. An RtpReceiver is conceptually responsible for the 545 incoming RTP stream(s) described by an "m=" section. This includes 546 processing received RTP media packets, decoding the incoming 547 stream(s) to produce a remote MediaStreamTrack, and generating/ 548 processing RTCP for the incoming RTP stream(s). 550 3.5. ICE 552 3.5.1. ICE Gathering Overview 554 JSEP gathers ICE candidates as needed by the application. Collection 555 of ICE candidates is referred to as a gathering phase, and this is 556 triggered either by the addition of a new or recycled "m=" section to 557 the local session description or by new ICE credentials in the 558 description, indicating an ICE restart. Use of new ICE credentials 559 can be triggered explicitly by the application or implicitly by the 560 JSEP implementation in response to changes in the ICE configuration. 562 When the ICE configuration changes in a way that requires a new 563 gathering phase, a 'needs-ice-restart' bit is set. When this bit is 564 set, calls to the createOffer API will generate new ICE credentials. 565 This bit is cleared by a call to the setLocalDescription API with new 566 ICE credentials from either an offer or an answer, i.e., from either 567 a locally or remotely initiated ICE restart. 569 When a new gathering phase starts, the ICE agent will notify the 570 application that gathering is occurring through a state change event. 571 Then, when each new ICE candidate becomes available, the ICE agent 572 will supply it to the application via an onicecandidate event; these 573 candidates will also automatically be added to the current and/or 574 pending local session description. Finally, when all candidates have 575 been gathered, a final onicecandidate event will be dispatched to 576 signal that the gathering process is complete. 578 Note that gathering phases only gather the candidates needed by 579 new/recycled/restarting "m=" sections; other "m=" sections continue 580 to use their existing candidates. Also, if an "m=" section is 581 bundled (either by a successful bundle negotiation or by being marked 582 as bundle-only), then candidates will be gathered and exchanged for 583 that "m=" section if and only if its MID item is a BUNDLE-tag, as 584 described in [RFC9143]. 586 3.5.2. ICE Candidate Trickling 588 Candidate trickling is a technique through which a caller may 589 incrementally provide candidates to the callee after the initial 590 offer has been dispatched; the semantics of "Trickle ICE" are defined 591 in [RFC8838]. This process allows the callee to begin acting upon 592 the call and setting up the ICE (and perhaps DTLS) connections 593 immediately, without having to wait for the caller to gather all 594 possible candidates. This results in faster media setup in cases 595 where gathering is not performed prior to initiating the call. 597 JSEP supports optional candidate trickling by providing APIs, as 598 described above, that provide control and feedback on the ICE 599 candidate gathering process. Applications that support candidate 600 trickling can send the initial offer immediately and send individual 601 candidates when they get notified of a new candidate; applications 602 that do not support this feature can simply wait for the indication 603 that gathering is complete, and then create and send their offer, 604 with all the candidates, at that time. 606 Upon receipt of trickled candidates, the receiving application will 607 supply them to its ICE agent. This triggers the ICE agent to start 608 using the new remote candidates for connectivity checks. 610 3.5.2.1. ICE Candidate Format 612 In JSEP, ICE candidates are abstracted by an IceCandidate object, and 613 as with session descriptions, SDP syntax is used for the internal 614 representation. 616 The candidate details are specified in an IceCandidate field, using 617 the same SDP syntax as the "candidate-attribute" field defined in 618 [RFC8839], Section 5.1. Note that this field does not contain an 619 "a=" prefix, as indicated in the following example: 621 candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host 623 The IceCandidate object contains a field to indicate which ICE 624 username fragment (ufrag) it is associated with, as defined in 625 [RFC8839], Section 5.4. This value is used to determine which 626 session description (and thereby which gathering phase) this 627 IceCandidate belongs to, which helps resolve ambiguities during ICE 628 restarts. If this field is absent in a received IceCandidate 629 (perhaps when communicating with a non-JSEP endpoint), the most 630 recently received session description is assumed. 632 The IceCandidate object also contains fields to indicate which "m=" 633 section it is associated with, which can be identified in one of two 634 ways: either by an "m=" section index or by a MID. The "m=" section 635 index is a zero-based index, with index N referring to the N+1th "m=" 636 section in the session description referenced by this IceCandidate. 637 The MID is a "media stream identification" value, as defined in 638 [RFC5888], Section 4, which provides a more robust way to identify 639 the "m=" section in the session description, using the MID of the 640 associated RtpTransceiver object (which may have been locally 641 generated by the answerer when interacting with a non-JSEP endpoint 642 that does not support the MID attribute, as discussed in Section 5.10 643 below). If the MID field is present in a received IceCandidate, it 644 MUST be used for identification; otherwise, the "m=" section index is 645 used instead. 647 Implementations MUST be prepared to receive objects with some fields 648 missing, as mentioned above. 650 3.5.3. ICE Candidate Policy 652 Typically, when gathering ICE candidates, the JSEP implementation 653 will gather all possible forms of initial candidates -- host, server- 654 reflexive, and relay. However, in certain cases, applications may 655 want to have more specific control over the gathering process, due to 656 privacy or related concerns. For example, one may want to only use 657 relay candidates, to leak as little location information as possible 658 (keeping in mind that this choice comes with corresponding 659 operational costs). To accomplish this, JSEP allows the application 660 to restrict which ICE candidates are used in a session. Note that 661 this filtering is applied on top of any restrictions the 662 implementation chooses to enforce regarding which IP addresses are 663 permitted for the application, as discussed in [RFC8828]. 665 There may also be cases where the application wants to change which 666 types of candidates are used while the session is active. A prime 667 example is where a callee may initially want to use only relay 668 candidates, to avoid leaking location information to an arbitrary 669 caller, but then change to use all candidates (for lower operational 670 cost) once the user has indicated that they want to take the call. 671 For this scenario, the JSEP implementation MUST allow the candidate 672 policy to be changed in mid-session, subject to the aforementioned 673 interactions with local policy. 675 To administer the ICE candidate policy, the JSEP implementation will 676 determine the current setting at the start of each gathering phase. 677 Then, during the gathering phase, the implementation MUST NOT expose 678 candidates disallowed by the current policy to the application, use 679 them as the source of connectivity checks, or indirectly expose them 680 via other fields, such as the raddr/rport attributes for other ICE 681 candidates. Later, if a different policy is specified by the 682 application, the application can apply it by kicking off a new 683 gathering phase via an ICE restart. 685 3.5.4. ICE Candidate Pool 687 JSEP applications typically inform the JSEP implementation to begin 688 ICE gathering via the information supplied to setLocalDescription, as 689 the local description indicates the number of ICE components that 690 will be needed and for which candidates must be gathered. However, 691 to accelerate cases where the application knows the number of ICE 692 components to use ahead of time, it may ask the implementation to 693 gather a pool of potential ICE candidates to help ensure rapid media 694 setup. 696 When setLocalDescription is eventually called and the JSEP 697 implementation prepares to gather the needed ICE candidates, it 698 SHOULD start by checking if any candidates are available in the pool. 699 If there are candidates in the pool, they SHOULD be handed to the 700 application immediately via the ICE candidate event. If the pool 701 becomes depleted, either because a larger-than-expected number of ICE 702 components are used or because the pool has not had enough time to 703 gather candidates, the remaining candidates are gathered as usual. 704 This only occurs for the first offer/answer exchange, after which the 705 candidate pool is emptied and no longer used. 707 One example of where this concept is useful is an application that 708 expects an incoming call at some point in the future, and wants to 709 minimize the time it takes to establish connectivity, to avoid 710 clipping of initial media. By pre-gathering candidates into the 711 pool, it can exchange and start sending connectivity checks from 712 these candidates almost immediately upon receipt of a call. Note, 713 though, that by holding on to these pre-gathered candidates, which 714 will be kept alive as long as they may be needed, the application 715 will consume resources on the STUN/TURN servers it is using. ("STUN" 716 stands for "Session Traversal Utilities for NAT".) 718 3.5.5. ICE Versions 720 While this specification formally relies on [RFC8445], at the time of 721 its publication, the majority of WebRTC implementations support the 722 version of ICE described in [RFC5245]. The "ice2" attribute defined 723 in [RFC8445] can be used to detect the version in use by a remote 724 endpoint and to provide a smooth transition from the older 725 specification to the newer one. Implementations MUST be able to 726 accept remote descriptions that do not have the "ice2" attribute. 728 3.6. Video Size Negotiation 730 Video size negotiation is the process through which a receiver can 731 use the "a=imageattr" SDP attribute [RFC6236] to indicate what video 732 frame sizes it is capable of receiving. A receiver may have hard 733 limits on what its video decoder can process, or it may have some 734 maximum set by policy. By specifying these limits in an 735 "a=imageattr" attribute, JSEP endpoints can attempt to ensure that 736 the remote sender transmits video at an acceptable resolution. 737 However, when communicating with a non-JSEP endpoint that does not 738 understand this attribute, any signaled limits may be exceeded, and 739 the JSEP implementation MUST handle this gracefully, e.g., by 740 discarding the video. 742 Note that certain codecs support transmission of samples with aspect 743 ratios other than 1.0 (i.e., non-square pixels). JSEP 744 implementations will not transmit non-square pixels but SHOULD 745 receive and render such video with the correct aspect ratio. 746 However, sample aspect ratio has no impact on the size negotiation 747 described below; all dimensions are measured in pixels, whether 748 square or not. 750 3.6.1. Creating an imageattr Attribute 752 The receiver will first combine any known local limits (e.g., 753 hardware decoder capabilities or local policy) to determine the 754 absolute minimum and maximum sizes it can receive. If there are no 755 known local limits, the "a=imageattr" attribute SHOULD be omitted. 756 If these local limits preclude receiving any video, i.e., the 757 degenerate case of no permitted resolutions, the "a=imageattr" 758 attribute MUST be omitted, and the "m=" section MUST be marked as 759 sendonly/inactive, as appropriate. 761 Otherwise, an "a=imageattr" attribute is created with a "recv" 762 direction, and the resulting resolution space formed from the 763 aforementioned intersection is used to specify its minimum and 764 maximum "x=" and "y=" values. 766 The rules here express a single set of preferences, and therefore, 767 the "a=imageattr" "q=" value is not important. It SHOULD be set to 768 "1.0". 770 The "a=imageattr" field is payload type specific. When all video 771 codecs supported have the same capabilities, use of a single 772 attribute, with the wildcard payload type (*), is RECOMMENDED. 773 However, when the supported video codecs have different limitations, 774 specific "a=imageattr" attributes MUST be inserted for each payload 775 type. 777 As an example, consider a system with a multiformat video decoder, 778 which is capable of decoding any resolution from 48x48 to 720p. In 779 this case, the implementation would generate this attribute: 781 a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] 783 This declaration indicates that the receiver is capable of decoding 784 any image resolution from 48x48 up to 1280x720 pixels. 786 3.6.2. Interpreting imageattr Attributes 788 [RFC6236] defines "a=imageattr" to be an advisory field. This means 789 that it does not absolutely constrain the video formats that the 790 sender can use but gives an indication of the preferred values. 792 This specification prescribes behavior that is more specific. When a 793 MediaStreamTrack, which is producing video of a certain resolution 794 (the "track resolution"), is attached to an RtpSender, which is 795 encoding the track video at the same or lower resolution(s) (the 796 "encoder resolutions"), and a remote description is applied that 797 references the sender and contains valid "a=imageattr recv" 798 attributes, it MUST follow the rules below to ensure that the sender 799 does not transmit a resolution that would exceed the size criteria 800 specified in the attributes. These rules MUST be followed as long as 801 the attributes remain present in the remote description, including 802 cases in which the track changes its resolution or is replaced with a 803 different track. 805 Depending on how the RtpSender is configured, it may be producing a 806 single encoding at a certain resolution or, if simulcast 807 (Section 3.7) has been negotiated, multiple encodings, each at their 808 own specific resolution. In addition, depending on the 809 configuration, each encoding may have the flexibility to reduce 810 resolution when needed or may be locked to a specific output 811 resolution. 813 For each encoding being produced by the RtpSender, the set of 814 "a=imageattr recv" attributes in the corresponding "m=" section of 815 the remote description is processed to determine what should be 816 transmitted. Only attributes that reference the media format 817 selected for the encoding are considered; each such attribute is 818 evaluated individually, starting with the attribute with the highest 819 "q=" value. If multiple attributes have the same "q=" value, they 820 are evaluated in the order they appear in their containing "m=" 821 section. Note that while JSEP endpoints will include at most one 822 "a=imageattr recv" attribute per media format, JSEP endpoints may 823 receive session descriptions from non-JSEP endpoints with "m=" 824 sections that contain multiple such attributes. 826 For each "a=imageattr recv" attribute, the following rules are 827 applied. If this processing is successful, the encoding is 828 transmitted accordingly, and no further attributes are considered for 829 that encoding. Otherwise, the next attribute is evaluated, in the 830 aforementioned order. If none of the supplied attributes can be 831 processed successfully, the encoding MUST NOT be transmitted, and an 832 error SHOULD be raised to the application. 834 * The limits from the attribute are compared to the encoder 835 resolution. Only the specific limits mentioned below are 836 considered; any other values, such as picture aspect ratio, MUST 837 be ignored. When considering a MediaStreamTrack that is producing 838 rotated video, the unrotated resolution MUST be used for the 839 checks. This is required regardless of whether the receiver 840 supports performing receive-side rotation (e.g., through 841 Coordination of Video Orientation (CVO) [TS26.114]), as it 842 significantly simplifies the matching logic. 844 * If the attribute includes a "sar=" (sample aspect ratio) value set 845 to something other than "1.0", indicating that the receiver wants 846 to receive non-square pixels, this cannot be satisfied and the 847 attribute MUST NOT be used. 849 * If the encoder resolution exceeds the maximum size permitted by 850 the attribute and the encoder is allowed to adjust its resolution, 851 the encoder SHOULD apply downscaling in order to satisfy the 852 limits. Downscaling MUST NOT change the picture aspect ratio of 853 the encoding, ignoring any trivial differences due to rounding. 854 For example, if the encoder resolution is 1280x720 and the 855 attribute specified a maximum of 640x480, the expected output 856 resolution would be 640x360. If downscaling cannot be applied, 857 the attribute MUST NOT be used. 859 * If the encoder resolution is less than the minimum size permitted 860 by the attribute, the attribute MUST NOT be used; the encoder MUST 861 NOT apply upscaling. JSEP implementations SHOULD avoid this 862 situation by allowing receipt of arbitrarily small resolutions, 863 perhaps via fallback to a software decoder. 865 * If the encoder resolution is within the maximum and minimum sizes, 866 no action is needed. 868 3.7. Simulcast 870 JSEP supports simulcast transmission of a MediaStreamTrack, where 871 multiple encodings of the source media can be transmitted within the 872 context of a single "m=" section. The current JSEP API is designed 873 to allow applications to send simulcasted media but only to receive a 874 single encoding. This allows for multi-user scenarios where each 875 sending client sends multiple encodings to a server, which then, for 876 each receiving client, chooses the appropriate encoding to forward. 878 Applications request support for simulcast by configuring multiple 879 encodings on an RtpSender. Upon generation of an offer or answer, 880 these encodings are indicated via SDP markings on the corresponding 881 "m=" section, as described below. Receivers that understand 882 simulcast and are willing to receive it will also include SDP 883 markings to indicate their support, and JSEP endpoints will use these 884 markings to determine whether simulcast is permitted for a given 885 RtpSender. If simulcast support is not negotiated, the RtpSender 886 will only use the first configured encoding. 888 Note that the exact simulcast parameters are up to the sending 889 application. While the aforementioned SDP markings are provided to 890 ensure that the remote side can receive and demux multiple simulcast 891 encodings, the specific resolutions and bitrates to be used for each 892 encoding are purely a send-side decision in JSEP. 894 JSEP currently does not provide a mechanism to configure receipt of 895 simulcast. This means that if simulcast is offered by the remote 896 endpoint, the answer generated by a JSEP endpoint will not indicate 897 support for receipt of simulcast, and as such the remote endpoint 898 will only send a single encoding per "m=" section. 900 In addition, JSEP does not provide a mechanism to handle an incoming 901 offer requesting simulcast from the JSEP endpoint. This means that 902 setting up simulcast in the case where the JSEP endpoint receives the 903 initial offer requires out-of-band signaling or SDP inspection. 904 However, in the case where the JSEP endpoint sets up simulcast in its 905 initial offer, any established simulcast streams will continue to 906 work upon receipt of an incoming re-offer. Future versions of this 907 specification may add additional APIs to handle the incoming initial 908 offer scenario. 910 When using JSEP to transmit multiple encodings from an RtpSender, the 911 techniques from [RFC8853] and [RFC8851] are used. Specifically, when 912 multiple encodings have been configured for an RtpSender, the "m=" 913 section for the RtpSender will include an "a=simulcast" attribute, as 914 defined in [RFC8853], Section 5.1, with a "send" simulcast stream 915 description that lists each desired encoding, and no "recv" simulcast 916 stream description. The "m=" section will also include an "a=rid" 917 attribute for each encoding, as specified in [RFC8851], Section 4; 918 the use of Restriction Identifiers (RIDs, also called rid-ids or 919 RtpStreamIds) allows the individual encodings to be disambiguated 920 even though they are all part of the same "m=" section. 922 3.8. Interactions with Forking 924 Some call signaling systems allow various types of forking where an 925 SDP Offer may be provided to more than one device. For example, SIP 926 [RFC3261] defines both a "parallel search" and "sequential search". 927 Although these are primarily signaling-level issues that are outside 928 the scope of JSEP, they do have some impact on the configuration of 929 the media plane that is relevant. When forking happens at the 930 signaling layer, the JavaScript application responsible for the 931 signaling needs to make the decisions about what media should be sent 932 or received at any point in time, as well as which remote endpoint it 933 should communicate with; JSEP is used to make sure the media engine 934 can make the RTP and media perform as required by the application. 935 The basic operations that the applications can have the media engine 936 do are as follows: 938 * Start exchanging media with a given remote peer, but keep all the 939 resources reserved in the offer. 941 * Start exchanging media with a given remote peer, and free any 942 resources in the offer that are not being used. 944 3.8.1. Sequential Forking 946 Sequential forking involves a call being dispatched to multiple 947 remote callees, where each callee can accept the call, but only one 948 active session ever exists at a time; no mixing of received media is 949 performed. 951 JSEP handles sequential forking well, allowing the application to 952 easily control the policy for selecting the desired remote endpoint. 953 When an answer arrives from one of the callees, the application can 954 choose to apply it as either (1) a provisional answer, leaving open 955 the possibility of using a different answer in the future or (2) a 956 final answer, ending the setup flow. 958 In a "first-one-wins" situation, the first answer will be applied as 959 a final answer, and the application will reject any subsequent 960 answers. In SIP parlance, this would be ACK + BYE. 962 In a "last-one-wins" situation, all answers would be applied as 963 provisional answers, and any previous call leg will be terminated. 964 At some point, the application will end the setup process, perhaps 965 with a timer; at this point, the application could reapply the 966 pending remote description as a final answer. 968 3.8.2. Parallel Forking 970 Parallel forking involves a call being dispatched to multiple remote 971 callees, where each callee can accept the call and multiple 972 simultaneous active signaling sessions can be established as a 973 result. If multiple callees send media at the same time, the 974 possibilities for handling this are described in [RFC3960], 975 Section 3.1. Most SIP devices today only support exchanging media 976 with a single device at a time and do not try to mix multiple early 977 media audio sources, as that could result in a confusing situation. 978 For example, consider having a European ringback tone mixed together 979 with the North American ringback tone -- the resulting sound would 980 not be like either tone and would confuse the user. If the signaling 981 application wishes to only exchange media with one of the remote 982 endpoints at a time, then from a media engine point of view, this is 983 exactly like the sequential forking case. 985 In the parallel forking case where the JavaScript application wishes 986 to simultaneously exchange media with multiple peers, the flow is 987 slightly more complex, but the JavaScript application can follow the 988 strategy that [RFC3960] describes, using UPDATE. The UPDATE approach 989 allows the signaling to set up a separate media flow for each peer 990 that it wishes to exchange media with. In JSEP, this offer used in 991 the UPDATE would be formed by simply creating a new PeerConnection 992 (see Section 4.1) and making sure that the same local media streams 993 have been added into this new PeerConnection. Then the new 994 PeerConnection object would produce an SDP offer that could be used 995 by the signaling to perform the UPDATE strategy discussed in 996 [RFC3960]. 998 As a result of sharing the media streams, the application will end up 999 with N parallel PeerConnection sessions, each with a local and remote 1000 description and their own local and remote addresses. The media flow 1001 from these sessions can be managed using setDirection (see 1002 Section 4.2.3), or the application can choose to play out the media 1003 from all sessions mixed together. Of course, if the application 1004 wants to only keep a single session, it can simply terminate the 1005 sessions that it no longer needs. 1007 4. Interface 1009 This section details the basic operations that must be present to 1010 implement JSEP functionality. The actual API exposed in the W3C API 1011 may have somewhat different syntax but should map easily to these 1012 concepts. 1014 4.1. PeerConnection 1016 4.1.1. Constructor 1018 The PeerConnection constructor allows the application to specify 1019 global parameters for the media session, such as the STUN/TURN 1020 servers and credentials to use when gathering candidates, as well as 1021 the initial ICE candidate policy and pool size, and also the bundle 1022 policy to use. 1024 If an ICE candidate policy is specified, it functions as described in 1025 Section 3.5.3, causing the JSEP implementation to only surface the 1026 permitted candidates (including any implementation-internal 1027 filtering) to the application and only use those candidates for 1028 connectivity checks. The set of available policies is as follows: 1030 all: All candidates permitted by implementation policy will be 1031 gathered and used. 1033 relay: All candidates except relay candidates will be filtered out. 1034 This obfuscates the location information that might be ascertained 1035 by the remote peer from the received candidates. Depending on how 1036 the application deploys and chooses relay servers, this could 1037 obfuscate location to a metro or possibly even global level. 1039 The default ICE candidate policy MUST be set to "all", as this is 1040 generally the desired policy and also typically reduces the use of 1041 application TURN server resources significantly. 1043 If a size is specified for the ICE candidate pool, this indicates the 1044 number of ICE components to pre-gather candidates for. Because 1045 pre-gathering results in utilizing STUN/TURN server resources for 1046 potentially long periods of time, this MUST only occur upon 1047 application request, and therefore the default candidate pool size 1048 MUST be zero. 1050 The application can specify its preferred policy regarding the use of 1051 BUNDLE, the multiplexing mechanism defined in [RFC9143]. Regardless 1052 of policy, the application will always try to negotiate bundle onto a 1053 single transport and will offer a single bundle group across all "m=" 1054 sections; use of this single transport is contingent upon the 1055 answerer accepting bundle. However, by specifying a policy from the 1056 list below, the application can control exactly how aggressively it 1057 will try to bundle media streams together, which affects how it will 1058 interoperate with a non-bundle-aware endpoint. When negotiating with 1059 a non-bundle-aware endpoint, only the streams not marked as bundle- 1060 only streams will be established. 1062 The set of available policies is as follows: 1064 balanced: The first "m=" section of each type (audio, video, or 1065 application) will contain transport parameters, which will allow 1066 an answerer to unbundle that section. The second and any 1067 subsequent "m=" sections of each type will be marked as bundle- 1068 only. The result is that if there are N distinct media types, 1069 then candidates will be gathered for N media streams. This policy 1070 balances the desire to multiplex with the need to ensure that 1071 basic audio and video can still be negotiated in legacy cases. 1072 When acting as answerer, if there is no bundle group in the offer, 1073 the implementation will reject all but the first "m=" section of 1074 each type. 1076 max-compat: All "m=" sections will contain transport parameters; 1077 none will be marked as bundle-only. This policy makes no 1078 assumptions about the remote endpoint and as such will allow all 1079 streams to be received by non-bundle-aware endpoints, but as a 1080 result requires separate candidates to be gathered for each media 1081 stream. 1083 must-bundle: Only the first "m=" section will contain transport 1084 parameters; all streams other than the first will be marked as 1085 bundle-only. This policy presumes the remote endpoint supports 1086 multiplexing and accordingly aims to minimize candidate gathering, 1087 at the cost of less compatibility with legacy endpoints. When 1088 acting as answerer, the implementation will reject any "m=" 1089 sections other than the first "m=" section, unless they are in the 1090 same bundle group as that "m=" section. 1092 As it provides the best trade-off between performance and 1093 compatibility with legacy endpoints, the default bundle policy MUST 1094 be set to "balanced". 1096 [RFC8829] defined a policy known as "max-bundle", which, while 1097 defined identically to the "must-bundle" policy described above, was 1098 implemented by some implementations according to an earlier, pre- 1099 standard definition (in which, for example, no "m=" sections were 1100 marked as bundle-only). As a result, "max-bundle" is considered 1101 deprecated, and new applications should use the "must-bundle" policy 1102 instead. 1104 The application can specify its preferred policy regarding use of 1105 RTP/RTCP multiplexing [RFC5761] using one of the following policies: 1107 negotiate: The JSEP implementation will gather both RTP and RTCP 1108 candidates but also will offer "a=rtcp-mux", thus allowing for 1109 compatibility with either multiplexing or non-multiplexing 1110 endpoints. 1112 require: The JSEP implementation will only gather RTP candidates and 1113 will insert an "a=rtcp-mux-only" indication into any new "m=" 1114 sections in offers it generates. This halves the number of 1115 candidates that the offerer needs to gather. Applying a 1116 description with an "m=" section that does not contain an "a=rtcp- 1117 mux" attribute will cause an error to be returned. 1119 The default multiplexing policy MUST be set to "require". 1120 Implementations MAY choose to reject attempts by the application to 1121 set the multiplexing policy to "negotiate". 1123 4.1.2. addTrack 1125 The addTrack method adds a MediaStreamTrack to the PeerConnection, 1126 using the MediaStream argument to associate the track with other 1127 tracks in the same MediaStream, so that they can be added to the same 1128 "LS" (Lip Synchronization) group when creating an offer or answer. 1129 Adding tracks to the same "LS" group indicates that the playback of 1130 these tracks should be synchronized for proper lip sync, as described 1131 in [RFC5888], Section 7. addTrack attempts to minimize the number of 1132 transceivers as follows: if the PeerConnection is in the 1133 "have-remote-offer" state, the track will be attached to the first 1134 compatible transceiver that was created by the most recent call to 1135 setRemoteDescription and does not have a local track. Otherwise, a 1136 new transceiver will be created, as described in Section 4.1.4. 1138 4.1.3. removeTrack 1140 The removeTrack method removes a MediaStreamTrack from the 1141 PeerConnection, using the RtpSender argument to indicate which sender 1142 should have its track removed. The sender's track is cleared, and 1143 the sender stops sending. Future calls to createOffer will mark the 1144 "m=" section associated with the sender as recvonly (if 1145 transceiver.direction is sendrecv) or as inactive (if 1146 transceiver.direction is sendonly). 1148 4.1.4. addTransceiver 1150 The addTransceiver method adds a new RtpTransceiver to the 1151 PeerConnection. If a MediaStreamTrack argument is provided, then the 1152 transceiver will be configured with that media type and the track 1153 will be attached to the transceiver. Otherwise, the application MUST 1154 explicitly specify the type; this mode is useful for creating 1155 recvonly transceivers as well as for creating transceivers to which a 1156 track can be attached at some later point. 1158 At the time of creation, the application can also specify a 1159 transceiver direction attribute, a set of MediaStreams that the 1160 transceiver is associated with (allowing "LS" group assignments), and 1161 a set of encodings for the media (used for simulcast as described in 1162 Section 3.7). 1164 4.1.5. onaddtrack Event 1166 The onaddtrack event is dispatched to the application when a new 1167 remote track has been signaled as a result of a setRemoteDescription 1168 call. The new track is supplied as a MediaStreamTrack object in the 1169 event, along with the MediaStream(s) the track is part of. 1171 4.1.6. createDataChannel 1173 The createDataChannel method creates a new data channel and attaches 1174 it to the PeerConnection. If no data channel currently exists for 1175 this PeerConnection, then a new offer/answer exchange is required. 1176 All data channels on a given PeerConnection share the same SCTP/DTLS 1177 association ("SCTP" stands for "Stream Control Transmission 1178 Protocol") and therefore the same "m=" section, so subsequent 1179 creation of data channels does not have any impact on the JSEP state. 1181 The createDataChannel method also includes a number of arguments that 1182 are used by the PeerConnection (e.g., maxPacketLifetime) but are not 1183 reflected in the SDP and do not affect the JSEP state. 1185 4.1.7. ondatachannel Event 1187 The ondatachannel event is dispatched to the application when a new 1188 data channel has been negotiated by the remote side, which can occur 1189 at any time after the underlying SCTP/DTLS association has been 1190 established. The new data channel object is supplied in the event. 1192 4.1.8. createOffer 1194 The createOffer method generates a blob of SDP that contains an offer 1195 per [RFC3264] with the supported configurations for the session, 1196 including descriptions of the media added to this PeerConnection, the 1197 codec, RTP, and RTCP options supported by this implementation, and 1198 any candidates that have been gathered by the ICE agent. An options 1199 parameter may be supplied to provide additional control over the 1200 generated offer. This options parameter allows an application to 1201 trigger an ICE restart, for the purpose of reestablishing 1202 connectivity. 1204 In the initial offer, the generated SDP will contain all desired 1205 functionality for the session (functionality that is supported but 1206 not desired by default may be omitted); for each SDP line, the 1207 generation of the SDP will follow the process defined for generating 1208 an initial offer from the specification that defines the given SDP 1209 line. The exact handling of initial offer generation is detailed in 1210 Section 5.2.1 below. 1212 In the event createOffer is called after the session is established, 1213 createOffer will generate an offer to modify the current session 1214 based on any changes that have been made to the session, e.g., adding 1215 or stopping RtpTransceivers, or requesting an ICE restart. For each 1216 existing stream, the generation of each SDP line MUST follow the 1217 process defined for generating an updated offer from the RFC that 1218 specifies the given SDP line. For each new stream, the generation of 1219 the SDP MUST follow the process of generating an initial offer, as 1220 mentioned above. If no changes have been made, or for SDP lines that 1221 are unaffected by the requested changes, the offer will only contain 1222 the parameters negotiated by the last offer/answer exchange. The 1223 exact handling of subsequent offer generation is detailed in 1224 Section 5.2.2 below. 1226 Session descriptions generated by createOffer MUST be immediately 1227 usable by setLocalDescription; if a system has limited resources 1228 (e.g., a finite number of decoders), createOffer SHOULD return an 1229 offer that reflects the current state of the system, so that 1230 setLocalDescription will succeed when it attempts to acquire those 1231 resources. 1233 Calling this method may do things such as generating new ICE 1234 credentials, but it does not change the PeerConnection state, trigger 1235 candidate gathering, or cause media to start or stop flowing. 1236 Specifically, the offer is not applied, and does not become the 1237 pending local description, until setLocalDescription is called. 1239 4.1.9. createAnswer 1241 The createAnswer method generates a blob of SDP that contains an SDP 1242 answer per [RFC3264] with the supported configuration for the session 1243 that is compatible with the parameters supplied in the most recent 1244 call to setRemoteDescription; setRemoteDescription MUST have been 1245 called prior to calling createAnswer. Like createOffer, the returned 1246 blob contains descriptions of the media added to this PeerConnection, 1247 the codec/RTP/RTCP options negotiated for this session, and any 1248 candidates that have been gathered by the ICE agent. An options 1249 parameter may be supplied to provide additional control over the 1250 generated answer. 1252 As an answer, the generated SDP will contain a specific configuration 1253 that specifies how the media plane should be established; for each 1254 SDP line, the generation of the SDP MUST follow the process defined 1255 for generating an answer from the specification that defines the 1256 given SDP line. The exact handling of answer generation is detailed 1257 in Section 5.3 below. 1259 Session descriptions generated by createAnswer MUST be immediately 1260 usable by setLocalDescription; like createOffer, the returned 1261 description SHOULD reflect the current state of the system. 1263 Calling this method may do things such as generating new ICE 1264 credentials, but it does not change the PeerConnection state, trigger 1265 candidate gathering, or cause a media state change. Specifically, 1266 the answer is not applied, and does not become the current local 1267 description, until setLocalDescription is called. 1269 4.1.10. SessionDescriptionType 1271 Session description objects (RTCSessionDescription) may be of type 1272 "offer", "pranswer", "answer", or "rollback". These types provide 1273 information as to how the description parameter should be parsed and 1274 how the media state should be changed. 1276 "offer" indicates that a description MUST be parsed as an offer; said 1277 description may include many possible media configurations. A 1278 description used as an "offer" may be applied any time the 1279 PeerConnection is in a "stable" state or applied as an update to a 1280 previously supplied but unanswered "offer". 1282 "pranswer" indicates that a description MUST be parsed as an answer, 1283 but not a final answer, and so MUST NOT result in the freeing of 1284 allocated resources. It may result in the start of media 1285 transmission, if the answer does not specify an inactive media 1286 direction. A description used as a "pranswer" may be applied as a 1287 response to an "offer" or as an update to a previously sent 1288 "pranswer". 1290 "answer" indicates that a description MUST be parsed as an answer, 1291 the offer/answer exchange MUST be considered complete, and any 1292 resources (decoders, candidates) that are no longer needed SHOULD be 1293 released. A description used as an "answer" may be applied as a 1294 response to an "offer" or as an update to a previously sent 1295 "pranswer". 1297 The only difference between a provisional and final answer is that 1298 the final answer results in the freeing of any unused resources that 1299 were allocated as a result of the offer. As such, the application 1300 can use some discretion on whether an answer should be applied as 1301 provisional or final and can change the type of the session 1302 description as needed. For example, in a serial forking scenario, an 1303 application may receive multiple "final" answers, one from each 1304 remote endpoint. The application could choose to accept the initial 1305 answers as provisional answers and only apply an answer as final when 1306 it receives one that meets its criteria (e.g., a live user instead of 1307 voicemail). 1309 "rollback" is a special session description type indicating that the 1310 state machine MUST be rolled back to the previous "stable" state, as 1311 described in Section 4.1.10.2. The contents MUST be empty. 1313 4.1.10.1. Use of Provisional Answers 1315 Most applications will not need to create answers using the 1316 "pranswer" type. While it is good practice to send an immediate 1317 response to an offer, in order to warm up the session transport and 1318 prevent media clipping, the preferred handling for a JSEP application 1319 is to create and send a "sendonly" final answer with a null 1320 MediaStreamTrack immediately after receiving the offer, which will 1321 prevent media from being sent by the caller and allow media to be 1322 sent immediately upon answer by the callee. Later, when the callee 1323 actually accepts the call, the application can plug in the real 1324 MediaStreamTrack and create a new "sendrecv" offer to update the 1325 previous offer/answer pair and start bidirectional media flow. While 1326 this could also be done with a "sendonly" pranswer followed by a 1327 "sendrecv" answer, the initial pranswer leaves the offer/answer 1328 exchange open, which means that the caller cannot send an updated 1329 offer during this time. 1331 As an example, consider a typical JSEP application that wants to set 1332 up audio and video as quickly as possible. When the callee receives 1333 an offer with audio and video MediaStreamTracks, it will send an 1334 immediate answer accepting these tracks as sendonly (meaning that the 1335 caller will not send the callee any media yet, and because the callee 1336 has not yet added its own MediaStreamTracks, the callee will not send 1337 any media either). It will then ask the user to accept the call and 1338 acquire the needed local tracks. Upon acceptance by the user, the 1339 application will plug in the tracks it has acquired, which, because 1340 ICE handshaking and DTLS handshaking have likely completed by this 1341 point, can start transmitting immediately. The application will also 1342 send a new offer to the remote side indicating call acceptance and 1343 moving the audio and video to be two-way media. A detailed example 1344 flow along these lines is shown in Section 7.3. 1346 Of course, some applications may not be able to perform this double 1347 offer/answer exchange, particularly ones that are attempting to 1348 gateway to legacy signaling protocols. In these cases, pranswer can 1349 still provide the application with a mechanism to warm up the 1350 transport. 1352 4.1.10.2. Rollback 1354 In certain situations, it may be desirable to "undo" a change made to 1355 setLocalDescription or setRemoteDescription. Consider a case where a 1356 call is ongoing and one side wants to change some of the session 1357 parameters; that side generates an updated offer and then calls 1358 setLocalDescription. However, the remote side, either before or 1359 after setRemoteDescription, decides it does not want to accept the 1360 new parameters and sends a reject message back to the offerer. Now, 1361 the offerer, and possibly the answerer as well, needs to return to a 1362 "stable" state and the previous local/remote description. To support 1363 this, we introduce the concept of "rollback", which discards any 1364 proposed changes to the session, returning the state machine to the 1365 "stable" state. A rollback is performed by supplying a session 1366 description of type "rollback" with empty contents to either 1367 setLocalDescription or setRemoteDescription. 1369 4.1.11. setLocalDescription 1371 The setLocalDescription method instructs the PeerConnection to apply 1372 the supplied session description as its local configuration. The 1373 type field indicates whether the description should be processed as 1374 an offer, provisional answer, final answer, or rollback; offers and 1375 answers are checked differently, using the various rules that exist 1376 for each SDP line. 1378 This API changes the local media state; among other things, it sets 1379 up local resources for receiving and decoding media. In order to 1380 successfully handle scenarios where the application wants to offer to 1381 change from one media format to a different, incompatible format, the 1382 PeerConnection MUST be able to simultaneously support use of both the 1383 current and pending local descriptions (e.g., support the codecs that 1384 exist in either description). This dual processing begins when the 1385 PeerConnection enters the "have-local-offer" state, and it continues 1386 until setRemoteDescription is called with either (1) a final answer, 1387 at which point the PeerConnection can fully adopt the pending local 1388 description or (2) a rollback, which results in a revert to the 1389 current local description. 1391 This API indirectly controls the candidate gathering process. When a 1392 local description is supplied and the number of transports currently 1393 in use does not match the number of transports needed by the local 1394 description, the PeerConnection will create transports as needed and 1395 begin gathering candidates for each transport, using ones from the 1396 candidate pool if available. 1398 If (1) setRemoteDescription was previously called with an offer, (2) 1399 setLocalDescription is called with an answer (provisional or final), 1400 (3) the media directions are compatible, and (4) media is available 1401 to send, this will result in the starting of media transmission. 1403 4.1.12. setRemoteDescription 1405 The setRemoteDescription method instructs the PeerConnection to apply 1406 the supplied session description as the desired remote configuration. 1407 As in setLocalDescription, the type field of the description 1408 indicates how it should be processed. 1410 This API changes the local media state; among other things, it sets 1411 up local resources for sending and encoding media. 1413 If (1) setLocalDescription was previously called with an offer, (2) 1414 setRemoteDescription is called with an answer (provisional or final), 1415 (3) the media directions are compatible, and (4) media is available 1416 to send, this will result in the starting of media transmission. 1418 4.1.13. currentLocalDescription 1420 The currentLocalDescription method returns the current negotiated 1421 local description -- i.e., the local description from the last 1422 successful offer/answer exchange -- in addition to any local 1423 candidates that have been generated by the ICE agent since the local 1424 description was set. 1426 A null object will be returned if an offer/answer exchange has not 1427 yet been completed. 1429 4.1.14. pendingLocalDescription 1431 The pendingLocalDescription method returns a copy of the local 1432 description currently in negotiation -- i.e., a local offer set 1433 without any corresponding remote answer -- in addition to any local 1434 candidates that have been generated by the ICE agent since the local 1435 description was set. 1437 A null object will be returned if the state of the PeerConnection is 1438 "stable" or "have-remote-offer". 1440 4.1.15. currentRemoteDescription 1442 The currentRemoteDescription method returns a copy of the current 1443 negotiated remote description -- i.e., the remote description from 1444 the last successful offer/answer exchange -- in addition to any 1445 remote candidates that have been supplied via processIceMessage since 1446 the remote description was set. 1448 A null object will be returned if an offer/answer exchange has not 1449 yet been completed. 1451 4.1.16. pendingRemoteDescription 1453 The pendingRemoteDescription method returns a copy of the remote 1454 description currently in negotiation -- i.e., a remote offer set 1455 without any corresponding local answer -- in addition to any remote 1456 candidates that have been supplied via processIceMessage since the 1457 remote description was set. 1459 A null object will be returned if the state of the PeerConnection is 1460 "stable" or "have-local-offer". 1462 4.1.17. canTrickleIceCandidates 1464 The canTrickleIceCandidates property indicates whether the remote 1465 side supports receiving trickled candidates. There are three 1466 potential values: 1468 null: No SDP has been received from the other side, so it is not 1469 known if it can handle trickle. This is the initial value before 1470 setRemoteDescription is called. 1472 true: SDP has been received from the other side indicating that it 1473 can support trickle. 1475 false: SDP has been received from the other side indicating that it 1476 cannot support trickle. 1478 As described in Section 3.5.2, JSEP implementations always provide 1479 candidates to the application individually, consistent with what is 1480 needed for Trickle ICE. However, applications can use the 1481 canTrickleIceCandidates property to determine whether their peer can 1482 actually do Trickle ICE, i.e., whether it is safe to send an initial 1483 offer or answer followed later by candidates as they are gathered. 1484 As "true" is the only value that definitively indicates remote 1485 Trickle ICE support, an application that compares 1486 canTrickleIceCandidates against "true" will by default attempt Half 1487 Trickle on initial offers and Full Trickle on subsequent interactions 1488 with a Trickle ICE-compatible agent. 1490 4.1.18. setConfiguration 1492 The setConfiguration method allows the global configuration of the 1493 PeerConnection, which was initially set by constructor parameters, to 1494 be changed during the session. The effects of calling this method 1495 depend on when it is invoked, and they will differ, depending on 1496 which specific parameters are changed: 1498 * Any changes to the STUN/TURN servers to use affect the next 1499 gathering phase. If an ICE gathering phase has already started or 1500 completed, the 'needs-ice-restart' bit mentioned in Section 3.5.1 1501 will be set. This will cause the next call to createOffer to 1502 generate new ICE credentials, for the purpose of forcing an ICE 1503 restart and kicking off a new gathering phase, in which the new 1504 servers will be used. If the ICE candidate pool has a nonzero 1505 size and a local description has not yet been applied, any 1506 existing candidates will be discarded, and new candidates will be 1507 gathered from the new servers. 1509 * Any change to the ICE candidate policy affects the next gathering 1510 phase. If an ICE gathering phase has already started or 1511 completed, the 'needs-ice-restart' bit will be set. Either way, 1512 changes to the policy have no effect on the candidate pool, 1513 because pooled candidates are not made available to the 1514 application until a gathering phase occurs, and so any necessary 1515 filtering can still be done on any pooled candidates. 1517 * The ICE candidate pool size MUST NOT be changed after applying a 1518 local description. If a local description has not yet been 1519 applied, any changes to the ICE candidate pool size take effect 1520 immediately; if increased, additional candidates are pre-gathered; 1521 if decreased, the now-superfluous candidates are discarded. 1523 * The bundle and RTCP-multiplexing policies MUST NOT be changed 1524 after the construction of the PeerConnection. 1526 Calling this method may result in a change to the state of the ICE 1527 agent. 1529 4.1.19. addIceCandidate 1531 The addIceCandidate method provides an update to the ICE agent via an 1532 IceCandidate object (Section 3.5.2.1). If the IceCandidate's 1533 candidate field is non-null, the IceCandidate is treated as a new 1534 remote ICE candidate, which will be added to the current and/or 1535 pending remote description according to the rules defined for Trickle 1536 ICE. Otherwise, the IceCandidate is treated as an end-of-candidates 1537 indication, as defined in [RFC8838], Section 14. 1539 In either case, the "m=" section index, MID, and ufrag fields from 1540 the supplied IceCandidate are used to determine which "m=" section 1541 and ICE candidate generation the IceCandidate belongs to, as 1542 described in Section 3.5.2.1 above. In the case of an end-of- 1543 candidates indication, null values for the "m=" section index and MID 1544 fields are interpreted to mean that the indication applies to all 1545 "m=" sections in the specified ICE candidate generation. However, if 1546 both fields are null for a new remote candidate, this MUST be treated 1547 as an invalid condition, as specified below. 1549 If any IceCandidate fields contain invalid values or an error occurs 1550 during the processing of the IceCandidate object, the supplied 1551 IceCandidate MUST be ignored and an error MUST be returned. 1553 Otherwise, the new remote candidate or end-of-candidates indication 1554 is supplied to the ICE agent. In the case of a new remote candidate, 1555 connectivity checks will be sent to the new candidate, assuming 1556 setLocalDescription has already been called to initialize the ICE 1557 gathering process. 1559 4.1.20. onicecandidate Event 1561 The onicecandidate event is dispatched to the application in two 1562 situations: (1) when the ICE agent has discovered a new allowed local 1563 ICE candidate during ICE gathering, as outlined in Section 3.5.1 and 1564 subject to the restrictions discussed in Section 3.5.3, or (2) when 1565 an ICE gathering phase completes. The event contains a single 1566 IceCandidate object, as defined in Section 3.5.2.1. 1568 In the first case, the newly discovered candidate is reflected in the 1569 IceCandidate object, and all of its fields MUST be non-null. This 1570 candidate will also be added to the current and/or pending local 1571 description according to the rules defined for Trickle ICE. 1573 In the second case, the event's IceCandidate object MUST have its 1574 candidate field set to null to indicate that the current gathering 1575 phase is complete, i.e., there will be no further onicecandidate 1576 events in this phase. However, the IceCandidate's ufrag field MUST 1577 be specified to indicate which ICE candidate generation is ending. 1578 The IceCandidate's "m=" section index and MID fields MAY be specified 1579 to indicate that the event applies to a specific "m=" section, or set 1580 to null to indicate it applies to all "m=" sections in the current 1581 ICE candidate generation. This event can be used by the application 1582 to generate an end-of-candidates indication, as defined in [RFC8838], 1583 Section 13. 1585 4.2. RtpTransceiver 1587 4.2.1. stop 1589 The stop method stops an RtpTransceiver. This will cause future 1590 calls to createOffer to generate a zero port for the associated "m=" 1591 section. See below for more details. 1593 4.2.2. stopped 1595 The stopped property indicates whether the transceiver has been 1596 stopped, either by a call to stop or by applying an answer that 1597 rejects the associated "m=" section. In either of these cases, it is 1598 set to "true" and otherwise will be set to "false". 1600 A stopped RtpTransceiver does not send any outgoing RTP or RTCP or 1601 process any incoming RTP or RTCP. It cannot be restarted. 1603 4.2.3. setDirection 1605 The setDirection method sets the direction of a transceiver, which 1606 affects the direction property of the associated "m=" section on 1607 future calls to createOffer and createAnswer. The permitted values 1608 for direction are "recvonly", "sendrecv", "sendonly", and "inactive", 1609 mirroring the identically named direction attributes defined in 1610 [RFC4566], Section 6. 1612 When creating offers, the transceiver direction is directly reflected 1613 in the output, even for re-offers. When creating answers, the 1614 transceiver direction is intersected with the offered direction, as 1615 explained in Section 5.3 below. 1617 Note that while setDirection sets the direction property of the 1618 transceiver immediately (Section 4.2.4), this property does not 1619 immediately affect whether the transceiver's RtpSender will send or 1620 its RtpReceiver will receive. The direction in effect is represented 1621 by the currentDirection property, which is only updated when an 1622 answer is applied. 1624 4.2.4. direction 1626 The direction property indicates the last value passed into 1627 setDirection. If setDirection has never been called, it is set to 1628 the direction the transceiver was initialized with. 1630 4.2.5. currentDirection 1632 The currentDirection property indicates the last negotiated direction 1633 for the transceiver's associated "m=" section. More specifically, it 1634 indicates the direction attribute [RFC3264] of the associated "m=" 1635 section in the last applied answer (including provisional answers), 1636 with "send" and "recv" directions reversed if it was a remote answer. 1637 For example, if the direction attribute for the associated "m=" 1638 section in a remote answer is "recvonly", currentDirection is set to 1639 "sendonly". 1641 If an answer that references this transceiver has not yet been 1642 applied or if the transceiver is stopped, currentDirection is set to 1643 "null". 1645 4.2.6. setCodecPreferences 1647 The setCodecPreferences method sets the codec preferences of a 1648 transceiver, which in turn affect the presence and order of codecs of 1649 the associated "m=" section on future calls to createOffer and 1650 createAnswer. Note that setCodecPreferences does not directly affect 1651 which codec the implementation decides to send. It only affects 1652 which codecs the implementation indicates that it prefers to receive, 1653 via the offer or answer. Even when a codec is excluded by 1654 setCodecPreferences, it still may be used to send until the next 1655 offer/answer exchange discards it. 1657 The codec preferences of an RtpTransceiver can cause codecs to be 1658 excluded by subsequent calls to createOffer and createAnswer, in 1659 which case the corresponding media formats in the associated "m=" 1660 section will be excluded. The codec preferences cannot add media 1661 formats that would otherwise not be present. 1663 The codec preferences of an RtpTransceiver can also determine the 1664 order of codecs in subsequent calls to createOffer and createAnswer, 1665 in which case the order of the media formats in the associated "m=" 1666 section will follow the specified preferences. 1668 5. SDP Interaction Procedures 1670 This section describes the specific procedures to be followed when 1671 creating and parsing SDP objects. 1673 5.1. Requirements Overview 1675 JSEP implementations MUST comply with the specifications listed below 1676 that govern the creation and processing of offers and answers. 1678 5.1.1. Usage Requirements 1680 All session descriptions handled by JSEP implementations, both local 1681 and remote, MUST indicate support for the following specifications. 1682 If any of these are absent, this omission MUST be treated as an 1683 error. 1685 * ICE, as specified in [RFC8445], MUST be used. Note that the 1686 remote endpoint may use a lite implementation; implementations 1687 MUST properly handle remote endpoints that use ICE-lite. The 1688 remote endpoint may also use an older version of ICE; 1689 implementations MUST properly handle remote endpoints that use ICE 1690 as specified in [RFC5245]. 1692 * DTLS [RFC6347] or DTLS-SRTP [RFC5763] MUST be used, as appropriate 1693 for the media type, as specified in [RFC8827]. 1695 The SDP security descriptions mechanism for SRTP keying [RFC4568] 1696 MUST NOT be used, as discussed in [RFC8827]. 1698 5.1.2. Profile Names and Interoperability 1700 For media "m=" sections, JSEP implementations MUST support the 1701 "UDP/TLS/RTP/SAVPF" profile specified in [RFC5764] as well as the 1702 "TCP/DTLS/RTP/SAVPF" profile specified in [RFC7850] and MUST indicate 1703 one of these profiles for each media "m=" line they produce in an 1704 offer. For data "m=" sections, implementations MUST support the 1705 "UDP/DTLS/SCTP" profile as well as the "TCP/DTLS/SCTP" profile and 1706 MUST indicate one of these profiles for each data "m=" line they 1707 produce in an offer. The exact profile to use is determined by the 1708 protocol associated with the current default or selected ICE 1709 candidate, as described in [RFC8839], Section 4.2.1.2. 1711 Unfortunately, in an attempt at compatibility, some endpoints 1712 generate other profile strings even when they mean to support one of 1713 these profiles. For instance, an endpoint might generate "RTP/AVP" 1714 but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its 1715 willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/DTLS/RTP/SAVPF". 1716 In order to simplify compatibility with such endpoints, JSEP 1717 implementations MUST follow the following rules when processing the 1718 media "m=" sections in a received offer: 1720 * Any profile in the offer matching one of the following MUST be 1721 accepted: 1723 - "RTP/AVP" (defined in [RFC4566], Section 8.2.2) 1725 - "RTP/AVPF" (defined in [RFC4585], Section 9) 1727 - "RTP/SAVP" (defined in [RFC3711], Section 12) 1729 - "RTP/SAVPF" (defined in [RFC5124], Section 6) 1731 - "TCP/DTLS/RTP/SAVP" (defined in [RFC7850], Section 3.4) 1733 - "TCP/DTLS/RTP/SAVPF" (defined in [RFC7850], Section 3.5) 1735 - "UDP/TLS/RTP/SAVP" (defined in [RFC5764], Section 9) 1737 - "UDP/TLS/RTP/SAVPF" (defined in [RFC5764], Section 9) 1739 * The profile in any "m=" line in any generated answer MUST exactly 1740 match the profile provided in the offer. 1742 * Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no 1743 effect; support for DTLS-SRTP is determined by the presence of one 1744 or more "a=fingerprint" attributes. Note that lack of an 1745 "a=fingerprint" attribute will lead to negotiation failure. 1747 * The use of AVPF or AVP simply controls the timing rules used for 1748 RTCP feedback. If AVPF is provided or an "a=rtcp-fb" attribute is 1749 present, assume AVPF timing, i.e., a default value of "trr-int=0". 1750 Otherwise, assume that AVPF is being used in an AVP-compatible 1751 mode and use a value of "trr-int=4000". 1753 * For data "m=" sections, implementations MUST support receiving the 1754 "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards 1755 compatibility) profiles. 1757 Note that re-offers by JSEP implementations MUST use the correct 1758 profile strings even if the initial offer/answer exchange used an 1759 (incorrect) older profile string. This simplifies JSEP behavior, 1760 with minimal downside, as any remote endpoint that fails to handle 1761 such a re-offer will also fail to handle a JSEP endpoint's initial 1762 offer. 1764 5.2. Constructing an Offer 1766 When createOffer is called, a new SDP description MUST be created 1767 that includes the functionality specified in [RFC8834]. The exact 1768 details of this process are explained below. 1770 5.2.1. Initial Offers 1772 When createOffer is called for the first time, the result is known as 1773 the initial offer. 1775 The first step in generating an initial offer is to generate session- 1776 level attributes, as specified in [RFC4566], Section 5. 1777 Specifically: 1779 * The first SDP line MUST be "v=0" as defined in [RFC4566], 1780 Section 5.1. 1782 * The second SDP line MUST be an "o=" line as defined in [RFC4566], 1783 Section 5.2. The value of the field SHOULD be "-". 1784 The MUST be representable by a 64-bit signed integer, 1785 and the value MUST be less than 2^63-1. It is RECOMMENDED that 1786 the be constructed by generating a 64-bit quantity with 1787 the highest bit set to zero and the remaining 63 bits being 1788 cryptographically random. The value of the 1789 tuple SHOULD be set to a non-meaningful address, 1790 such as IN IP4 0.0.0.0, to prevent leaking a local IP address in 1791 this field; this problem is discussed in [RFC8828]. As mentioned 1792 in [RFC4566], the entire "o=" line needs to be unique, but 1793 selecting a random number for is sufficient to 1794 accomplish this. 1796 * The third SDP line MUST be a "s=" line as defined in [RFC4566], 1797 Section 5.3; to match the "o=" line, a single dash SHOULD be used 1798 as the session name, e.g., "s=-". Note that this differs from the 1799 advice in [RFC4566], which proposes a single space, but as both 1800 "o=" and "s=" are meaningless in JSEP, having the same meaningless 1801 value seems clearer. 1803 * Session Information ("i="), URI ("u="), Email Address ("e="), 1804 Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") 1805 lines are not useful in this context and SHOULD NOT be included. 1807 * Encryption Keys ("k=") lines do not provide sufficient security 1808 and MUST NOT be included. 1810 * A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; 1811 both and SHOULD be set to zero, e.g., 1812 "t=0 0". 1814 * An "a=ice-options" line with the "trickle" and "ice2" options MUST 1815 be added, as specified in [RFC8840], Section 4.1.1 and [RFC8445], 1816 Section 10. 1818 * If WebRTC identity is being used, an "a=identity" line MUST be 1819 added, as described in [RFC8827], Section 5. 1821 The next step is to generate "m=" sections, as specified in 1822 [RFC4566], Section 5.14. An "m=" section is generated for each 1823 RtpTransceiver that has been added to the PeerConnection, excluding 1824 any stopped RtpTransceivers; this is done in the order the 1825 RtpTransceivers were added to the PeerConnection. If there are no 1826 such RtpTransceivers, no "m=" sections are generated; more can be 1827 added later, as discussed in [RFC3264], Section 5. 1829 For each "m=" section generated for an RtpTransceiver, establish a 1830 mapping between the transceiver and the index of the generated "m=" 1831 section. 1833 Each "m=" section, provided it is not marked as bundle-only, MUST 1834 contain a unique set of ICE credentials and a unique set of ICE 1835 candidates. Bundle-only "m=" sections MUST NOT contain any ICE 1836 credentials and MUST NOT gather any candidates. 1838 For DTLS, all "m=" sections MUST use any and all certificates that 1839 have been specified for the PeerConnection; as a result, they MUST 1840 all have the same fingerprint value or values [RFC8122], or these 1841 values MUST be session-level attributes. 1843 Each "m=" section MUST be generated as specified in [RFC4566], 1844 Section 5.14. For the "m=" line itself, the following rules MUST be 1845 followed: 1847 * If the "m=" section is marked as bundle-only, then the 1848 value MUST be set to zero. Otherwise, the value is set to 1849 the port of the default ICE candidate for this "m=" section, but 1850 given that no candidates are available yet, the default port value 1851 of 9 (Discard) MUST be used, as indicated in [RFC8840], 1852 Section 4.1.1. 1854 * To properly indicate use of DTLS, the field MUST be set to 1855 "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. 1857 * If codec preferences have been set for the associated transceiver, 1858 media formats MUST be generated in the corresponding order and 1859 MUST exclude any codecs not present in the codec preferences. 1861 * Unless excluded by the above restrictions, the media formats MUST 1862 include the mandatory audio/video codecs as specified in 1863 [RFC7874], Section 3 and [RFC7742], Section 5. 1865 The "m=" line MUST be followed immediately by a "c=" line, as 1866 specified in [RFC4566], Section 5.7. Again, as no candidates are 1867 available yet, the "c=" line MUST contain the default value "IN IP4 1868 0.0.0.0", as defined in [RFC8840], Section 4.1.1. 1870 [RFC8859] groups SDP attributes into different categories. To avoid 1871 unnecessary duplication when bundling, attributes of category 1872 IDENTICAL or TRANSPORT MUST NOT be repeated in bundled "m=" sections, 1873 repeating the guidance from [RFC9143], Section 7.1.3. This includes 1874 "m=" sections for which bundling has been negotiated and is still 1875 desired, as well as "m=" sections marked as bundle-only. 1877 The following attributes, which are of a category other than 1878 IDENTICAL or TRANSPORT, MUST be included in each "m=" section: 1880 * An "a=mid" line, as specified in [RFC5888], Section 4. All MID 1881 values MUST be generated in a fashion that does not leak user 1882 information, e.g., randomly or using a per-PeerConnection counter, 1883 and SHOULD be 3 bytes or less, to allow them to efficiently fit 1884 into the RTP header extension defined in [RFC9143], Section 15.2. 1885 Note that this does not set the RtpTransceiver mid property, as 1886 that only occurs when the description is applied. The generated 1887 MID value can be considered a "proposed" MID at this point. 1889 * A direction attribute that is the same as that of the associated 1890 transceiver. 1892 * For each media format on the "m=" line, "a=rtpmap" and "a=fmtp" 1893 lines, as specified in [RFC4566], Section 6 and [RFC3264], 1894 Section 5.1. 1896 * For each primary codec where RTP retransmission should be used, a 1897 corresponding "a=rtpmap" line indicating "rtx" with the clock rate 1898 of the primary codec and an "a=fmtp" line that references the 1899 payload type of the primary codec, as specified in [RFC4588], 1900 Section 8.1. 1902 * For each supported Forward Error Correction (FEC) mechanism, 1903 "a=rtpmap" and "a=fmtp" lines, as specified in [RFC4566], 1904 Section 6. The FEC mechanisms that MUST be supported are 1905 specified in [RFC8854], Section 7, and specific usage for each 1906 media type is outlined in Sections 4 and 5. 1908 * If this "m=" section is for media with configurable durations of 1909 media per packet, e.g., audio, an "a=maxptime" line, indicating 1910 the maximum amount of media, specified in milliseconds, that can 1911 be encapsulated in each packet, as specified in [RFC4566], 1912 Section 6. This value is set to the smallest of the maximum 1913 duration values across all the codecs included in the "m=" 1914 section. 1916 * If this "m=" section is for video media and there are known 1917 limitations on the size of images that can be decoded, an 1918 "a=imageattr" line, as specified in Section 3.6. 1920 * For each supported RTP header extension, an "a=extmap" line, as 1921 specified in [RFC5285], Section 5. The list of header extensions 1922 that SHOULD/MUST be supported is specified in [RFC8834], 1923 Section 5.2. Any header extensions that require encryption MUST 1924 be specified as indicated in [RFC6904], Section 4. 1926 * For each supported RTCP feedback mechanism, an "a=rtcp-fb" line, 1927 as specified in [RFC4585], Section 4.2. The list of RTCP feedback 1928 mechanisms that SHOULD/MUST be supported is specified in 1929 [RFC8834], Section 5.1. 1931 * If the RtpTransceiver has a sendrecv or sendonly direction: 1933 - For each MediaStream that was associated with the transceiver 1934 when it was created via addTrack or addTransceiver, an "a=msid" 1935 line, as specified in [RFC8830], Section 2, but omitting the 1936 "appdata" field. 1938 * If the RtpTransceiver has a sendrecv or sendonly direction, and 1939 the application has specified a rid-id for an encoding, or has 1940 specified more than one encoding in the RtpSenders's parameters, 1941 an "a=rid" line for each encoding specified. The "a=rid" line is 1942 specified in [RFC8851], and its direction MUST be "send". If the 1943 application has chosen a rid-id, it MUST be used; otherwise, a 1944 rid-id MUST be generated by the implementation. rid-ids MUST be 1945 generated in a fashion that does not leak user information, e.g., 1946 randomly or using a per-PeerConnection counter (see guidance at 1947 the end of [RFC8852], Section 3.3), and SHOULD be 3 bytes or less, 1948 to allow them to efficiently fit into the RTP header extensions 1949 defined in [RFC8852], Section 3.3. If no encodings have been 1950 specified, or only one encoding is specified but without a rid-id, 1951 then no "a=rid" lines are generated. 1953 * If the RtpTransceiver has a sendrecv or sendonly direction and 1954 more than one "a=rid" line has been generated, an "a=simulcast" 1955 line, with direction "send", as defined in [RFC8853], Section 5.1. 1956 The associated set of rid-ids MUST include all of the rid-ids used 1957 in the "a=rid" lines for this "m=" section. 1959 * If (1) the bundle policy for this PeerConnection is set to "must- 1960 bundle" and this is not the first "m=" section or (2) the bundle 1961 policy is set to "balanced" and this is not the first "m=" section 1962 for this media type, an "a=bundle-only" line. 1964 The following attributes, which are of category IDENTICAL or 1965 TRANSPORT, MUST appear only in "m=" sections that either have a 1966 unique address or are associated with the BUNDLE-tag. (In initial 1967 offers, this means those "m=" sections that do not contain an 1968 "a=bundle-only" attribute.) 1970 * "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC8839], 1971 Section 5.4. 1973 * For each desired digest algorithm, one or more "a=fingerprint" 1974 lines for each of the endpoint's certificates, as specified in 1975 [RFC8122], Section 5. 1977 * An "a=setup" line, as specified in [RFC4145], Section 4 and 1978 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1979 The role value in the offer MUST be "actpass". 1981 * An "a=tls-id" line, as specified in [RFC8842], Section 5.2. 1983 * An "a=rtcp" line, as specified in [RFC3605], Section 2.1, 1984 containing the default value "9 IN IP4 0.0.0.0", because no 1985 candidates have yet been gathered. 1987 * An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.3. 1989 * If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- 1990 only" line, as specified in [RFC8858], Section 4. 1992 * An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. 1994 Lastly, if a data channel has been created, an "m=" section MUST be 1995 generated for data. The field MUST be set to "application", 1996 and the field MUST be set to "UDP/DTLS/SCTP" [RFC8841]. The 1997 value MUST be set to "webrtc-datachannel" as specified in 1998 [RFC8841], Section 4.2.2. 2000 Within the data "m=" section, an "a=mid" line MUST be generated and 2001 included as described above, along with an "a=sctp-port" line 2002 referencing the SCTP port number, as defined in [RFC8841], 2003 Section 5.1; and, if appropriate, an "a=max-message-size" line, as 2004 defined in [RFC8841], Section 6.1. 2006 As discussed above, the following attributes of category IDENTICAL or 2007 TRANSPORT are included only if the data "m=" section either has a 2008 unique address or is associated with the BUNDLE-tag (e.g., if it is 2009 the only "m=" section): 2011 * "a=ice-ufrag" 2013 * "a=ice-pwd" 2015 * "a=fingerprint" 2017 * "a=setup" 2019 * "a=tls-id" 2021 Once all "m=" sections have been generated, a session-level "a=group" 2022 attribute MUST be added as specified in [RFC5888]. This attribute 2023 MUST have semantics "BUNDLE" and MUST include the mid identifiers of 2024 each "m=" section. The effect of this is that the JSEP 2025 implementation offers all "m=" sections as one bundle group. 2026 However, whether the "m=" sections are bundle-only or not depends on 2027 the bundle policy. 2029 The next step is to generate session-level lip sync groups as defined 2030 in [RFC5888], Section 7. For each MediaStream referenced by more 2031 than one RtpTransceiver (by passing those MediaStreams as arguments 2032 to the addTrack and addTransceiver methods), a group of type "LS" 2033 MUST be added that contains the MID values for each RtpTransceiver. 2035 Attributes that SDP permits to be at either the session level or the 2036 media level SHOULD generally be at the media level even if they are 2037 identical. This assists development and debugging by making it 2038 easier to understand individual media sections, especially if one of 2039 a set of initially identical attributes is subsequently changed. 2041 However, implementations MAY choose to aggregate attributes at the 2042 session level, and JSEP implementations MUST be prepared to receive 2043 attributes in either location. 2045 Attributes other than the ones specified above MAY be included, 2046 except for the following attributes, which are specifically 2047 incompatible with the requirements of [RFC8834] and MUST NOT be 2048 included: 2050 * "a=crypto" 2052 * "a=key-mgmt" 2054 * "a=ice-lite" 2056 Note that when bundle is used, any additional attributes that are 2057 added MUST follow the advice in [RFC8859] on how those attributes 2058 interact with bundle. 2060 Note that these requirements are in some cases stricter than those of 2061 SDP. Implementations MUST be prepared to accept compliant SDP even 2062 if it would not conform to the requirements for generating SDP in 2063 this specification. 2065 5.2.2. Subsequent Offers 2067 When createOffer is called a second (or later) time or is called 2068 after a local description has already been installed, the processing 2069 is somewhat different than for an initial offer. 2071 If the previous offer was not applied using setLocalDescription, 2072 meaning the PeerConnection is still in the "stable" state, the steps 2073 for generating an initial offer MUST be followed, subject to the 2074 following restriction: 2076 * The fields of the "o=" line MUST stay the same except for the 2077 field, which MUST increment by one on each call 2078 to createOffer if the offer might differ from the output of the 2079 previous call to createOffer; implementations MAY opt to increment 2080 on every call. The value of the generated 2081 is independent of the of the 2082 current local description; in particular, in the case where the 2083 current version is N, an offer is created and applied with version 2084 N+1, and then that offer is rolled back so that the current 2085 version is again N, the next generated offer will still have 2086 version N+2. 2088 Note that if the application creates an offer by reading 2089 currentLocalDescription instead of calling createOffer, the returned 2090 SDP may be different than when setLocalDescription was originally 2091 called, due to the addition of gathered ICE candidates, but the 2092 will not have changed. There are no known 2093 scenarios in which this causes problems, but if this is a concern, 2094 the solution is simply to use createOffer to ensure a unique 2095 . 2097 If the previous offer was applied using setLocalDescription, but a 2098 corresponding answer from the remote side has not yet been applied, 2099 meaning the PeerConnection is still in the "have-local-offer" state, 2100 an offer is generated by following the steps in the "stable" state 2101 above, along with these exceptions: 2103 * The "s=" and "t=" lines MUST stay the same. 2105 * If any RtpTransceiver has been added and there exists an "m=" 2106 section with a zero port in the current local description or the 2107 current remote description, that "m=" section MUST be recycled by 2108 generating an "m=" section for the added RtpTransceiver as if the 2109 "m=" section were being added to the session description 2110 (including a new MID value) and placing it at the same index as 2111 the "m=" section with a zero port. 2113 * If an RtpTransceiver is stopped and is not associated with an "m=" 2114 section, an "m=" section MUST NOT be generated for it. This 2115 prevents adding back RtpTransceivers whose "m=" sections were 2116 recycled and used for a new RtpTransceiver in a previous offer/ 2117 answer exchange, as described above. 2119 * If an RtpTransceiver has been stopped and is associated with an 2120 "m=" section, and the "m=" section is not being recycled as 2121 described above, an "m=" section MUST be generated for it with the 2122 port set to zero and all "a=msid" lines removed. 2124 * For RtpTransceivers that are not stopped, the "a=msid" line or 2125 lines MUST stay the same if they are present in the current 2126 description, regardless of changes to the transceiver's direction 2127 or track. If no "a=msid" line is present in the current 2128 description, "a=msid" line(s) MUST be generated according to the 2129 same rules as for an initial offer. 2131 * Each "m=" and "c=" line MUST be filled in with the port, relevant 2132 RTP profile, and address of the default candidate for the "m=" 2133 section, as described in [RFC8839], Section 4.2.1.2 and clarified 2134 in Section 5.1.2. If no RTP candidates have yet been gathered, 2135 default values MUST still be used, as described above. 2137 * Each "a=mid" line MUST stay the same. 2139 * Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless 2140 the ICE configuration has changed (e.g., changes to either the 2141 supported STUN/TURN servers or the ICE candidate policy) or the 2142 IceRestart option (Section 5.2.3.1) was specified. If the "m=" 2143 section is bundled into another "m=" section, it still MUST NOT 2144 contain any ICE credentials. 2146 * If the "m=" section is not bundled into another "m=" section, its 2147 "a=rtcp" attribute line MUST be filled in with the port and 2148 address of the default RTCP candidate, as indicated in [RFC5761], 2149 Section 5.1.3. If no RTCP candidates have yet been gathered, 2150 default values MUST be used, as described in Section 5.2.1 above. 2152 * If the "m=" section is not bundled into another "m=" section, for 2153 each candidate that has been gathered during the most recent 2154 gathering phase (see Section 3.5.1), an "a=candidate" line MUST be 2155 added, as defined in [RFC8839], Section 5.1. If candidate 2156 gathering for the section has completed, an "a=end-of-candidates" 2157 attribute MUST be added, as described in [RFC8840], Section 8.2. 2158 If the "m=" section is bundled into another "m=" section, both 2159 "a=candidate" and "a=end-of-candidates" MUST be omitted. 2161 * For RtpTransceivers that are still present, the "a=rid" lines MUST 2162 stay the same. 2164 * For RtpTransceivers that are still present, any "a=simulcast" line 2165 MUST stay the same. 2167 If the previous offer was applied using setLocalDescription, and a 2168 corresponding answer from the remote side has been applied using 2169 setRemoteDescription, meaning the PeerConnection is in the "have- 2170 remote-pranswer" state or the "stable" state, an offer is generated 2171 based on the negotiated session descriptions by following the steps 2172 mentioned for the "have-local-offer" state above. 2174 In addition, for each existing, non-recycled, non-rejected "m=" 2175 section in the new offer, the following adjustments are made based on 2176 the contents of the corresponding "m=" section in the current local 2177 or remote description, as appropriate: 2179 * The "m=" line and corresponding "a=rtpmap" and "a=fmtp" lines MUST 2180 only include media formats that have not been excluded by the 2181 codec preferences of the associated transceiver and also MUST 2182 include all currently available formats. Media formats that were 2183 previously offered but are no longer available (e.g., a shared 2184 hardware codec) MAY be excluded. 2186 * Unless codec preferences have been set for the associated 2187 transceiver, the media formats on the "m=" line MUST be generated 2188 in the same order as in the most recent answer. Any media formats 2189 that were not present in the most recent answer MUST be added 2190 after all existing formats. 2192 * The RTP header extensions MUST only include those that are present 2193 in the most recent answer. 2195 * The RTCP feedback mechanisms MUST only include those that are 2196 present in the most recent answer, except for the case of format- 2197 specific mechanisms that are referencing a newly added media 2198 format. 2200 * The "a=rtcp" line MUST NOT be added if the most recent answer 2201 included an "a=rtcp-mux" line. 2203 * The "a=rtcp-mux" line MUST be the same as that in the most recent 2204 answer. 2206 * The "a=rtcp-mux-only" line MUST NOT be added. 2208 * The "a=rtcp-rsize" line MUST NOT be added unless present in the 2209 most recent answer. 2211 * An "a=bundle-only" line, as defined in [RFC9143], Section 6, MUST 2212 NOT be added. Instead, JSEP implementations MUST simply omit 2213 parameters in the IDENTICAL and TRANSPORT categories for bundled 2214 "m=" sections, as described in [RFC9143], Section 7.1.3. 2216 * Note that if media "m=" sections are bundled into a data "m=" 2217 section, then certain TRANSPORT and IDENTICAL attributes may 2218 appear in the data "m=" section even if they would otherwise only 2219 be appropriate for a media "m=" section (e.g., "a=rtcp-mux"). 2220 This cannot happen in initial offers because in the initial offer 2221 JSEP implementations always list media "m=" sections (if any) 2222 before the data "m=" section (if any), and at least one of those 2223 media "m=" sections will not have the "a=bundle-only" attribute. 2224 Therefore, in initial offers, any "a=bundle-only" "m=" sections 2225 will be bundled into a preceding non-bundle-only media "m=" 2226 section. 2228 The "a=group:BUNDLE" attribute MUST include the MID identifiers 2229 specified in the bundle group in the most recent answer, minus any 2230 "m=" sections that have been marked as rejected, plus any newly added 2231 or re-enabled "m=" sections. In other words, the bundle attribute 2232 MUST contain all "m=" sections that were previously bundled, as long 2233 as they are still alive, as well as any new "m=" sections. 2235 Note that if bundling has been negotiated, unbundling is no longer 2236 possible, and media sections will not be marked as bundle-only. This 2237 is by design, but could cause issues in the rare case of sending a 2238 subsequent offer as an initial offer to a non-bundle-aware endpoint 2239 via Third Party Call Control (3PCC), as discussed in [RFC9143], 2240 Section 7.6. 2242 "a=group:LS" attributes are generated in the same way as for initial 2243 offers, with the additional stipulation that any lip sync groups that 2244 were present in the most recent answer MUST continue to exist and 2245 MUST contain any previously existing MID identifiers, as long as the 2246 identified "m=" sections still exist and are not rejected, and the 2247 group still contains at least two MID identifiers. This ensures that 2248 any synchronized "recvonly" "m=" sections continue to be synchronized 2249 in the new offer. 2251 5.2.3. Options Handling 2253 The createOffer method takes as a parameter an RTCOfferOptions 2254 object. Special processing is performed when generating an SDP 2255 description if the following options are present. 2257 5.2.3.1. IceRestart 2259 If the IceRestart option is specified, with a value of "true", the 2260 offer MUST indicate an ICE restart by generating new ICE ufrag and 2261 pwd attributes, as specified in [RFC8839], Section 4.4.3.1.1. If 2262 this option is specified on an initial offer, it has no effect (since 2263 a new ICE ufrag and pwd are already generated). Similarly, if the 2264 ICE configuration has changed, this option has no effect, since new 2265 ufrag and pwd attributes will be generated automatically. This 2266 option is primarily useful for reestablishing connectivity in cases 2267 where failures are detected by the application. 2269 5.2.3.2. VoiceActivityDetection 2271 Silence suppression, also known as discontinuous transmission 2272 ("DTX"), can reduce the bandwidth used for audio by switching to a 2273 special encoding when voice activity is not detected, at the cost of 2274 some fidelity. 2276 If the "VoiceActivityDetection" option is specified, with a value of 2277 "true", the offer MUST indicate support for silence suppression in 2278 the audio it receives by including comfort noise ("CN") codecs for 2279 each offered audio codec, as specified in [RFC3389], Section 5.1, 2280 except for codecs that have their own internal silence suppression 2281 support. For codecs that have their own internal silence suppression 2282 support, the appropriate fmtp parameters for that codec MUST be 2283 specified to indicate that silence suppression for received audio is 2284 desired. For example, when using the Opus codec [RFC6716], the 2285 "usedtx=1" parameter, specified in [RFC7587], would be used in the 2286 offer. 2288 If the "VoiceActivityDetection" option is specified, with a value of 2289 "false", the JSEP implementation MUST NOT emit "CN" codecs. For 2290 codecs that have their own internal silence suppression support, the 2291 appropriate fmtp parameters for that codec MUST be specified to 2292 indicate that silence suppression for received audio is not desired. 2293 For example, when using the Opus codec, the "usedtx=0" parameter 2294 would be specified in the offer. In addition, the implementation 2295 MUST NOT use silence suppression for media it generates, regardless 2296 of whether the "CN" codecs or related fmtp parameters appear in the 2297 peer's description. The impact of these rules is that silence 2298 suppression in JSEP depends on mutual agreement of both sides, which 2299 ensures consistent handling regardless of which codec is used. 2301 The "VoiceActivityDetection" option does not have any impact on the 2302 setting of the "vad" value in the signaling of the client-to-mixer 2303 audio level header extension described in [RFC6464], Section 4. 2305 5.3. Generating an Answer 2307 When createAnswer is called, a new SDP description MUST be created 2308 that is compatible with the supplied remote description as well as 2309 the requirements specified in [RFC8834]. The exact details of this 2310 process are explained below. 2312 5.3.1. Initial Answers 2314 When createAnswer is called for the first time after a remote 2315 description has been provided, the result is known as the initial 2316 answer. If no remote description has been installed, an answer 2317 cannot be generated, and an error MUST be returned. 2319 Note that the remote description SDP may not have been created by a 2320 JSEP endpoint and may not conform to all the requirements listed in 2321 Section 5.2. For many cases, this is not a problem. However, if any 2322 mandatory SDP attributes are missing or functionality listed as 2323 mandatory-to-use above is not present, this MUST be treated as an 2324 error and MUST cause the affected "m=" sections to be marked as 2325 rejected. 2327 The first step in generating an initial answer is to generate 2328 session-level attributes. The process here is identical to that 2329 indicated in Section 5.2.1 above, except that the "a=ice-options" 2330 line, with the "trickle" option as specified in [RFC8840], 2331 Section 4.1.3 and the "ice2" option as specified in [RFC8445], 2332 Section 10, is only included if such an option was present in the 2333 offer. 2335 The next step is to generate session-level lip sync groups, as 2336 defined in [RFC5888], Section 7. For each group of type "LS" present 2337 in the offer, select the local RtpTransceivers that are referenced by 2338 the MID values in the specified group, and determine which of them 2339 either reference a common local MediaStream (specified in the calls 2340 to addTrack/addTransceiver used to create them) or have no 2341 MediaStream to reference because they were not created by addTrack/ 2342 addTransceiver. If at least two such RtpTransceivers exist, a group 2343 of type "LS" with the MID values of these RtpTransceivers MUST be 2344 added. Otherwise, the offered "LS" group MUST be ignored and no 2345 corresponding group generated in the answer. 2347 As a simple example, consider the following offer of a single audio 2348 and single video track contained in the same MediaStream. SDP lines 2349 not relevant to this example have been removed for clarity. As 2350 explained in Section 5.2, a group of type "LS" has been added that 2351 references each track's RtpTransceiver. 2353 a=group:LS a1 v1 2354 m=audio 10000 UDP/TLS/RTP/SAVPF 0 2355 a=mid:a1 2356 a=msid:ms1 2357 m=video 10001 UDP/TLS/RTP/SAVPF 96 2358 a=mid:v1 2359 a=msid:ms1 2361 If the answerer uses a single MediaStream when it adds its tracks, 2362 both of its transceivers will reference this stream, and so the 2363 subsequent answer will contain a "LS" group identical to that in the 2364 offer, as shown below: 2366 a=group:LS a1 v1 2367 m=audio 20000 UDP/TLS/RTP/SAVPF 0 2368 a=mid:a1 2369 a=msid:ms2 2370 m=video 20001 UDP/TLS/RTP/SAVPF 96 2371 a=mid:v1 2372 a=msid:ms2 2374 However, if the answerer groups its tracks into separate 2375 MediaStreams, its transceivers will reference different streams, and 2376 so the subsequent answer will not contain a "LS" group. 2378 m=audio 20000 UDP/TLS/RTP/SAVPF 0 2379 a=mid:a1 2380 a=msid:ms2a 2381 m=video 20001 UDP/TLS/RTP/SAVPF 96 2382 a=mid:v1 2383 a=msid:ms2b 2385 Finally, if the answerer does not add any tracks, its transceivers 2386 will not reference any MediaStreams, causing the preferences of the 2387 offerer to be maintained, and so the subsequent answer will contain 2388 an identical "LS" group. 2390 a=group:LS a1 v1 2391 m=audio 20000 UDP/TLS/RTP/SAVPF 0 2392 a=mid:a1 2393 a=recvonly 2394 m=video 20001 UDP/TLS/RTP/SAVPF 96 2395 a=mid:v1 2396 a=recvonly 2398 The example in Section 7.2 shows a more involved case of "LS" group 2399 generation. 2401 The next step is to generate a "m=" section for each "m=" section 2402 that is present in the remote offer, as specified in [RFC3264], 2403 Section 6. For the purposes of this discussion, any session-level 2404 attributes in the offer that are also valid as media-level attributes 2405 are considered to be present in each "m=" section. Each offered "m=" 2406 section will have an associated RtpTransceiver, as described in 2407 Section 5.10. If there are more RtpTransceivers than there are "m=" 2408 sections, the unmatched RtpTransceivers will need to be associated in 2409 a subsequent offer. 2411 For each offered "m=" section, if any of the following conditions are 2412 true, the corresponding "m=" section in the answer MUST be marked as 2413 rejected by setting the in the "m=" line to zero, as indicated 2414 in [RFC3264], Section 6, and further processing for this "m=" section 2415 can be skipped: 2417 * The associated RtpTransceiver has been stopped. 2419 * There is no offered media format that is both supported and, if 2420 applicable, allowed by codec preferences. 2422 * The bundle policy is "must-bundle", and this is not the first "m=" 2423 section or in the same bundle group as the first "m=" section. 2425 * The bundle policy is "balanced", and this is not the first "m=" 2426 section for this media type or in the same bundle group as the 2427 first "m=" section for this media type. 2429 * This "m=" section is in a bundle group, and the group's offerer 2430 tagged "m=" section is being rejected due to one of the above 2431 reasons. This requires all "m=" sections in the bundle group to 2432 be rejected, as specified in [RFC9143], Section 7.3.3. 2434 Otherwise, each "m=" section in the answer MUST then be generated as 2435 specified in [RFC3264], Section 6.1. For the "m=" line itself, the 2436 following rules MUST be followed: 2438 * The value would normally be set to the port of the default 2439 ICE candidate for this "m=" section, but given that no candidates 2440 are available yet, the default value of 9 (Discard) MUST be 2441 used, as indicated in [RFC8840], Section 4.1.1. 2443 * The field MUST be set to exactly match the field 2444 for the corresponding "m=" line in the offer. 2446 * If codec preferences have been set for the associated transceiver, 2447 media formats MUST be generated in the corresponding order, 2448 regardless of what was offered, and MUST exclude any codecs not 2449 present in the codec preferences. 2451 * Otherwise, the media formats on the "m=" line MUST be generated in 2452 the same order as those offered in the current remote description, 2453 excluding any currently unsupported formats. Any currently 2454 available media formats that are not present in the current remote 2455 description MUST be added after all existing formats. 2457 * In either case, the media formats in the answer MUST include at 2458 least one format that is present in the offer but MAY include 2459 formats that are locally supported but not present in the offer, 2460 as mentioned in [RFC3264], Section 6.1. If no common format 2461 exists, the "m=" section is rejected as described above. 2463 The "m=" line MUST be followed immediately by a "c=" line, as 2464 specified in [RFC4566], Section 5.7. Again, as no candidates are 2465 available yet, the "c=" line MUST contain the default value "IN IP4 2466 0.0.0.0", as defined in [RFC8840], Section 4.1.3. 2468 If the offer supports bundle, all "m=" sections to be bundled MUST 2469 use the same ICE credentials and candidates; all "m=" sections not 2470 being bundled MUST use unique ICE credentials and candidates. Each 2471 "m=" section MUST contain the following attributes (which are of 2472 attribute types other than IDENTICAL or TRANSPORT): 2474 * If and only if present in the offer, an "a=mid" line, as specified 2475 in [RFC5888], Section 9.1. The MID value MUST match that 2476 specified in the offer. 2478 * A direction attribute, determined by applying the rules regarding 2479 the offered direction specified in [RFC3264], Section 6.1, and 2480 then intersecting with the direction of the associated 2481 RtpTransceiver. For example, in the case where an "m=" section is 2482 offered as "sendonly" and the local transceiver is set to 2483 "sendrecv", the result in the answer is a "recvonly" direction. 2485 * For each media format on the "m=" line, "a=rtpmap" and "a=fmtp" 2486 lines, as specified in [RFC4566], Section 6 and [RFC3264], 2487 Section 6.1. 2489 * If "rtx" is present in the offer, for each primary codec where RTP 2490 retransmission should be used, a corresponding "a=rtpmap" line 2491 indicating "rtx" with the clock rate of the primary codec and an 2492 "a=fmtp" line that references the payload type of the primary 2493 codec, as specified in [RFC4588], Section 8.1. 2495 * For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, 2496 as specified in [RFC4566], Section 6. The FEC mechanisms that 2497 MUST be supported are specified in [RFC8854], Section 7, and 2498 specific usage for each media type is outlined in Sections 4 and 2499 5. 2501 * If this "m=" section is for media with configurable durations of 2502 media per packet, e.g., audio, an "a=maxptime" line, as described 2503 in Section 5.2. 2505 * If this "m=" section is for video media and there are known 2506 limitations on the size of images that can be decoded, an 2507 "a=imageattr" line, as specified in Section 3.6. 2509 * For each supported RTP header extension that is present in the 2510 offer, an "a=extmap" line, as specified in [RFC5285], Section 5. 2511 The list of header extensions that SHOULD/MUST be supported is 2512 specified in [RFC8834], Section 5.2. Any header extensions that 2513 require encryption MUST be specified as indicated in [RFC6904], 2514 Section 4. 2516 * For each supported RTCP feedback mechanism that is present in the 2517 offer, an "a=rtcp-fb" line, as specified in [RFC4585], 2518 Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ 2519 MUST be supported is specified in [RFC8834], Section 5.1. 2521 * If the RtpTransceiver has a sendrecv or sendonly direction: 2523 - For each MediaStream that was associated with the transceiver 2524 when it was created via addTrack or addTransceiver, an "a=msid" 2525 line, as specified in [RFC8830], Section 2, but omitting the 2526 "appdata" field. 2528 Each "m=" section that is not bundled into another "m=" section MUST 2529 contain the following attributes (which are of category IDENTICAL or 2530 TRANSPORT): 2532 * "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC8839], 2533 Section 5.4. 2535 * For each desired digest algorithm, one or more "a=fingerprint" 2536 lines for each of the endpoint's certificates, as specified in 2537 [RFC8122], Section 5. 2539 * An "a=setup" line, as specified in [RFC4145], Section 4 and 2540 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 2541 The role value in the answer MUST be "active" or "passive". When 2542 the offer contains the "actpass" value, as will always be the case 2543 with JSEP endpoints, the answerer SHOULD use the "active" role. 2544 Offers from non-JSEP endpoints MAY send other values for 2545 "a=setup", in which case the answer MUST use a value consistent 2546 with the value in the offer. 2548 * An "a=tls-id" line, as specified in [RFC8842], Section 5.3. 2550 * If present in the offer, an "a=rtcp-mux" line, as specified in 2551 [RFC5761], Section 5.1.3. Otherwise, an "a=rtcp" line, as 2552 specified in [RFC3605], Section 2.1, containing the default value 2553 "9 IN IP4 0.0.0.0" (because no candidates have yet been gathered). 2555 * If present in the offer, an "a=rtcp-rsize" line, as specified in 2556 [RFC5506], Section 5. 2558 If a data channel "m=" section has been offered, an "m=" section MUST 2559 also be generated for data. The field MUST be set to 2560 "application", and the and fields MUST be set to 2561 exactly match the fields in the offer. 2563 Within the data "m=" section, an "a=mid" line MUST be generated and 2564 included as described above, along with an "a=sctp-port" line 2565 referencing the SCTP port number, as defined in [RFC8841], 2566 Section 5.1; and, if appropriate, an "a=max-message-size" line, as 2567 defined in [RFC8841], Section 6.1. 2569 As discussed above, the following attributes of category IDENTICAL or 2570 TRANSPORT are included only if the data "m=" section is not bundled 2571 into another "m=" section: 2573 * "a=ice-ufrag" 2575 * "a=ice-pwd" 2577 * "a=fingerprint" 2579 * "a=setup" 2581 * "a=tls-id" 2583 Note that if media "m=" sections are bundled into a data "m=" 2584 section, then certain TRANSPORT and IDENTICAL attributes may also 2585 appear in the data "m=" section even if they would otherwise only be 2586 appropriate for a media "m=" section (e.g., "a=rtcp-mux"). 2588 If "a=group" attributes with semantics of "BUNDLE" are offered, 2589 corresponding session-level "a=group" attributes MUST be added as 2590 specified in [RFC5888]. These attributes MUST have semantics 2591 "BUNDLE" and MUST include all mid identifiers from the offered bundle 2592 groups that have not been rejected. Note that regardless of the 2593 presence of "a=bundle-only" in the offer, all "m=" sections in the 2594 answer MUST NOT have an "a=bundle-only" line. 2596 Attributes that are common between all "m=" sections MAY be moved to 2597 the session level if explicitly defined to be valid at the session 2598 level. 2600 The attributes prohibited in the creation of offers are also 2601 prohibited in the creation of answers. 2603 5.3.2. Subsequent Answers 2605 When createAnswer is called a second (or later) time or is called 2606 after a local description has already been installed, the processing 2607 is somewhat different than for an initial answer. 2609 If the previous answer was not applied using setLocalDescription, 2610 meaning the PeerConnection is still in the "have-remote-offer" state, 2611 the steps for generating an initial answer MUST be followed, subject 2612 to the following restriction: 2614 * The fields of the "o=" line MUST stay the same except for the 2615 field, which MUST increment if the session 2616 description changes in any way from the previously generated 2617 answer. 2619 If any session description was previously supplied to 2620 setLocalDescription, an answer is generated by following the steps in 2621 the "have-remote-offer" state above, along with these exceptions: 2623 * The "s=" and "t=" lines MUST stay the same. 2625 * Each "m=" and "c=" line MUST be filled in with the port and 2626 address of the default candidate for the "m=" section, as 2627 described in [RFC8839], Section 4.2.1.2. Note that in certain 2628 cases, the "m=" line protocol may not match that of the default 2629 candidate, because the "m=" line protocol value MUST match what 2630 was supplied in the offer, as described above. 2632 * Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless 2633 the "m=" section is restarting, in which case new ICE credentials 2634 MUST be created as specified in [RFC8839], Section 4.4.1.1.1. If 2635 the "m=" section is bundled into another "m=" section, it still 2636 MUST NOT contain any ICE credentials. 2638 * Each "a=tls-id" line MUST stay the same, unless the offerer's 2639 "a=tls-id" line changed, in which case a new tls-id value MUST be 2640 created, as described in [RFC8842], Section 5.2. 2642 * Each "a=setup" line MUST use an "active" or "passive" role value 2643 consistent with the existing DTLS association, if the association 2644 is being continued by the offerer. 2646 * RTCP multiplexing MUST be used, and an "a=rtcp-mux" line inserted 2647 if and only if the "m=" section previously used RTCP multiplexing. 2649 * If the "m=" section is not bundled into another "m=" section and 2650 RTCP multiplexing is not active, an "a=rtcp" attribute line MUST 2651 be filled in with the port and address of the default RTCP 2652 candidate. If no RTCP candidates have yet been gathered, default 2653 values MUST be used, as described in Section 5.3.1 above. 2655 * If the "m=" section is not bundled into another "m=" section, for 2656 each candidate that has been gathered during the most recent 2657 gathering phase (see Section 3.5.1), an "a=candidate" line MUST be 2658 added, as defined in [RFC8839], Section 5.1. If candidate 2659 gathering for the section has completed, an "a=end-of-candidates" 2660 attribute MUST be added, as described in [RFC8840], Section 8.2. 2661 If the "m=" section is bundled into another "m=" section, both 2662 "a=candidate" and "a=end-of-candidates" MUST be omitted. 2664 * For RtpTransceivers that are not stopped, the "a=msid" line(s) 2665 MUST stay the same, regardless of changes to the transceiver's 2666 direction or track. If no "a=msid" line is present in the current 2667 description, "a=msid" line(s) MUST be generated according to the 2668 same rules as for an initial answer. 2670 5.3.3. Options Handling 2672 The createAnswer method takes as a parameter an RTCAnswerOptions 2673 object. The set of parameters for RTCAnswerOptions is different than 2674 those supported in RTCOfferOptions; the IceRestart option is 2675 unnecessary, as ICE credentials will automatically be changed for all 2676 "m=" sections where the offerer chose to perform ICE restart. 2678 The following options are supported in RTCAnswerOptions. 2680 5.3.3.1. VoiceActivityDetection 2682 Silence suppression in the answer is handled as described in 2683 Section 5.2.3.2, with one exception: if support for silence 2684 suppression was not indicated in the offer, the 2685 VoiceActivityDetection parameter has no effect, and the answer MUST 2686 be generated as if VoiceActivityDetection was set to "false". This 2687 is done on a per-codec basis (e.g., if the offerer somehow offered 2688 support for CN but set "usedtx=0" for Opus, setting 2689 VoiceActivityDetection to "true" would result in an answer with CN 2690 codecs and "usedtx=0"). The impact of this rule is that an answerer 2691 will not try to use silence suppression with any endpoint that does 2692 not offer it, making silence suppression support bilateral even with 2693 non-JSEP endpoints. 2695 5.4. Modifying an Offer or Answer 2697 The SDP returned from createOffer or createAnswer MUST NOT be changed 2698 before passing it to setLocalDescription. If precise control over 2699 the SDP is needed, the aforementioned createOffer/createAnswer 2700 options or RtpTransceiver APIs MUST be used. 2702 After calling setLocalDescription with an offer or answer, the 2703 application MAY modify the SDP to reduce its capabilities before 2704 sending it to the far side, as long as it follows the rules above 2705 that define a valid JSEP offer or answer. Likewise, an application 2706 that has received an offer or answer from a peer MAY modify the 2707 received SDP, subject to the same constraints, before calling 2708 setRemoteDescription. 2710 As always, the application is solely responsible for what it sends to 2711 the other party, and all incoming SDP will be processed by the JSEP 2712 implementation to the extent of its capabilities. It is an error to 2713 assume that all SDP is well formed; however, one should be able to 2714 assume that any implementation of this specification will be able to 2715 process, as a remote offer or answer, unmodified SDP coming from any 2716 other implementation of this specification. 2718 5.5. Processing a Local Description 2720 When a SessionDescription is supplied to setLocalDescription, the 2721 following steps MUST be performed: 2723 * If the description is of type "rollback", follow the processing 2724 defined in Section 5.7 and skip the processing described in the 2725 rest of this section. 2727 * Otherwise, the type of the SessionDescription is checked against 2728 the current state of the PeerConnection: 2730 - If the type is "offer", the PeerConnection state MUST be either 2731 "stable" or "have-local-offer". 2733 - If the type is "pranswer" or "answer", the PeerConnection state 2734 MUST be either "have-remote-offer" or "have-local-pranswer". 2736 * If the type is not correct for the current state, processing MUST 2737 stop and an error MUST be returned. 2739 * The SessionDescription is then checked to ensure that its contents 2740 are identical to those generated in the last call to createOffer/ 2741 createAnswer, and thus have not been altered, as discussed in 2742 Section 5.4; otherwise, processing MUST stop and an error MUST be 2743 returned. 2745 * Next, the SessionDescription is parsed into a data structure, as 2746 described in Section 5.8 below. 2748 * Finally, the parsed SessionDescription is applied as described in 2749 Section 5.9 below. 2751 5.6. Processing a Remote Description 2753 When a SessionDescription is supplied to setRemoteDescription, the 2754 following steps MUST be performed: 2756 * If the description is of type "rollback", follow the processing 2757 defined in Section 5.7 and skip the processing described in the 2758 rest of this section. 2760 * Otherwise, the type of the SessionDescription is checked against 2761 the current state of the PeerConnection: 2763 - If the type is "offer", the PeerConnection state MUST be either 2764 "stable" or "have-remote-offer". 2766 - If the type is "pranswer" or "answer", the PeerConnection state 2767 MUST be either "have-local-offer" or "have-remote-pranswer". 2769 * If the type is not correct for the current state, processing MUST 2770 stop and an error MUST be returned. 2772 * Next, the SessionDescription is parsed into a data structure, as 2773 described in Section 5.8 below. If parsing fails for any reason, 2774 processing MUST stop and an error MUST be returned. 2776 * Finally, the parsed SessionDescription is applied as described in 2777 Section 5.10 below. 2779 5.7. Processing a Rollback 2781 A rollback may be performed if the PeerConnection is in any state 2782 except for "stable". This means that both offers and provisional 2783 answers can be rolled back. Rollback can only be used to cancel 2784 proposed changes; there is no support for rolling back from a 2785 "stable" state to a previous "stable" state. If a rollback is 2786 attempted in the "stable" state, processing MUST stop and an error 2787 MUST be returned. Note that this implies that once the answerer has 2788 performed setLocalDescription with its answer, this cannot be rolled 2789 back. 2791 The effect of rollback MUST be the same regardless of whether 2792 setLocalDescription or setRemoteDescription is called. 2794 In order to process rollback, a JSEP implementation abandons the 2795 current offer/answer transaction, sets the signaling state to 2796 "stable", and sets the pending local and/or remote description (see 2797 Sections 4.1.14 and 4.1.16) to "null". Any resources or candidates 2798 that were allocated by the abandoned local description are discarded; 2799 any media that is received is processed according to the previous 2800 local and remote descriptions. 2802 A rollback disassociates any RtpTransceivers that were associated 2803 with "m=" sections by the application of the rolled-back session 2804 description (see Sections 5.10 and 5.9). This means that some 2805 RtpTransceivers that were previously associated will no longer be 2806 associated with any "m=" section; in such cases, the value of the 2807 RtpTransceiver's mid property MUST be set to "null", and the mapping 2808 between the transceiver and its "m=" section index MUST be discarded. 2809 RtpTransceivers that were created by applying a remote offer that was 2810 subsequently rolled back MUST be stopped and removed from the 2811 PeerConnection. However, an RtpTransceiver MUST NOT be removed if a 2812 track was attached to the RtpTransceiver via the addTrack method. 2813 This is so that an application may call addTrack, then call 2814 setRemoteDescription with an offer, then roll back that offer, then 2815 call createOffer and have an "m=" section for the added track appear 2816 in the generated offer. 2818 5.8. Parsing a Session Description 2820 The SDP contained in the session description object consists of a 2821 sequence of text lines, each containing a key-value expression, as 2822 described in [RFC4566], Section 5. The SDP is read, line by line, 2823 and converted to a data structure that contains the deserialized 2824 information. However, SDP allows many types of lines, not all of 2825 which are relevant to JSEP applications. For each line, the 2826 implementation will first ensure that it is syntactically correct 2827 according to its defining ABNF, check that it conforms to the 2828 semantics used in [RFC4566] and [RFC3264], and then either parse and 2829 store or discard the provided value, as described below. 2831 If any line is not well formed or cannot be parsed as described, the 2832 parser MUST stop with an error and reject the session description, 2833 even if the value is to be discarded. This ensures that 2834 implementations do not accidentally misinterpret ambiguous SDP. 2836 5.8.1. Session-Level Parsing 2838 First, the session-level lines are checked and parsed. These lines 2839 MUST occur in a specific order, and with a specific syntax, as 2840 defined in [RFC4566], Section 5. Note that while the specific line 2841 types (e.g., "v=", "c=") MUST occur in the defined order, lines of 2842 the same type (typically "a=") can occur in any order. 2844 The following non-attribute lines are not meaningful in the JSEP 2845 context and MAY be discarded once they have been checked. 2847 * The "c=" line MUST be checked for syntax, but its value is only 2848 used for ICE mismatch detection, as defined in [RFC8445], 2849 Section 5.4. Note that JSEP implementations should never 2850 encounter this condition because ICE is required for WebRTC. 2852 * The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines MUST 2853 be checked for syntax, but their values are not otherwise used. 2855 The remaining non-attribute lines are processed as follows: 2857 * The "v=" line MUST have a version of 0, as specified in [RFC4566], 2858 Section 5.1. 2860 * The "o=" line MUST be parsed as specified in [RFC4566], 2861 Section 5.2. 2863 * The "b=" line, if present, MUST be parsed as specified in 2864 [RFC4566], Section 5.8, and the bwtype and bandwidth values 2865 stored. 2867 Finally, the attribute lines are processed. Specific processing MUST 2868 be applied for the following session-level attribute ("a=") lines: 2870 * Any "a=group" lines are parsed as specified in [RFC5888], 2871 Section 5, and the group's semantics and mids are stored. 2873 * If present, a single "a=ice-lite" line is parsed as specified in 2874 [RFC8839], Section 5.3, and a value indicating the presence of 2875 ice-lite is stored. 2877 * If present, a single "a=ice-ufrag" line is parsed as specified in 2878 [RFC8839], Section 5.4, and the ufrag value is stored. 2880 * If present, a single "a=ice-pwd" line is parsed as specified in 2881 [RFC8839], Section 5.4, and the password value is stored. 2883 * If present, a single "a=ice-options" line is parsed as specified 2884 in [RFC8839], Section 5.6, and the set of specified options is 2885 stored. 2887 * Any "a=fingerprint" lines are parsed as specified in [RFC8122], 2888 Section 5, and the set of fingerprint and algorithm values is 2889 stored. 2891 * If present, a single "a=setup" line is parsed as specified in 2892 [RFC4145], Section 4, and the setup value is stored. 2894 * If present, a single "a=tls-id" line is parsed as specified in 2895 [RFC8842], Section 5, and the attribute value is stored. 2897 * Any "a=identity" lines are parsed and the identity values stored 2898 for subsequent verification, as specified in [RFC8827], Section 5. 2900 * Any "a=extmap" lines are parsed as specified in [RFC5285], 2901 Section 5, and their values are stored. 2903 Other attributes that are not relevant to JSEP may also be present, 2904 and implementations SHOULD process any that they recognize. As 2905 required by [RFC4566], Section 5.13, unknown attribute lines MUST be 2906 ignored. 2908 Once all the session-level lines have been parsed, processing 2909 continues with the lines in "m=" sections. 2911 5.8.2. Media Section Parsing 2913 Like the session-level lines, the media section lines MUST occur in 2914 the specific order and with the specific syntax defined in [RFC4566], 2915 Section 5. 2917 The "m=" line itself MUST be parsed as described in [RFC4566], 2918 Section 5.14, and the , , , and values 2919 stored. 2921 Following the "m=" line, specific processing MUST be applied for the 2922 following non-attribute lines: 2924 * As with the "c=" line at the session level, the "c=" line MUST be 2925 parsed according to [RFC4566], Section 5.7, but its value is not 2926 used. 2928 * The "b=" line, if present, MUST be parsed as specified in 2929 [RFC4566], Section 5.8, and the bwtype and bandwidth values 2930 stored. 2932 Specific processing MUST also be applied for the following attribute 2933 lines: 2935 * If present, a single "a=ice-ufrag" line is parsed as specified in 2936 [RFC8839], Section 5.4, and the ufrag value is stored. 2938 * If present, a single "a=ice-pwd" line is parsed as specified in 2939 [RFC8839], Section 5.4, and the password value is stored. 2941 * If present, a single "a=ice-options" line is parsed as specified 2942 in [RFC8839], Section 5.6, and the set of specified options is 2943 stored. 2945 * Any "a=candidate" attributes MUST be parsed as specified in 2946 [RFC8839], Section 5.1, and their values stored. 2948 * Any "a=remote-candidates" attributes MUST be parsed as specified 2949 in [RFC8839], Section 5.2, but their values are ignored. 2951 * If present, a single "a=end-of-candidates" attribute MUST be 2952 parsed as specified in [RFC8840], Section 8.1, and its presence or 2953 absence flagged and stored. 2955 * Any "a=fingerprint" lines are parsed as specified in [RFC8122], 2956 Section 5, and the set of fingerprint and algorithm values is 2957 stored. 2959 If the "m=" value indicates use of RTP, as described in 2960 Section 5.1.2 above, the following attribute lines MUST be processed: 2962 * The "m=" value MUST be parsed as specified in [RFC4566], 2963 Section 5.14, and the individual values stored. 2965 * Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in 2966 [RFC4566], Section 6, and their values stored. 2968 * If present, a single "a=ptime" line MUST be parsed as described in 2969 [RFC4566], Section 6, and its value stored. 2971 * If present, a single "a=maxptime" line MUST be parsed as described 2972 in [RFC4566], Section 6, and its value stored. 2974 * If present, a single direction attribute line (e.g., "a=sendrecv") 2975 MUST be parsed as described in [RFC4566], Section 6, and its value 2976 stored. 2978 * Any "a=ssrc" attributes MUST be parsed as specified in [RFC5576], 2979 Section 4.1, and their values stored. 2981 * Any "a=extmap" attributes MUST be parsed as specified in 2982 [RFC5285], Section 5, and their values stored. 2984 * Any "a=rtcp-fb" attributes MUST be parsed as specified in 2985 [RFC4585], Section 4.2, and their values stored. 2987 * If present, a single "a=rtcp-mux" attribute MUST be parsed as 2988 specified in [RFC5761], Section 5.1.3, and its presence or absence 2989 flagged and stored. 2991 * If present, a single "a=rtcp-mux-only" attribute MUST be parsed as 2992 specified in [RFC8858], Section 3, and its presence or absence 2993 flagged and stored. 2995 * If present, a single "a=rtcp-rsize" attribute MUST be parsed as 2996 specified in [RFC5506], Section 5, and its presence or absence 2997 flagged and stored. 2999 * If present, a single "a=rtcp" attribute MUST be parsed as 3000 specified in [RFC3605], Section 2.1, but its value is ignored, as 3001 this information is superfluous when using ICE. 3003 * If present, "a=msid" attributes MUST be parsed as specified in 3004 [RFC8830], Section 3.2, and their values stored, ignoring any 3005 "appdata" field. If no "a=msid" attributes are present, a random 3006 msid-id value is generated for a "default" MediaStream for the 3007 session, if not already present, and this value is stored. 3009 * Any "a=imageattr" attributes MUST be parsed as specified in 3010 [RFC6236], Section 3, and their values stored. 3012 * Any "a=rid" lines MUST be parsed as specified in [RFC8851], 3013 Section 10, and their values stored. 3015 * If present, a single "a=simulcast" line MUST be parsed as 3016 specified in [RFC8853], and its values stored. 3018 Otherwise, if the "m=" value indicates use of SCTP, the 3019 following attribute lines MUST be processed: 3021 * The "m=" value MUST be parsed as specified in [RFC8841], 3022 Section 4.3, and the application protocol value stored. 3024 * An "a=sctp-port" attribute MUST be present, and it MUST be parsed 3025 as specified in [RFC8841], Section 5.2, and the value stored. 3027 * If present, a single "a=max-message-size" attribute MUST be parsed 3028 as specified in [RFC8841], Section 6, and the value stored. 3029 Otherwise, use the specified default. 3031 Other attributes that are not relevant to JSEP may also be present, 3032 and implementations SHOULD process any that they recognize. As 3033 required by [RFC4566], Section 5.13, unknown attribute lines MUST be 3034 ignored. 3036 5.8.3. Semantics Verification 3038 Assuming that parsing completes successfully, the parsed description 3039 is then evaluated to ensure internal consistency as well as proper 3040 support for mandatory features. Specifically, the following checks 3041 are performed: 3043 * For each "m=" section, valid values for each of the mandatory-to- 3044 use features enumerated in Section 5.1.1 MUST be present. These 3045 values MAY be either present at the media level or inherited from 3046 the session level. 3048 - ICE ufrag and password values, which MUST comply with the size 3049 limits specified in [RFC8839], Section 5.4. 3051 - A tls-id value, which MUST be set according to [RFC8842], 3052 Section 5. If this is a re-offer or a response to a re-offer 3053 and the tls-id value is different from that presently in use, 3054 the DTLS connection is not being continued and the remote 3055 description MUST be part of an ICE restart, together with new 3056 ufrag and password values. 3058 - A DTLS setup value, which MUST be set according to the rules 3059 specified in [RFC5763], Section 5 and MUST be consistent with 3060 the selected role of the current DTLS connection, if one exists 3061 and is being continued. 3063 - DTLS fingerprint values, where at least one fingerprint MUST be 3064 present. 3066 * All rid-ids referenced in an "a=simulcast" line MUST exist as 3067 "a=rid" lines. 3069 * Each "m=" section is also checked to ensure that prohibited 3070 features are not used. 3072 * If the RTP/RTCP multiplexing policy is "require", each "m=" 3073 section MUST contain an "a=rtcp-mux" attribute. If an "m=" 3074 section contains an "a=rtcp-mux-only" attribute, that section MUST 3075 also contain an "a=rtcp-mux" attribute. 3077 * If an "m=" section was present in the previous answer, the state 3078 of RTP/RTCP multiplexing MUST match what was previously 3079 negotiated. 3081 If this session description is of type "pranswer" or "answer", the 3082 following additional checks are applied: 3084 * The session description MUST follow the rules defined in 3085 [RFC3264], Section 6, including the requirement that the number of 3086 "m=" sections MUST exactly match the number of "m=" sections in 3087 the associated offer. 3089 * For each "m=" section, the media type and protocol values MUST 3090 exactly match the media type and protocol values in the 3091 corresponding "m=" section in the associated offer. 3093 If any of the preceding checks failed, processing MUST stop and an 3094 error MUST be returned. 3096 5.9. Applying a Local Description 3098 The following steps are performed at the media engine level to apply 3099 a local description. If an error is returned, the session MUST be 3100 restored to the state it was in before performing these steps. 3102 First, "m=" sections are processed. For each "m=" section, the 3103 following steps MUST be performed; if any parameters are out of 3104 bounds or cannot be applied, processing MUST stop and an error MUST 3105 be returned. 3107 * If this "m=" section is new, begin gathering candidates for it, as 3108 defined in [RFC8445], Section 5.1.1, unless it is definitively 3109 being bundled (either (1) this is an offer and the "m=" section is 3110 marked as bundle-only or (2) it is an answer and the "m=" section 3111 is bundled into another "m=" section). 3113 * Or, if the ICE ufrag and password values have changed, trigger the 3114 ICE agent to start an ICE restart as described in [RFC8445], 3115 Section 9, and begin gathering new candidates for the "m=" 3116 section. If this description is an answer, also start checks on 3117 that media section. 3119 * If the "m=" section value indicates use of RTP: 3121 - If there is no RtpTransceiver associated with this "m=" 3122 section, find one and associate it with this "m=" section 3123 according to the following steps. Note that this situation 3124 will only occur when applying an offer. 3126 o Find the RtpTransceiver that corresponds to this "m=" 3127 section, using the mapping between transceivers and "m=" 3128 section indices established when creating the offer. 3130 o Set the value of this RtpTransceiver's mid property to the 3131 MID of the "m=" section. 3133 - If RTCP mux is indicated, prepare to demux RTP and RTCP from 3134 the RTP ICE component, as specified in [RFC5761], 3135 Section 5.1.3. 3137 - For each specified RTP header extension, establish a mapping 3138 between the extension ID and URI, as described in [RFC5285], 3139 Section 6. 3141 - If the MID header extension is supported, prepare to demux RTP 3142 streams intended for this "m=" section based on the MID header 3143 extension, as described in [RFC9143], Section 15. 3145 - For each specified media format, establish a mapping between 3146 the payload type and the actual media format, as described in 3147 [RFC3264], Section 6.1. In addition, prepare to demux RTP 3148 streams intended for this "m=" section based on the media 3149 formats supported by this "m=" section, as described in 3150 [RFC9143], Section 9.2. 3152 - For each specified "rtx" media format, establish a mapping 3153 between the RTX payload type and its associated primary payload 3154 type, as described in Sections 8.6 and 8.7 of [RFC4588]. 3156 - If the direction attribute is of type "sendrecv" or "recvonly", 3157 enable receipt and decoding of media. 3159 Finally, if this description is of type "pranswer" or "answer", 3160 follow the processing defined in Section 5.11 below. 3162 5.10. Applying a Remote Description 3164 The following steps are performed to apply a remote description. If 3165 an error is returned, the session MUST be restored to the state it 3166 was in before performing these steps. 3168 If the answer contains any "a=ice-options" attributes where "trickle" 3169 is listed as an attribute, update the PeerConnection 3170 canTrickleIceCandidates property to be "true". Otherwise, set this 3171 property to "false". 3173 The following steps MUST be performed for attributes at the session 3174 level; if any parameters are out of bounds or cannot be applied, 3175 processing MUST stop and an error MUST be returned. 3177 * For any specified "CT" bandwidth value, set this value as the 3178 limit for the maximum total bitrate for all "m=" sections, as 3179 specified in [RFC4566], Section 5.8. Within this overall limit, 3180 the implementation can dynamically decide how to best allocate the 3181 available bandwidth between "m=" sections, respecting any specific 3182 limits that have been specified for individual "m=" sections. 3184 * For any specified "RR" or "RS" bandwidth values, handle as 3185 specified in [RFC3556], Section 2. 3187 * Any "AS" bandwidth value ([RFC4566], Section 5.8) MUST be ignored, 3188 as the meaning of this construct at the session level is not well 3189 defined. 3191 For each "m=" section, the following steps MUST be performed; if any 3192 parameters are out of bounds or cannot be applied, processing MUST 3193 stop and an error MUST be returned. 3195 * If the ICE ufrag or password changed from the previous remote 3196 description: 3198 - If the description is of type "offer", the implementation MUST 3199 note that an ICE restart is needed, as described in [RFC8839], 3200 Section 4.4.1.1.1. 3202 - If the description is of type "answer" or "pranswer", then 3203 check to see if the current local description is an ICE 3204 restart, and if not, generate an error. If the PeerConnection 3205 state is "have-remote-pranswer" and the ICE ufrag or password 3206 changed from the previous provisional answer, then signal the 3207 ICE agent to discard any previous ICE checklist state for the 3208 "m=" section. Finally, signal the ICE agent to begin checks. 3210 * If the current local description indicates an ICE restart but 3211 neither the ICE ufrag nor the password has changed from the 3212 previous remote description (as prescribed by [RFC8445], 3213 Section 9), generate an error. 3215 * Configure the ICE components associated with this media section to 3216 use the supplied ICE remote ufrag and password for their 3217 connectivity checks. 3219 * Pair any supplied ICE candidates with any gathered local 3220 candidates, as described in [RFC8445], Section 6.1.2, and start 3221 connectivity checks with the appropriate credentials. 3223 * If an "a=end-of-candidates" attribute is present, process the end- 3224 of-candidates indication as described in [RFC8838], Section 14. 3226 * If the "m=" section value indicates use of RTP: 3228 - If the "m=" section is being recycled (see Section 5.2.2), 3229 disassociate the currently associated RtpTransceiver by setting 3230 its mid property to "null", and discard the mapping between the 3231 transceiver and its "m=" section index. 3233 - If the "m=" section is not associated with any RtpTransceiver 3234 (possibly because it was disassociated in the previous step), 3235 either find an RtpTransceiver or create one according to the 3236 following steps: 3238 o If the "m=" section is sendrecv or recvonly, and there are 3239 RtpTransceivers of the same type that were added to the 3240 PeerConnection by addTrack and are not associated with any 3241 "m=" section and are not stopped, find the first (according 3242 to the canonical order described in Section 5.2.1) such 3243 RtpTransceiver. 3245 o If no RtpTransceiver was found in the previous step, create 3246 one with a recvonly direction. 3248 o Associate the found or created RtpTransceiver with the "m=" 3249 section by setting the value of the RtpTransceiver's mid 3250 property to the MID of the "m=" section, and establish a 3251 mapping between the transceiver and the index of the "m=" 3252 section. If the "m=" section does not include a MID (i.e., 3253 the remote endpoint does not support the MID extension), 3254 generate a value for the RtpTransceiver mid property, 3255 following the guidance for "a=mid" mentioned in 3256 Section 5.2.1. 3258 - For each specified media format that is also supported by the 3259 local implementation, establish a mapping between the specified 3260 payload type and the media format, as described in [RFC3264], 3261 Section 6.1. Specifically, this means that the implementation 3262 records the payload type to be used in outgoing RTP packets 3263 when sending each specified media format, as well as the 3264 relative preference for each format that is indicated in their 3265 ordering. If any indicated media format is not supported by 3266 the local implementation, it MUST be ignored. 3268 - For each specified "rtx" media format, establish a mapping 3269 between the RTX payload type and its associated primary payload 3270 type, as described in [RFC4588], Section 4. If any referenced 3271 primary payload types are not present, this MUST result in an 3272 error. Note that RTX payload types may refer to primary 3273 payload types that are not supported by the local media 3274 implementation, in which case the RTX payload type MUST also be 3275 ignored. 3277 - For each specified fmtp parameter that is supported by the 3278 local implementation, enable them on the associated media 3279 formats. 3281 - For each specified Synchronization Source (SSRC) that is 3282 signaled in the "m=" section, prepare to demux RTP streams 3283 intended for this "m=" section using that SSRC, as described in 3284 [RFC9143], Section 9.2. 3286 - For each specified RTP header extension that is also supported 3287 by the local implementation, establish a mapping between the 3288 extension ID and URI, as described in [RFC5285], Section 5. 3289 Specifically, this means that the implementation records the 3290 extension ID to be used in outgoing RTP packets when sending 3291 each specified header extension. If any indicated RTP header 3292 extension is not supported by the local implementation, it MUST 3293 be ignored. 3295 - For each specified RTCP feedback mechanism that is supported by 3296 the local implementation, enable them on the associated media 3297 formats. 3299 - For any specified "TIAS" ("Transport Independent Application 3300 Specific Maximum") bandwidth value, set this value as a 3301 constraint on the maximum RTP bitrate to be used when sending 3302 media, as specified in [RFC3890]. If a "TIAS" value is not 3303 present but an "AS" value is specified, generate a "TIAS" value 3304 using this formula: 3306 TIAS = AS * 1000 * 0.95 - (50 * 40 * 8) 3308 The 1000 changes the unit from kbps to bps (as required by 3309 TIAS), and the 0.95 is to allocate 5% to RTCP. An estimate of 3310 header overhead is then subtracted out, in which the 50 is 3311 based on 50 packets per second, the 40 is based on typical 3312 header size (in bytes), and the 8 converts bytes to bits. Note 3313 that "TIAS" is preferred over "AS" because it provides more 3314 accurate control of bandwidth. 3316 - For any "RR" or "RS" bandwidth values, handle as specified in 3317 [RFC3556], Section 2. 3319 - Any specified "CT" bandwidth value MUST be ignored, as the 3320 meaning of this construct at the media level is not well 3321 defined. 3323 - If the "m=" section is of type "audio": 3325 o For each specified "CN" media format, configure silence 3326 suppression for all supported media formats with the same 3327 clock rate, as described in [RFC3389], Section 5, except for 3328 formats that have their own internal silence suppression 3329 mechanisms. Silence suppression for such formats (e.g., 3330 Opus) is controlled via fmtp parameters, as discussed in 3331 Section 5.2.3.2. 3333 o For each specified "telephone-event" media format, enable 3334 dual-tone multifrequency (DTMF) transmission for all 3335 supported media formats with the same clock rate, as 3336 described in [RFC4733], Section 2.5.1.2. If there are any 3337 supported media formats that do not have a corresponding 3338 telephone-event format, disable DTMF transmission for those 3339 formats. 3341 o For any specified "ptime" value, configure the available 3342 media formats to use the specified packet size when sending. 3343 If the specified size is not supported for a media format, 3344 use the next closest value instead. 3346 Finally, if this description is of type "pranswer" or "answer", 3347 follow the processing defined in Section 5.11 below. 3349 5.11. Applying an Answer 3351 In addition to the steps mentioned above for processing a local or 3352 remote description, the following steps are performed when processing 3353 a description of type "pranswer" or "answer". 3355 For each "m=" section, the following steps MUST be performed: 3357 * If the "m=" section has been rejected (i.e., the value is 3358 set to zero in the answer), stop any reception or transmission of 3359 media for this section, and, unless a non-rejected "m=" section is 3360 bundled with this "m=" section, discard any associated ICE 3361 components, as described in [RFC8839], Section 4.4.3.1. 3363 * If the remote DTLS fingerprint has been changed or the value of 3364 the "a=tls-id" attribute has changed, tear down the DTLS 3365 connection. This includes the case when the PeerConnection state 3366 is "have-remote-pranswer". If a DTLS connection needs to be torn 3367 down but the answer does not indicate an ICE restart or, in the 3368 case of "have-remote-pranswer", new ICE credentials, an error MUST 3369 be generated. If an ICE restart is performed without a change in 3370 the tls-id value or fingerprint, then the same DTLS connection is 3371 continued over the new ICE channel. Note that although JSEP 3372 requires that answerers change the tls-id value if and only if the 3373 offerer does, non-JSEP answerers are permitted to change the tls- 3374 id value as long as the offer contained an ICE restart. Thus, 3375 JSEP implementations that process DTLS data prior to receiving an 3376 answer MUST be prepared to receive either a ClientHello or data 3377 from the previous DTLS connection. 3379 * If no valid DTLS connection exists, prepare to start a DTLS 3380 connection, using the specified roles and fingerprints, on any 3381 underlying ICE components, once they are active. 3383 * If the "m=" section value indicates use of RTP: 3385 - If the "m=" section references RTCP feedback mechanisms that 3386 were not present in the corresponding "m=" section in the 3387 offer, this indicates a negotiation problem and MUST result in 3388 an error. However, new media formats and new RTP header 3389 extension values are permitted in the answer, as described in 3390 [RFC3264], Section 7 and [RFC5285], Section 6. 3392 - If the "m=" section has RTCP mux enabled, discard the RTCP ICE 3393 component, if one exists, and begin or continue muxing RTCP 3394 over the RTP ICE component, as specified in [RFC5761], 3395 Section 5.1.3. Otherwise, prepare to transmit RTCP over the 3396 RTCP ICE component; if no RTCP ICE component exists because 3397 RTCP mux was previously enabled, this MUST result in an error. 3399 - If the "m=" section has Reduced-Size RTCP enabled, configure 3400 the RTCP transmission for this "m=" section to use Reduced-Size 3401 RTCP, as specified in [RFC5506]. 3403 - If the direction attribute in the answer indicates that the 3404 JSEP implementation should be sending media ("sendonly" for 3405 local answers, "recvonly" for remote answers, or "sendrecv" for 3406 either type of answer), choose the media format to send as the 3407 most preferred media format from the remote description that is 3408 also locally supported, as discussed in Sections 6.1 and 7 of 3409 [RFC3264], and start transmitting RTP media using that format 3410 once the underlying transport layers have been established. If 3411 an SSRC has not already been chosen for this outgoing RTP 3412 stream, choose a unique random one. If media is already being 3413 transmitted, the same SSRC SHOULD be used unless the clock rate 3414 of the new codec is different, in which case a new SSRC MUST be 3415 chosen, as specified in [RFC7160], Section 4.1. 3417 - The payload type mapping from the remote description is used to 3418 determine payload types for the outgoing RTP streams, including 3419 the payload type for the send media format chosen above. Any 3420 RTP header extensions that were negotiated should be included 3421 in the outgoing RTP streams, using the extension mapping from 3422 the remote description. If the MID header extension has been 3423 negotiated, include it in the outgoing RTP streams, as 3424 indicated in [RFC9143], Section 15. If the RtpStreamId or 3425 RepairedRtpStreamId header extensions have been negotiated and 3426 rid-ids have been established, include these header extensions 3427 in the outgoing RTP streams, as indicated in [RFC8851], 3428 Section 4. 3430 - If the "m=" section is of type "audio", and silence suppression 3431 was (1) configured for the send media format as a result of 3432 processing the remote description and (2) also enabled for that 3433 format in the local description, use silence suppression for 3434 outgoing media, in accordance with the guidance in 3435 Section 5.2.3.2. If these conditions are not met, silence 3436 suppression MUST NOT be used for outgoing media. 3438 - If simulcast has been negotiated, send the appropriate number 3439 of Source RTP Streams as specified in [RFC8853], Section 5.3.3. 3441 - If the send media format chosen above has a corresponding "rtx" 3442 media format or a FEC mechanism has been negotiated, establish 3443 a redundancy RTP stream with a unique random SSRC for each 3444 Source RTP Stream, and start or continue transmitting RTX/FEC 3445 packets as needed. 3447 - If the send media format chosen above has a corresponding "red" 3448 media format of the same clock rate, allow redundant encoding 3449 using the specified format for resiliency purposes, as 3450 discussed in [RFC8854], Section 3.2. Note that unlike RTX or 3451 FEC media formats, the "red" format is transmitted on the 3452 Source RTP Stream, not the redundancy RTP stream. 3454 - Enable the RTCP feedback mechanisms referenced in the media 3455 section for all Source RTP Streams using the specified media 3456 formats. Specifically, begin or continue sending the requested 3457 feedback types and reacting to received feedback, as specified 3458 in [RFC4585], Section 4.2. When sending RTCP feedback, follow 3459 the rules and recommendations from [RFC8108], Section 5.4.1 to 3460 select which SSRC to use. 3462 - If the direction attribute in the answer indicates that the 3463 JSEP implementation should not be sending media ("recvonly" for 3464 local answers, "sendonly" for remote answers, or "inactive" for 3465 either type of answer), stop transmitting all RTP media, but 3466 continue sending RTCP, as described in [RFC3264], Section 5.1. 3468 * If the "m=" section value indicates use of SCTP: 3470 - If an SCTP association exists and the remote SCTP port has 3471 changed, discard the existing SCTP association. This includes 3472 the case when the PeerConnection state is "have-remote- 3473 pranswer". 3475 - If no valid SCTP association exists, prepare to initiate an 3476 SCTP association over the associated ICE component and DTLS 3477 connection, using the local SCTP port value from the local 3478 description and the remote SCTP port value from the remote 3479 description, as described in [RFC8841], Section 10.2. 3481 If the answer contains valid bundle groups, discard any ICE 3482 components for the "m=" sections that will be bundled onto the 3483 primary ICE components in each bundle, and begin muxing these "m=" 3484 sections accordingly, as described in [RFC9143], Section 7.4. 3486 If the description is of type "answer" and there are still remaining 3487 candidates in the ICE candidate pool, discard them. 3489 6. Processing RTP/RTCP 3491 When bundling, associating incoming RTP/RTCP with the proper "m=" 3492 section is defined in [RFC9143], Section 9.2. When not bundling, the 3493 proper "m=" section is clear from the ICE component over which the 3494 RTP/RTCP is received. 3496 Once the proper "m=" section or sections are known, RTP/RTCP is 3497 delivered to the RtpTransceiver(s) associated with the "m=" 3498 section(s) and further processing of the RTP/RTCP is done at the 3499 RtpTransceiver level. This includes using the RID mechanism 3500 [RFC8851] and its associated RtpStreamId and RepairedRtpStreamId 3501 identifiers to distinguish between multiple encoded streams and 3502 determine which Source RTP stream should be repaired by a given 3503 redundancy RTP stream. 3505 7. Examples 3507 Note that this example section shows several SDP fragments. To 3508 accommodate RFC line-length restrictions, some of the SDP lines have 3509 been split into multiple lines, where leading whitespace indicates 3510 that a line is a continuation of the previous line. In addition, 3511 some blank lines have been added to improve readability but are not 3512 valid in SDP. 3514 More examples of SDP for WebRTC call flows, including examples with 3515 IPv6 addresses, can be found in [SDP4WebRTC]. 3517 7.1. Simple Example 3519 This section shows a very simple example that sets up a minimal 3520 audio/video call between two JSEP endpoints without using Trickle 3521 ICE. The example in the following section provides a more detailed 3522 example of what could happen in a JSEP session. 3524 The code flow below shows Alice's endpoint initiating the session to 3525 Bob's endpoint. The messages from the JavaScript application in 3526 Alice's browser to the JavaScript in Bob's browser, abbreviated as 3527 "AliceJS" and "BobJS", respectively, are assumed to flow over some 3528 signaling protocol via a web server. The JavaScript on both Alice's 3529 side and Bob's side waits for all candidates before sending the offer 3530 or answer, so the offers and answers are complete; Trickle ICE is not 3531 used. The user agents (JSEP implementations) in Alice's and Bob's 3532 browsers, abbreviated as "AliceUA" and "BobUA", respectively, are 3533 both using the default bundle policy of "balanced" and the default 3534 RTCP mux policy of "require". 3536 // set up local media state 3537 AliceJS->AliceUA: create new PeerConnection 3538 AliceJS->AliceUA: addTrack with two tracks: audio and video 3539 AliceJS->AliceUA: createOffer to get offer 3540 AliceJS->AliceUA: setLocalDescription with offer 3541 AliceUA->AliceJS: multiple onicecandidate events with candidates 3543 // wait for ICE gathering to complete 3544 AliceUA->AliceJS: onicecandidate event with null candidate 3545 AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription 3547 // |offer-A1| is sent over signaling protocol to Bob 3548 AliceJS->WebServer: signaling with |offer-A1| 3549 WebServer->BobJS: signaling with |offer-A1| 3551 // |offer-A1| arrives at Bob 3552 BobJS->BobUA: create a PeerConnection 3553 BobJS->BobUA: setRemoteDescription with |offer-A1| 3554 BobUA->BobJS: ontrack events for audio and video tracks 3556 // Bob accepts call 3557 BobJS->BobUA: addTrack with local tracks 3558 BobJS->BobUA: createAnswer 3559 BobJS->BobUA: setLocalDescription with answer 3560 BobUA->BobJS: multiple onicecandidate events with candidates 3562 // wait for ICE gathering to complete 3563 BobUA->BobJS: onicecandidate event with null candidate 3564 BobJS->BobUA: get |answer-A1| from currentLocalDescription 3566 // |answer-A1| is sent over signaling protocol 3567 // to Alice 3568 BobJS->WebServer: signaling with |answer-A1| 3569 WebServer->AliceJS: signaling with |answer-A1| 3571 // |answer-A1| arrives at Alice 3572 AliceJS->AliceUA: setRemoteDescription with |answer-A1| 3573 AliceUA->AliceJS: ontrack events for audio and video tracks 3575 // media flows 3576 BobUA->AliceUA: media sent from Bob to Alice 3577 AliceUA->BobUA: media sent from Alice to Bob 3579 The SDP for |offer-A1| looks like: 3581 v=0 3582 o=- 4962303333179871722 1 IN IP4 0.0.0.0 3583 s=- 3584 t=0 0 3585 a=ice-options:trickle ice2 3586 a=group:BUNDLE a1 v1 3587 a=group:LS a1 v1 3589 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3590 c=IN IP4 203.0.113.100 3591 a=mid:a1 3592 a=sendrecv 3593 a=rtpmap:96 opus/48000/2 3594 a=rtpmap:0 PCMU/8000 3595 a=rtpmap:8 PCMA/8000 3596 a=rtpmap:97 telephone-event/8000 3597 a=rtpmap:98 telephone-event/48000 3598 a=fmtp:97 0-15 3599 a=fmtp:98 0-15 3600 a=maxptime:120 3601 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3602 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3603 a=msid:47017fee-b6c1-4162-929c-a25110252400 3604 a=ice-ufrag:ETEn 3605 a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl 3606 a=fingerprint:sha-256 3607 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3608 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3609 a=setup:actpass 3610 a=tls-id:91bbf309c0990a6bec11e38ba2933cee 3611 a=rtcp:10101 IN IP4 203.0.113.100 3612 a=rtcp-mux 3613 a=rtcp-rsize 3614 a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host 3615 a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host 3616 a=end-of-candidates 3618 m=video 10102 UDP/TLS/RTP/SAVPF 100 101 102 103 3619 c=IN IP4 203.0.113.100 3620 a=mid:v1 3621 a=sendrecv 3622 a=rtpmap:100 VP8/90000 3623 a=rtpmap:101 H264/90000 3624 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 3625 a=rtpmap:102 rtx/90000 3626 a=fmtp:102 apt=100 3627 a=rtpmap:103 rtx/90000 3628 a=fmtp:103 apt=101 3629 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3630 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 3631 a=rtcp-fb:100 ccm fir 3632 a=rtcp-fb:100 nack 3633 a=rtcp-fb:100 nack pli 3634 a=msid:47017fee-b6c1-4162-929c-a25110252400 3635 a=ice-ufrag:BGKk 3636 a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf 3637 a=fingerprint:sha-256 3638 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3639 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3640 a=setup:actpass 3641 a=tls-id:91bbf309c0990a6bec11e38ba2933cee 3642 a=rtcp:10103 IN IP4 203.0.113.100 3643 a=rtcp-mux 3644 a=rtcp-rsize 3645 a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host 3646 a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host 3647 a=end-of-candidates 3649 The SDP for |answer-A1| looks like: 3651 v=0 3652 o=- 6729291447651054566 1 IN IP4 0.0.0.0 3653 s=- 3654 t=0 0 3655 a=ice-options:trickle ice2 3656 a=group:BUNDLE a1 v1 3657 a=group:LS a1 v1 3659 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3660 c=IN IP4 203.0.113.200 3661 a=mid:a1 3662 a=sendrecv 3663 a=rtpmap:96 opus/48000/2 3664 a=rtpmap:0 PCMU/8000 3665 a=rtpmap:8 PCMA/8000 3666 a=rtpmap:97 telephone-event/8000 3667 a=rtpmap:98 telephone-event/48000 3668 a=fmtp:97 0-15 3669 a=fmtp:98 0-15 3670 a=maxptime:120 3671 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3672 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3673 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 3674 a=ice-ufrag:6sFv 3675 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 3676 a=fingerprint:sha-256 3677 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 3678 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 3679 a=setup:active 3680 a=tls-id:eec3392ab83e11ceb6a0990c903fbb19 3681 a=rtcp-mux 3682 a=rtcp-rsize 3683 a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host 3684 a=end-of-candidates 3686 m=video 10200 UDP/TLS/RTP/SAVPF 100 101 102 103 3687 c=IN IP4 203.0.113.200 3688 a=mid:v1 3689 a=sendrecv 3690 a=rtpmap:100 VP8/90000 3691 a=rtpmap:101 H264/90000 3692 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 3693 a=rtpmap:102 rtx/90000 3694 a=fmtp:102 apt=100 3695 a=rtpmap:103 rtx/90000 3696 a=fmtp:103 apt=101 3697 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3698 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 3699 a=rtcp-fb:100 ccm fir 3700 a=rtcp-fb:100 nack 3701 a=rtcp-fb:100 nack pli 3702 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 3704 7.2. Detailed Example 3706 This section shows a more involved example of a session between two 3707 JSEP endpoints. Trickle ICE is used in full trickle mode, with a 3708 bundle policy of "must-bundle", an RTCP mux policy of "require", and 3709 a single TURN server. Initially, both Alice and Bob establish an 3710 audio channel and a data channel. Later, Bob adds two video flows -- 3711 one for his video feed and one for screen sharing, both supporting 3712 FEC -- with the video feed configured for simulcast. Alice accepts 3713 these video flows but does not add video flows of her own, so they 3714 are handled as recvonly. Alice also specifies a maximum video 3715 decoder resolution. 3717 // set up local media state 3718 AliceJS->AliceUA: create new PeerConnection 3719 AliceJS->AliceUA: addTrack with an audio track 3720 AliceJS->AliceUA: createDataChannel to get data channel 3721 AliceJS->AliceUA: createOffer to get |offer-B1| 3722 AliceJS->AliceUA: setLocalDescription with |offer-B1| 3724 // |offer-B1| is sent over signaling protocol to Bob 3725 AliceJS->WebServer: signaling with |offer-B1| 3726 WebServer->BobJS: signaling with |offer-B1| 3728 // |offer-B1| arrives at Bob 3729 BobJS->BobUA: create a PeerConnection 3730 BobJS->BobUA: setRemoteDescription with |offer-B1| 3731 BobUA->BobJS: ontrack event with audio track from Alice 3733 // candidates are sent to Bob 3734 AliceUA->AliceJS: onicecandidate (host) |offer-B1-candidate-1| 3735 AliceJS->WebServer: signaling with |offer-B1-candidate-1| 3736 AliceUA->AliceJS: onicecandidate (srflx) |offer-B1-candidate-2| 3737 AliceJS->WebServer: signaling with |offer-B1-candidate-2| 3738 AliceUA->AliceJS: onicecandidate (relay) |offer-B1-candidate-3| 3739 AliceJS->WebServer: signaling with |offer-B1-candidate-3| 3741 WebServer->BobJS: signaling with |offer-B1-candidate-1| 3742 BobJS->BobUA: addIceCandidate with |offer-B1-candidate-1| 3743 WebServer->BobJS: signaling with |offer-B1-candidate-2| 3744 BobJS->BobUA: addIceCandidate with |offer-B1-candidate-2| 3745 WebServer->BobJS: signaling with |offer-B1-candidate-3| 3746 BobJS->BobUA: addIceCandidate with |offer-B1-candidate-3| 3748 // Bob accepts call 3749 BobJS->BobUA: addTrack with local audio 3750 BobJS->BobUA: createDataChannel to get data channel 3751 BobJS->BobUA: createAnswer to get |answer-B1| 3752 BobJS->BobUA: setLocalDescription with |answer-B1| 3754 // |answer-B1| is sent to Alice 3755 BobJS->WebServer: signaling with |answer-B1| 3756 WebServer->AliceJS: signaling with |answer-B1| 3757 AliceJS->AliceUA: setRemoteDescription with |answer-B1| 3758 AliceUA->AliceJS: ontrack event with audio track from Bob 3760 // candidates are sent to Alice 3761 BobUA->BobJS: onicecandidate (host) |answer-B1-candidate-1| 3762 BobJS->WebServer: signaling with |answer-B1-candidate-1| 3763 BobUA->BobJS: onicecandidate (srflx) |answer-B1-candidate-2| 3764 BobJS->WebServer: signaling with |answer-B1-candidate-2| 3765 BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-3| 3766 BobJS->WebServer: signaling with |answer-B1-candidate-3| 3768 WebServer->AliceJS: signaling with |answer-B1-candidate-1| 3769 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| 3770 WebServer->AliceJS: signaling with |answer-B1-candidate-2| 3771 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-2| 3772 WebServer->AliceJS: signaling with |answer-B1-candidate-3| 3773 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-3| 3775 // data channel opens 3776 BobUA->BobJS: ondatachannel event 3777 AliceUA->AliceJS: ondatachannel event 3778 BobUA->BobJS: onopen 3779 AliceUA->AliceJS: onopen 3781 // media is flowing between endpoints 3782 BobUA->AliceUA: audio+data sent from Bob to Alice 3783 AliceUA->BobUA: audio+data sent from Alice to Bob 3785 // some time later, Bob adds two video streams 3786 // note: no candidates exchanged, because of bundle 3787 BobJS->BobUA: addTrack with first video stream 3788 BobJS->BobUA: addTrack with second video stream 3789 BobJS->BobUA: createOffer to get |offer-B2| 3790 BobJS->BobUA: setLocalDescription with |offer-B2| 3792 // |offer-B2| is sent to Alice 3793 BobJS->WebServer: signaling with |offer-B2| 3794 WebServer->AliceJS: signaling with |offer-B2| 3795 AliceJS->AliceUA: setRemoteDescription with |offer-B2| 3796 AliceUA->AliceJS: ontrack event with first video track 3797 AliceUA->AliceJS: ontrack event with second video track 3798 AliceJS->AliceUA: createAnswer to get |answer-B2| 3799 AliceJS->AliceUA: setLocalDescription with |answer-B2| 3801 // |answer-B2| is sent over signaling protocol 3802 // to Bob 3803 AliceJS->WebServer: signaling with |answer-B2| 3804 WebServer->BobJS: signaling with |answer-B2| 3805 BobJS->BobUA: setRemoteDescription with |answer-B2| 3807 // media is flowing between endpoints 3808 BobUA->AliceUA: audio+video+data sent from Bob to Alice 3809 AliceUA->BobUA: audio+video+data sent from Alice to Bob 3811 The SDP for |offer-B1| looks like: 3813 v=0 3814 o=- 4962303333179871723 1 IN IP4 0.0.0.0 3815 s=- 3816 t=0 0 3817 a=ice-options:trickle ice2 3818 a=group:BUNDLE a1 d1 3820 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3821 c=IN IP4 0.0.0.0 3822 a=mid:a1 3823 a=sendrecv 3824 a=rtpmap:96 opus/48000/2 3825 a=rtpmap:0 PCMU/8000 3826 a=rtpmap:8 PCMA/8000 3827 a=rtpmap:97 telephone-event/8000 3828 a=rtpmap:98 telephone-event/48000 3829 a=fmtp:97 0-15 3830 a=fmtp:98 0-15 3831 a=maxptime:120 3832 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3833 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3834 a=msid:57017fee-b6c1-4162-929c-a25110252400 3835 a=ice-ufrag:ATEn 3836 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 3837 a=fingerprint:sha-256 3838 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3839 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3840 a=setup:actpass 3841 a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 3842 a=rtcp-mux 3843 a=rtcp-mux-only 3844 a=rtcp-rsize 3846 m=application 0 UDP/DTLS/SCTP webrtc-datachannel 3847 c=IN IP4 0.0.0.0 3848 a=mid:d1 3849 a=sctp-port:5000 3850 a=max-message-size:65536 3851 a=bundle-only 3853 |offer-B1-candidate-1| looks like: 3855 ufrag ATEn 3856 index 0 3857 mid a1 3858 attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host 3860 |offer-B1-candidate-2| looks like: 3862 ufrag ATEn 3863 index 0 3864 mid a1 3865 attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx 3866 raddr 203.0.113.100 rport 10100 3868 |offer-B1-candidate-3| looks like: 3870 ufrag ATEn 3871 index 0 3872 mid a1 3873 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay 3874 raddr 198.51.100.100 rport 11100 3876 The SDP for |answer-B1| looks like: 3878 v=0 3879 o=- 7729291447651054566 1 IN IP4 0.0.0.0 3880 s=- 3881 t=0 0 3882 a=ice-options:trickle ice2 3883 a=group:BUNDLE a1 d1 3885 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3886 c=IN IP4 0.0.0.0 3887 a=mid:a1 3888 a=sendrecv 3889 a=rtpmap:96 opus/48000/2 3890 a=rtpmap:0 PCMU/8000 3891 a=rtpmap:8 PCMA/8000 3892 a=rtpmap:97 telephone-event/8000 3893 a=rtpmap:98 telephone-event/48000 3894 a=fmtp:97 0-15 3895 a=fmtp:98 0-15 3896 a=maxptime:120 3897 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3898 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3899 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 3900 a=ice-ufrag:7sFv 3901 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 3902 a=fingerprint:sha-256 3903 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 3904 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 3905 a=setup:active 3906 a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 3907 a=rtcp-mux 3908 a=rtcp-mux-only 3909 a=rtcp-rsize 3911 m=application 9 UDP/DTLS/SCTP webrtc-datachannel 3912 c=IN IP4 0.0.0.0 3913 a=mid:d1 3914 a=sctp-port:5000 3915 a=max-message-size:65536 3917 |answer-B1-candidate-1| looks like: 3919 ufrag 7sFv 3920 index 0 3921 mid a1 3922 attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host 3924 |answer-B1-candidate-2| looks like: 3926 ufrag 7sFv 3927 index 0 3928 mid a1 3929 attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx 3930 raddr 203.0.113.200 rport 10200 3932 |answer-B1-candidate-3| looks like: 3934 ufrag 7sFv 3935 index 0 3936 mid a1 3937 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay 3938 raddr 198.51.100.200 rport 11200 3940 The SDP for |offer-B2| is shown below. In addition to the new "m=" 3941 sections for video, both of which are offering FEC and one of which 3942 is offering simulcast, note the increment of the version number in 3943 the "o=" line; changes to the "c=" line, indicating the local 3944 candidate that was selected; and the inclusion of gathered candidates 3945 as a=candidate lines. 3947 v=0 3948 o=- 7729291447651054566 2 IN IP4 0.0.0.0 3949 s=- 3950 t=0 0 3951 a=ice-options:trickle ice2 3952 a=group:BUNDLE a1 d1 v1 v2 3953 a=group:LS a1 v1 3955 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3956 c=IN IP4 192.0.2.200 3957 a=mid:a1 3958 a=sendrecv 3959 a=rtpmap:96 opus/48000/2 3960 a=rtpmap:0 PCMU/8000 3961 a=rtpmap:8 PCMA/8000 3962 a=rtpmap:97 telephone-event/8000 3963 a=rtpmap:98 telephone-event/48000 3964 a=fmtp:97 0-15 3965 a=fmtp:98 0-15 3966 a=maxptime:120 3967 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3968 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3969 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 3970 a=ice-ufrag:7sFv 3971 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 3972 a=fingerprint:sha-256 3973 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 3975 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 3976 a=setup:actpass 3977 a=tls-id:7a25ab85b195acaf3121f5a8ab4f0f71 3978 a=rtcp-mux 3979 a=rtcp-mux-only 3980 a=rtcp-rsize 3981 a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host 3982 a=candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx 3983 raddr 203.0.113.200 rport 10200 3984 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay 3985 raddr 198.51.100.200 rport 11200 3986 a=end-of-candidates 3988 m=application 12200 UDP/DTLS/SCTP webrtc-datachannel 3989 c=IN IP4 192.0.2.200 3990 a=mid:d1 3991 a=sctp-port:5000 3992 a=max-message-size:65536 3994 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 3995 c=IN IP4 192.0.2.200 3996 a=mid:v1 3997 a=sendrecv 3998 a=rtpmap:100 VP8/90000 3999 a=rtpmap:101 H264/90000 4000 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4001 a=rtpmap:102 rtx/90000 4002 a=fmtp:102 apt=100 4003 a=rtpmap:103 rtx/90000 4004 a=fmtp:103 apt=101 4005 a=rtpmap:104 flexfec/90000 4006 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4007 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4008 a=rtcp-fb:100 ccm fir 4009 a=rtcp-fb:100 nack 4010 a=rtcp-fb:100 nack pli 4011 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 4012 a=rid:1 send 4013 a=rid:2 send 4014 a=rid:3 send 4015 a=simulcast:send 1;2;3 4017 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 104 4018 c=IN IP4 192.0.2.200 4019 a=mid:v2 4020 a=sendrecv 4021 a=rtpmap:100 VP8/90000 4022 a=rtpmap:101 H264/90000 4023 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4024 a=rtpmap:102 rtx/90000 4025 a=fmtp:102 apt=100 4026 a=rtpmap:103 rtx/90000 4027 a=fmtp:103 apt=101 4028 a=rtpmap:104 flexfec/90000 4029 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4030 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4031 a=rtcp-fb:100 ccm fir 4032 a=rtcp-fb:100 nack 4033 a=rtcp-fb:100 nack pli 4034 a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae 4036 The SDP for |answer-B2| is shown below. In addition to the 4037 acceptance of the video "m=" sections, the use of a=recvonly to 4038 indicate one-way video, and the use of a=imageattr to limit the 4039 received resolution, note the use of setup:passive to maintain the 4040 existing DTLS roles. 4042 v=0 4043 o=- 4962303333179871723 2 IN IP4 0.0.0.0 4044 s=- 4045 t=0 0 4046 a=ice-options:trickle ice2 4047 a=group:BUNDLE a1 d1 v1 v2 4048 a=group:LS a1 v1 4050 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4051 c=IN IP4 192.0.2.100 4052 a=mid:a1 4053 a=sendrecv 4054 a=rtpmap:96 opus/48000/2 4055 a=rtpmap:0 PCMU/8000 4056 a=rtpmap:8 PCMA/8000 4057 a=rtpmap:97 telephone-event/8000 4058 a=rtpmap:98 telephone-event/48000 4059 a=fmtp:97 0-15 4060 a=fmtp:98 0-15 4061 a=maxptime:120 4062 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4063 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4064 a=msid:57017fee-b6c1-4162-929c-a25110252400 4065 a=ice-ufrag:ATEn 4066 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 4067 a=fingerprint:sha-256 4068 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 4069 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 4070 a=setup:passive 4071 a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7 4072 a=rtcp-mux 4073 a=rtcp-mux-only 4074 a=rtcp-rsize 4075 a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host 4076 a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx 4077 raddr 203.0.113.100 rport 10100 4078 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay 4079 raddr 198.51.100.100 rport 11100 4080 a=end-of-candidates 4082 m=application 12100 UDP/DTLS/SCTP webrtc-datachannel 4083 c=IN IP4 192.0.2.100 4084 a=mid:d1 4085 a=sctp-port:5000 4086 a=max-message-size:65536 4088 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 4089 c=IN IP4 192.0.2.100 4090 a=mid:v1 4091 a=recvonly 4092 a=rtpmap:100 VP8/90000 4093 a=rtpmap:101 H264/90000 4094 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4095 a=rtpmap:102 rtx/90000 4096 a=fmtp:102 apt=100 4097 a=rtpmap:103 rtx/90000 4098 a=fmtp:103 apt=101 4099 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] 4100 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4101 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4102 a=rtcp-fb:100 ccm fir 4103 a=rtcp-fb:100 nack 4104 a=rtcp-fb:100 nack pli 4106 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 4107 c=IN IP4 192.0.2.100 4108 a=mid:v2 4109 a=recvonly 4110 a=rtpmap:100 VP8/90000 4111 a=rtpmap:101 H264/90000 4112 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4113 a=rtpmap:102 rtx/90000 4114 a=fmtp:102 apt=100 4115 a=rtpmap:103 rtx/90000 4116 a=fmtp:103 apt=101 4117 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] 4118 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4119 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4120 a=rtcp-fb:100 ccm fir 4121 a=rtcp-fb:100 nack 4122 a=rtcp-fb:100 nack pli 4124 7.3. Early Transport Warmup Example 4126 This example demonstrates the early-warmup technique described in 4127 Section 4.1.10.1. Here, Alice's endpoint sends an offer to Bob's 4128 endpoint to start an audio/video call. Bob immediately responds with 4129 an answer that accepts the audio/video "m=" sections but marks them 4130 as sendonly (from his perspective), meaning that Alice will not yet 4131 send media. This allows the JSEP implementation to start negotiating 4132 ICE and DTLS immediately. Bob's endpoint then prompts him to answer 4133 the call, and when he does, his endpoint sends a second offer, which 4134 enables the audio and video "m=" sections, and thereby bidirectional 4135 media transmission. The advantage of such a flow is that as soon as 4136 the first answer is received, the implementation can proceed with ICE 4137 and DTLS negotiation and establish the session transport. If the 4138 transport setup completes before the second offer is sent, then media 4139 can be transmitted by the callee immediately upon answering the call, 4140 minimizing perceived post-dial delay. The second offer/answer 4141 exchange can also change the preferred codecs or other session 4142 parameters. 4144 This example also makes use of the "relay" ICE candidate policy 4145 described in Section 3.5.3 to minimize the ICE gathering and checking 4146 needed. 4148 // set up local media state 4149 AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy 4150 AliceJS->AliceUA: addTrack with two tracks: audio and video 4151 AliceJS->AliceUA: createOffer to get |offer-C1| 4152 AliceJS->AliceUA: setLocalDescription with |offer-C1| 4154 // |offer-C1| is sent over signaling protocol to Bob 4155 AliceJS->WebServer: signaling with |offer-C1| 4156 WebServer->BobJS: signaling with |offer-C1| 4158 // |offer-C1| arrives at Bob 4159 BobJS->BobUA: create new PeerConnection with "relay" ICE policy 4160 BobJS->BobUA: setRemoteDescription with |offer-C1| 4161 BobUA->BobJS: ontrack events for audio and video 4163 // a relay candidate is sent to Bob 4164 AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1| 4165 AliceJS->WebServer: signaling with |offer-C1-candidate-1| 4166 WebServer->BobJS: signaling with |offer-C1-candidate-1| 4167 BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1| 4169 // Bob prepares an early answer to warm up the 4170 // transport 4171 BobJS->BobUA: addTransceiver with null audio and video tracks 4172 BobJS->BobUA: transceiver.setDirection(sendonly) for both 4173 BobJS->BobUA: createAnswer 4174 BobJS->BobUA: setLocalDescription with answer 4176 // |answer-C1| is sent over signaling protocol 4177 // to Alice 4178 BobJS->WebServer: signaling with |answer-C1| 4179 WebServer->AliceJS: signaling with |answer-C1| 4181 // |answer-C1| (sendonly) arrives at Alice 4182 AliceJS->AliceUA: setRemoteDescription with |answer-C1| 4183 AliceUA->AliceJS: ontrack events for audio and video 4185 // a relay candidate is sent to Alice 4186 BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| 4187 BobJS->WebServer: signaling with |answer-B1-candidate-1| 4189 WebServer->AliceJS: signaling with |answer-B1-candidate-1| 4190 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| 4192 // ICE and DTLS establish while call is ringing 4194 // Bob accepts call, starts media, and sends 4195 // new offer 4196 BobJS->BobUA: transceiver.setTrack with audio and video tracks 4197 BobUA->AliceUA: media sent from Bob to Alice 4198 BobJS->BobUA: transceiver.setDirection(sendrecv) for both 4199 transceivers 4200 BobJS->BobUA: createOffer 4201 BobJS->BobUA: setLocalDescription with offer 4203 // |offer-C2| is sent over signaling protocol 4204 // to Alice 4205 BobJS->WebServer: signaling with |offer-C2| 4206 WebServer->AliceJS: signaling with |offer-C2| 4208 // |offer-C2| (sendrecv) arrives at Alice 4209 AliceJS->AliceUA: setRemoteDescription with |offer-C2| 4210 AliceJS->AliceUA: createAnswer 4211 AliceJS->AliceUA: setLocalDescription with |answer-C2| 4212 AliceUA->BobUA: media sent from Alice to Bob 4213 // |answer-C2| is sent over signaling protocol 4214 // to Bob 4215 AliceJS->WebServer: signaling with |answer-C2| 4216 WebServer->BobJS: signaling with |answer-C2| 4217 BobJS->BobUA: setRemoteDescription with |answer-C2| 4219 The SDP for |offer-C1| looks like: 4221 v=0 4222 o=- 1070771854436052752 1 IN IP4 0.0.0.0 4223 s=- 4224 t=0 0 4225 a=ice-options:trickle ice2 4226 a=group:BUNDLE a1 v1 4227 a=group:LS a1 v1 4229 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4230 c=IN IP4 0.0.0.0 4231 a=mid:a1 4232 a=sendrecv 4233 a=rtpmap:96 opus/48000/2 4234 a=rtpmap:0 PCMU/8000 4235 a=rtpmap:8 PCMA/8000 4236 a=rtpmap:97 telephone-event/8000 4237 a=rtpmap:98 telephone-event/48000 4238 a=fmtp:97 0-15 4239 a=fmtp:98 0-15 4240 a=maxptime:120 4241 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4242 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4243 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4244 a=ice-ufrag:4ZcD 4245 a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD 4246 a=fingerprint:sha-256 4247 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 4248 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF 4249 a=setup:actpass 4250 a=tls-id:9e5b948ade9c3d41de6617b68f769e55 4251 a=rtcp-mux 4252 a=rtcp-mux-only 4253 a=rtcp-rsize 4255 m=video 0 UDP/TLS/RTP/SAVPF 100 101 102 103 4256 c=IN IP4 0.0.0.0 4257 a=mid:v1 4258 a=sendrecv 4259 a=rtpmap:100 VP8/90000 4260 a=rtpmap:101 H264/90000 4261 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4262 a=rtpmap:102 rtx/90000 4263 a=fmtp:102 apt=100 4264 a=rtpmap:103 rtx/90000 4265 a=fmtp:103 apt=101 4266 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4267 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4268 a=rtcp-fb:100 ccm fir 4269 a=rtcp-fb:100 nack 4270 a=rtcp-fb:100 nack pli 4271 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4272 a=bundle-only 4274 |offer-C1-candidate-1| looks like: 4276 ufrag 4ZcD 4277 index 0 4278 mid a1 4279 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay 4280 raddr 0.0.0.0 rport 0 4282 The SDP for |answer-C1| looks like: 4284 v=0 4285 o=- 6386516489780559513 1 IN IP4 0.0.0.0 4286 s=- 4287 t=0 0 4288 a=ice-options:trickle ice2 4289 a=group:BUNDLE a1 v1 4290 a=group:LS a1 v1 4292 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4293 c=IN IP4 0.0.0.0 4294 a=mid:a1 4295 a=sendonly 4296 a=rtpmap:96 opus/48000/2 4297 a=rtpmap:0 PCMU/8000 4298 a=rtpmap:8 PCMA/8000 4299 a=rtpmap:97 telephone-event/8000 4300 a=rtpmap:98 telephone-event/48000 4301 a=fmtp:97 0-15 4302 a=fmtp:98 0-15 4303 a=maxptime:120 4304 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4305 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4306 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4307 a=ice-ufrag:TpaA 4308 a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ 4309 a=fingerprint:sha-256 4310 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 4311 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D 4312 a=setup:active 4313 a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 4314 a=rtcp-mux 4315 a=rtcp-mux-only 4316 a=rtcp-rsize 4318 m=video 9 UDP/TLS/RTP/SAVPF 100 101 102 103 4319 c=IN IP4 0.0.0.0 4320 a=mid:v1 4321 a=sendonly 4322 a=rtpmap:100 VP8/90000 4323 a=rtpmap:101 H264/90000 4324 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4325 a=rtpmap:102 rtx/90000 4326 a=fmtp:102 apt=100 4327 a=rtpmap:103 rtx/90000 4328 a=fmtp:103 apt=101 4329 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4330 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4331 a=rtcp-fb:100 ccm fir 4332 a=rtcp-fb:100 nack 4333 a=rtcp-fb:100 nack pli 4334 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4336 |answer-C1-candidate-1| looks like: 4338 ufrag TpaA 4339 index 0 4340 mid a1 4341 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay 4342 raddr 0.0.0.0 rport 0 4344 The SDP for |offer-C2| looks like: 4346 v=0 4347 o=- 6386516489780559513 2 IN IP4 0.0.0.0 4348 s=- 4349 t=0 0 4350 a=ice-options:trickle ice2 4351 a=group:BUNDLE a1 v1 4352 a=group:LS a1 v1 4354 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4355 c=IN IP4 192.0.2.200 4356 a=mid:a1 4357 a=sendrecv 4358 a=rtpmap:96 opus/48000/2 4359 a=rtpmap:0 PCMU/8000 4360 a=rtpmap:8 PCMA/8000 4361 a=rtpmap:97 telephone-event/8000 4362 a=rtpmap:98 telephone-event/48000 4363 a=fmtp:97 0-15 4364 a=fmtp:98 0-15 4365 a=maxptime:120 4366 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4367 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4368 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4369 a=ice-ufrag:TpaA 4370 a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ 4371 a=fingerprint:sha-256 4372 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 4373 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D 4374 a=setup:actpass 4375 a=tls-id:55e967f86b7166ed14d3c9eda849b5e9 4376 a=rtcp-mux 4377 a=rtcp-mux-only 4378 a=rtcp-rsize 4379 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay 4380 raddr 0.0.0.0 rport 0 4381 a=end-of-candidates 4383 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 103 4384 c=IN IP4 192.0.2.200 4385 a=mid:v1 4386 a=sendrecv 4387 a=rtpmap:100 VP8/90000 4388 a=rtpmap:101 H264/90000 4389 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4390 a=rtpmap:102 rtx/90000 4391 a=fmtp:102 apt=100 4392 a=rtpmap:103 rtx/90000 4393 a=fmtp:103 apt=101 4394 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4395 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4396 a=rtcp-fb:100 ccm fir 4397 a=rtcp-fb:100 nack 4398 a=rtcp-fb:100 nack pli 4399 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4401 The SDP for |answer-C2| looks like: 4403 v=0 4404 o=- 1070771854436052752 2 IN IP4 0.0.0.0 4405 s=- 4406 t=0 0 4407 a=ice-options:trickle ice2 4408 a=group:BUNDLE a1 v1 4409 a=group:LS a1 v1 4411 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4412 c=IN IP4 192.0.2.100 4413 a=mid:a1 4414 a=sendrecv 4415 a=rtpmap:96 opus/48000/2 4416 a=rtpmap:0 PCMU/8000 4417 a=rtpmap:8 PCMA/8000 4418 a=rtpmap:97 telephone-event/8000 4419 a=rtpmap:98 telephone-event/48000 4420 a=fmtp:97 0-15 4421 a=fmtp:98 0-15 4422 a=maxptime:120 4423 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4424 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4425 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4426 a=ice-ufrag:4ZcD 4427 a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD 4428 a=fingerprint:sha-256 4429 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 4430 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF 4431 a=setup:passive 4432 a=tls-id:9e5b948ade9c3d41de6617b68f769e55 4433 a=rtcp-mux 4434 a=rtcp-mux-only 4435 a=rtcp-rsize 4436 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay 4437 raddr 0.0.0.0 rport 0 4438 a=end-of-candidates 4440 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103 4441 c=IN IP4 192.0.2.100 4442 a=mid:v1 4443 a=sendrecv 4444 a=rtpmap:100 VP8/90000 4445 a=rtpmap:101 H264/90000 4446 a=fmtp:101 packetization-mode=1;profile-level-id=42e01f 4447 a=rtpmap:102 rtx/90000 4448 a=fmtp:102 apt=100 4449 a=rtpmap:103 rtx/90000 4450 a=fmtp:103 apt=101 4451 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4452 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 4453 a=rtcp-fb:100 ccm fir 4454 a=rtcp-fb:100 nack 4455 a=rtcp-fb:100 nack pli 4456 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4458 8. Security Considerations 4460 The IETF has published separate documents [RFC8827] [RFC8826] 4461 describing the security architecture for WebRTC as a whole. The 4462 remainder of this section describes security considerations for this 4463 document. 4465 While formally the JSEP interface is an API, it is better to think of 4466 it as an Internet protocol, with the application JavaScript being 4467 untrustworthy from the perspective of the JSEP implementation. Thus, 4468 the threat model of [RFC3552] applies. In particular, JavaScript can 4469 call the API in any order and with any inputs, including malicious 4470 ones. This is particularly relevant when we consider the SDP that is 4471 passed to setLocalDescription. While correct API usage requires that 4472 the application pass in SDP that was derived from createOffer or 4473 createAnswer, there is no guarantee that applications do so. The 4474 JSEP implementation MUST be prepared for the JavaScript to pass in 4475 bogus data instead. 4477 Conversely, the application programmer needs to be aware that the 4478 JavaScript does not have complete control of endpoint behavior. One 4479 case that bears particular mention is that editing ICE candidates out 4480 of the SDP or suppressing trickled candidates does not have the 4481 expected behavior: implementations will still perform checks from 4482 those candidates even if they are not sent to the other side. Thus, 4483 for instance, it is not possible to prevent the remote peer from 4484 learning your public IP address by removing server-reflexive 4485 candidates. Applications that wish to conceal their public IP 4486 address MUST instead configure the ICE agent to use only relay 4487 candidates. 4489 9. IANA Considerations 4491 This document has no IANA actions. 4493 10. References 4495 10.1. Normative References 4497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4498 Requirement Levels", BCP 14, RFC 2119, 4499 DOI 10.17487/RFC2119, March 1997, 4500 . 4502 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4503 A., Peterson, J., Sparks, R., Handley, M., and E. 4504 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4505 DOI 10.17487/RFC3261, June 2002, 4506 . 4508 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 4509 with Session Description Protocol (SDP)", RFC 3264, 4510 DOI 10.17487/RFC3264, June 2002, 4511 . 4513 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4514 Text on Security Considerations", BCP 72, RFC 3552, 4515 DOI 10.17487/RFC3552, July 2003, 4516 . 4518 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 4519 in Session Description Protocol (SDP)", RFC 3605, 4520 DOI 10.17487/RFC3605, October 2003, 4521 . 4523 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 4524 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 4525 RFC 3711, DOI 10.17487/RFC3711, March 2004, 4526 . 4528 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 4529 Modifier for the Session Description Protocol (SDP)", 4530 RFC 3890, DOI 10.17487/RFC3890, September 2004, 4531 . 4533 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 4534 the Session Description Protocol (SDP)", RFC 4145, 4535 DOI 10.17487/RFC4145, September 2005, 4536 . 4538 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4539 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 4540 July 2006, . 4542 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 4543 "Extended RTP Profile for Real-time Transport Control 4544 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 4545 DOI 10.17487/RFC4585, July 2006, 4546 . 4548 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 4549 Real-time Transport Control Protocol (RTCP)-Based Feedback 4550 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 4551 2008, . 4553 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 4554 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 4555 2008, . 4557 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 4558 Control Packets on a Single Port", RFC 5761, 4559 DOI 10.17487/RFC5761, April 2010, 4560 . 4562 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 4563 Protocol (SDP) Grouping Framework", RFC 5888, 4564 DOI 10.17487/RFC5888, June 2010, 4565 . 4567 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 4568 Attributes in the Session Description Protocol (SDP)", 4569 RFC 6236, DOI 10.17487/RFC6236, May 2011, 4570 . 4572 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4573 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 4574 January 2012, . 4576 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 4577 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 4578 September 2012, . 4580 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 4581 Real-time Transport Protocol (SRTP)", RFC 6904, 4582 DOI 10.17487/RFC6904, April 2013, 4583 . 4585 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 4586 Clock Rates in an RTP Session", RFC 7160, 4587 DOI 10.17487/RFC7160, April 2014, 4588 . 4590 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 4591 for the Opus Speech and Audio Codec", RFC 7587, 4592 DOI 10.17487/RFC7587, June 2015, 4593 . 4595 [RFC7742] Roach, A.B., "WebRTC Video Processing and Codec 4596 Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, 4597 . 4599 [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' 4600 Field for Transporting RTP Media over TCP under Various 4601 RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, 4602 . 4604 [RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing 4605 Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, 4606 . 4608 [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 4609 "Sending Multiple RTP Streams in a Single RTP Session", 4610 RFC 8108, DOI 10.17487/RFC8108, March 2017, 4611 . 4613 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 4614 Transport over the Transport Layer Security (TLS) Protocol 4615 in the Session Description Protocol (SDP)", RFC 8122, 4616 DOI 10.17487/RFC8122, March 2017, 4617 . 4619 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4620 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4621 May 2017, . 4623 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 4624 Connectivity Establishment (ICE): A Protocol for Network 4625 Address Translator (NAT) Traversal", RFC 8445, 4626 DOI 10.17487/RFC8445, July 2018, 4627 . 4629 [RFC8826] Rescorla, E., "Security Considerations for WebRTC", 4630 RFC 8826, DOI 10.17487/RFC8826, January 2021, 4631 . 4633 [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, 4634 DOI 10.17487/RFC8827, January 2021, 4635 . 4637 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 4638 "JavaScript Session Establishment Protocol (JSEP)", 4639 RFC 8829, DOI 10.17487/RFC8829, January 2021, 4640 . 4642 [RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the 4643 Session Description Protocol", RFC 8830, 4644 DOI 10.17487/RFC8830, January 2021, 4645 . 4647 [RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport 4648 and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834, 4649 January 2021, . 4651 [RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE: 4652 Incremental Provisioning of Candidates for the Interactive 4653 Connectivity Establishment (ICE) Protocol", RFC 8838, 4654 DOI 10.17487/RFC8838, January 2021, 4655 . 4657 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, 4658 A., and R. Shpount, "Session Description Protocol (SDP) 4659 Offer/Answer Procedures for Interactive Connectivity 4660 Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, 4661 January 2021, . 4663 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 4664 Session Initiation Protocol (SIP) Usage for Incremental 4665 Provisioning of Candidates for the Interactive 4666 Connectivity Establishment (Trickle ICE)", RFC 8840, 4667 DOI 10.17487/RFC8840, January 2021, 4668 . 4670 [RFC8841] Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 4671 "Session Description Protocol (SDP) Offer/Answer 4672 Procedures for Stream Control Transmission Protocol (SCTP) 4673 over Datagram Transport Layer Security (DTLS) Transport", 4674 RFC 8841, DOI 10.17487/RFC8841, January 2021, 4675 . 4677 [RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol 4678 (SDP) Offer/Answer Considerations for Datagram Transport 4679 Layer Security (DTLS) and Transport Layer Security (TLS)", 4680 RFC 8842, DOI 10.17487/RFC8842, January 2021, 4681 . 4683 [RFC8851] Roach, A.B., Ed., "RTP Payload Format Restrictions", 4684 RFC 8851, DOI 10.17487/RFC8851, January 2021, 4685 . 4687 [RFC8852] Roach, A.B., Nandakumar, S., and P. Thatcher, "RTP Stream 4688 Identifier Source Description (SDES)", RFC 8852, 4689 DOI 10.17487/RFC8852, January 2021, 4690 . 4692 [RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 4693 "Using Simulcast in Session Description Protocol (SDP) and 4694 RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January 4695 2021, . 4697 [RFC8854] Uberti, J., "WebRTC Forward Error Correction 4698 Requirements", RFC 8854, DOI 10.17487/RFC8854, January 4699 2021, . 4701 [RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP 4702 Control Protocol (RTCP) Multiplexing Using the Session 4703 Description Protocol (SDP)", RFC 8858, 4704 DOI 10.17487/RFC8858, January 2021, 4705 . 4707 [RFC8859] Nandakumar, S., "A Framework for Session Description 4708 Protocol (SDP) Attributes When Multiplexing", RFC 8859, 4709 DOI 10.17487/RFC8859, January 2021, 4710 . 4712 [RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings, 4713 "Negotiating Media Multiplexing Using the Session 4714 Description Protocol (SDP)", RFC 9143, 4715 DOI 10.17487/RFC9143, February 2022, 4716 . 4718 10.2. Informative References 4720 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 4721 Comfort Noise (CN)", RFC 3389, DOI 10.17487/RFC3389, 4722 September 2002, . 4724 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 4725 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 4726 RFC 3556, DOI 10.17487/RFC3556, July 2003, 4727 . 4729 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 4730 Tone Generation in the Session Initiation Protocol (SIP)", 4731 RFC 3960, DOI 10.17487/RFC3960, December 2004, 4732 . 4734 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 4735 Description Protocol (SDP) Security Descriptions for Media 4736 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 4737 . 4739 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 4740 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 4741 DOI 10.17487/RFC4588, July 2006, 4742 . 4744 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 4745 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 4746 DOI 10.17487/RFC4733, December 2006, 4747 . 4749 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 4750 (ICE): A Protocol for Network Address Translator (NAT) 4751 Traversal for Offer/Answer Protocols", RFC 5245, 4752 DOI 10.17487/RFC5245, April 2010, 4753 . 4755 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 4756 Real-Time Transport Control Protocol (RTCP): Opportunities 4757 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 4758 2009, . 4760 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 4761 Media Attributes in the Session Description Protocol 4762 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 4763 . 4765 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 4766 for Establishing a Secure Real-time Transport Protocol 4767 (SRTP) Security Context Using Datagram Transport Layer 4768 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 4769 2010, . 4771 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 4772 Security (DTLS) Extension to Establish Keys for the Secure 4773 Real-time Transport Protocol (SRTP)", RFC 5764, 4774 DOI 10.17487/RFC5764, May 2010, 4775 . 4777 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 4778 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 4779 March 2011, . 4781 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 4782 Transport Protocol (RTP) Header Extension for Client-to- 4783 Mixer Audio Level Indication", RFC 6464, 4784 DOI 10.17487/RFC6464, December 2011, 4785 . 4787 [RFC8828] Uberti, J. and G. Shieh, "WebRTC IP Address Handling 4788 Requirements", RFC 8828, DOI 10.17487/RFC8828, January 4789 2021, . 4791 [SDP4WebRTC] 4792 Nandakumar, S. and C. Jennings, "Annotated Example SDP for 4793 WebRTC", Work in Progress, Internet-Draft, draft-ietf- 4794 rtcweb-sdp-14, 17 December 2020, 4795 . 4798 [TS26.114] 3GPP, "3rd Generation Partnership Project; Technical 4799 Specification Group Services and System Aspects; IP 4800 Multimedia Subsystem (IMS); Multimedia Telephony; Media 4801 handling and interaction (Release 16)", 3GPP TS 26.114 4802 V16.3.0, September 2019, 4803 . 4805 [W3C.webrtc] 4806 Jennings, C., Ed., Boström, H., Ed., and J. Bruaroey, Ed., 4807 "WebRTC 1.0: Real-time Communication Between Browsers", 4808 World Wide Web Consortium PR PR-webrtc-20201215, December 4809 2020, . 4811 Appendix A. SDP ABNF Syntax 4813 For the syntax validation performed in Section 5.8, the following 4814 list of ABNF definitions is used: 4816 +=========================+==========================+ 4817 | Attribute | Reference | 4818 +=========================+==========================+ 4819 | ptime | Section 6 of [RFC4566] | 4820 +-------------------------+--------------------------+ 4821 | maxptime | Section 6 of [RFC4566] | 4822 +-------------------------+--------------------------+ 4823 | rtpmap | Section 6 of [RFC4566] | 4824 +-------------------------+--------------------------+ 4825 | recvonly | Section 9 of [RFC4566] | 4826 +-------------------------+--------------------------+ 4827 | sendrecv | Section 9 of [RFC4566] | 4828 +-------------------------+--------------------------+ 4829 | sendonly | Section 9 of [RFC4566] | 4830 +-------------------------+--------------------------+ 4831 | inactive | Section 9 of [RFC4566] | 4832 +-------------------------+--------------------------+ 4833 | fmtp | Section 9 of [RFC4566] | 4834 +-------------------------+--------------------------+ 4835 | rtcp | Section 2.1 of [RFC3605] | 4836 +-------------------------+--------------------------+ 4837 | setup | Section 4 of [RFC4145] | 4838 +-------------------------+--------------------------+ 4839 | fingerprint | Section 5 of [RFC8122] | 4840 +-------------------------+--------------------------+ 4841 | rtcp-fb | Section 4.2 of [RFC4585] | 4842 +-------------------------+--------------------------+ 4843 | extmap | Section 7 of [RFC5285] | 4844 +-------------------------+--------------------------+ 4845 | mid | Section 4 of [RFC5888] | 4846 +-------------------------+--------------------------+ 4847 | group | Section 5 of [RFC5888] | 4848 +-------------------------+--------------------------+ 4849 | imageattr | Section 3.1 of [RFC6236] | 4850 +-------------------------+--------------------------+ 4851 | extmap (encrypt option) | Section 4 of [RFC6904] | 4852 +-------------------------+--------------------------+ 4853 | candidate | Section 5.1 of [RFC8839] | 4854 +-------------------------+--------------------------+ 4855 | remote-candidates | Section 5.2 of [RFC8839] | 4856 +-------------------------+--------------------------+ 4857 | ice-lite | Section 5.3 of [RFC8839] | 4858 +-------------------------+--------------------------+ 4859 | ice-ufrag | Section 5.4 of [RFC8839] | 4860 +-------------------------+--------------------------+ 4861 | ice-pwd | Section 5.4 of [RFC8839] | 4862 +-------------------------+--------------------------+ 4863 | ice-options | Section 5.6 of [RFC8839] | 4864 +-------------------------+--------------------------+ 4865 | msid | Section 3 of [RFC8830] | 4866 +-------------------------+--------------------------+ 4867 | rid | Section 10 of [RFC8851] | 4868 +-------------------------+--------------------------+ 4869 | simulcast | Section 5.1 of [RFC8853] | 4870 +-------------------------+--------------------------+ 4871 | tls-id | Section 4 of [RFC8842] | 4872 +-------------------------+--------------------------+ 4873 Table 1: SDP ABNF References 4875 Acknowledgements 4877 Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter 4878 Thatcher provided significant text for this document. Bernard Aboba, 4879 Adam Bergkvist, Jan-Ivar Bruaroey, Dan Burnett, Ben Campbell, Alissa 4880 Cooper, Richard Ejzak, Stefan Håkansson, Ted Hardie, Christer 4881 Holmberg, Andrew Hutton, Randell Jesup, Matthew Kaufman, Anant 4882 Narayanan, Adam Roach, Robert Sparks, Neil Stratford, Martin Thomson, 4883 Sean Turner, and Magnus Westerlund all provided valuable feedback on 4884 this document. 4886 Authors' Addresses 4888 Justin Uberti 4889 Clubhouse 4890 Email: justin@uberti.name 4892 Cullen Jennings 4893 Cisco 4894 400 3rd Avenue SW 4895 Calgary AB T2P 4H2 4896 Canada 4897 Email: fluffy@iii.ca 4899 Eric Rescorla (editor) 4900 Mozilla 4901 Email: ekr@rtfm.com