idnits 2.17.1 draft-ietf-rtcweb-jsep-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. -- 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 3647 has weird spacing: '... mid a1...' == Line 3648 has weird spacing: '... attr candi...' == Line 3653 has weird spacing: '... mid a1...' == Line 3654 has weird spacing: '... attr candi...' == Line 3661 has weird spacing: '... mid a1...' == (11 more instances...) -- The document date (March 10, 2017) is 2603 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) -- Looks like a reference, but probably isn't: '0' on line 784 == Unused Reference: 'I-D.ietf-rtcweb-audio' is defined on line 4311, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtcweb-video' is defined on line 4335, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-avtext-rid-00 == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-4572-update-05 == Outdated reference: A later version (-32) exists of draft-ietf-mmusic-dtls-sdp-14 == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-msid-01 == Outdated reference: A later version (-12) exists of draft-ietf-mmusic-mux-exclusive-08 == Outdated reference: A later version (-15) exists of draft-ietf-mmusic-rid-04 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-04 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-01 == Outdated reference: A later version (-14) exists of draft-ietf-mmusic-sdp-simulcast-04 == Outdated reference: A later version (-11) exists of draft-ietf-rtcweb-audio-02 == Outdated reference: A later version (-10) exists of draft-ietf-rtcweb-fec-00 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-09 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-06 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-09 == Outdated reference: A later version (-06) exists of draft-ietf-rtcweb-video-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-ietf-avtext-lrr-03 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-ip-handling-01 == Outdated reference: A later version (-08) exists of draft-nandakumar-rtcweb-sdp-02 Summary: 6 errors (**), 0 flaws (~~), 28 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 Google 4 Intended status: Standards Track C. Jennings 5 Expires: September 11, 2017 Cisco 6 E. Rescorla, Ed. 7 Mozilla 8 March 10, 2017 10 Javascript Session Establishment Protocol 11 draft-ietf-rtcweb-jsep-19 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 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 11, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 4 56 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 59 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 60 3.2. Session Descriptions and State Machine . . . . . . . . . 7 61 3.3. Session Description Format . . . . . . . . . . . . . . . 11 62 3.4. Session Description Control . . . . . . . . . . . . . . . 11 63 3.4.1. RtpTransceivers . . . . . . . . . . . . . . . . . . . 11 64 3.4.2. RtpSenders . . . . . . . . . . . . . . . . . . . . . 12 65 3.4.3. RtpReceivers . . . . . . . . . . . . . . . . . . . . 12 66 3.5. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.5.1. ICE Gathering Overview . . . . . . . . . . . . . . . 12 68 3.5.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 13 69 3.5.2.1. ICE Candidate Format . . . . . . . . . . . . . . 13 70 3.5.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 14 71 3.5.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 15 72 3.6. Video Size Negotiation . . . . . . . . . . . . . . . . . 16 73 3.6.1. Creating an imageattr Attribute . . . . . . . . . . . 16 74 3.6.2. Interpreting an imageattr Attribute . . . . . . . . . 17 75 3.7. Simulcast . . . . . . . . . . . . . . . . . . . . . . . . 18 76 3.8. Interactions With Forking . . . . . . . . . . . . . . . . 19 77 3.8.1. Sequential Forking . . . . . . . . . . . . . . . . . 20 78 3.8.2. Parallel Forking . . . . . . . . . . . . . . . . . . 20 79 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.1. PeerConnection . . . . . . . . . . . . . . . . . . . . . 21 81 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 21 82 4.1.2. addTrack . . . . . . . . . . . . . . . . . . . . . . 23 83 4.1.3. removeTrack . . . . . . . . . . . . . . . . . . . . . 24 84 4.1.4. addTransceiver . . . . . . . . . . . . . . . . . . . 24 85 4.1.5. createDataChannel . . . . . . . . . . . . . . . . . . 24 86 4.1.6. createOffer . . . . . . . . . . . . . . . . . . . . . 24 87 4.1.7. createAnswer . . . . . . . . . . . . . . . . . . . . 25 88 4.1.8. SessionDescriptionType . . . . . . . . . . . . . . . 26 89 4.1.8.1. Use of Provisional Answers . . . . . . . . . . . 27 90 4.1.8.2. Rollback . . . . . . . . . . . . . . . . . . . . 28 91 4.1.9. setLocalDescription . . . . . . . . . . . . . . . . . 29 92 4.1.10. setRemoteDescription . . . . . . . . . . . . . . . . 29 93 4.1.11. currentLocalDescription . . . . . . . . . . . . . . . 30 94 4.1.12. pendingLocalDescription . . . . . . . . . . . . . . . 30 95 4.1.13. currentRemoteDescription . . . . . . . . . . . . . . 30 96 4.1.14. pendingRemoteDescription . . . . . . . . . . . . . . 30 97 4.1.15. canTrickleIceCandidates . . . . . . . . . . . . . . . 31 98 4.1.16. setConfiguration . . . . . . . . . . . . . . . . . . 31 99 4.1.17. addIceCandidate . . . . . . . . . . . . . . . . . . . 32 100 4.2. RtpTransceiver . . . . . . . . . . . . . . . . . . . . . 33 101 4.2.1. stop . . . . . . . . . . . . . . . . . . . . . . . . 33 102 4.2.2. stopped . . . . . . . . . . . . . . . . . . . . . . . 33 103 4.2.3. setDirection . . . . . . . . . . . . . . . . . . . . 33 104 4.2.4. direction . . . . . . . . . . . . . . . . . . . . . . 33 105 4.2.5. currentDirection . . . . . . . . . . . . . . . . . . 34 106 4.2.6. setCodecPreferences . . . . . . . . . . . . . . . . . 34 107 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 34 108 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 35 109 5.1.1. Usage Requirements . . . . . . . . . . . . . . . . . 35 110 5.1.2. Profile Names and Interoperability . . . . . . . . . 35 111 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 36 112 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 36 113 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 43 114 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 47 115 5.2.3.1. IceRestart . . . . . . . . . . . . . . . . . . . 47 116 5.2.3.2. VoiceActivityDetection . . . . . . . . . . . . . 47 117 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 48 118 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 48 119 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 54 120 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 55 121 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 56 122 5.4. Modifying an Offer or Answer . . . . . . . . . . . . . . 56 123 5.5. Processing a Local Description . . . . . . . . . . . . . 57 124 5.6. Processing a Remote Description . . . . . . . . . . . . . 57 125 5.7. Parsing a Session Description . . . . . . . . . . . . . . 58 126 5.7.1. Session-Level Parsing . . . . . . . . . . . . . . . . 58 127 5.7.2. Media Section Parsing . . . . . . . . . . . . . . . . 60 128 5.7.3. Semantics Verification . . . . . . . . . . . . . . . 62 129 5.8. Applying a Local Description . . . . . . . . . . . . . . 64 130 5.9. Applying a Remote Description . . . . . . . . . . . . . . 65 131 5.10. Applying an Answer . . . . . . . . . . . . . . . . . . . 69 132 6. Processing RTP/RTCP . . . . . . . . . . . . . . . . . . . . . 71 133 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 71 134 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 72 135 7.2. Detailed Example . . . . . . . . . . . . . . . . . . . . 77 136 7.3. Early Transport Warmup Example . . . . . . . . . . . . . 86 137 8. Security Considerations . . . . . . . . . . . . . . . . . . . 94 138 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 95 139 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 140 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95 141 11.1. Normative References . . . . . . . . . . . . . . . . . . 95 142 11.2. Informative References . . . . . . . . . . . . . . . . . 99 143 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 101 144 Appendix B. Appendix B . . . . . . . . . . . . . . . . . . . . . 102 145 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 107 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116 148 1. Introduction 150 This document describes how the W3C WEBRTC RTCPeerConnection 151 interface [W3C.WD-webrtc-20140617] is used to control the setup, 152 management and teardown of a multimedia session. 154 1.1. General Design of JSEP 156 The thinking behind WebRTC call setup has been to fully specify and 157 control the media plane, but to leave the signaling plane up to the 158 application as much as possible. The rationale is that different 159 applications may prefer to use different protocols, such as the 160 existing SIP or Jingle call signaling protocols, or something custom 161 to the particular application, perhaps for a novel use case. In this 162 approach, the key information that needs to be exchanged is the 163 multimedia session description, which specifies the necessary 164 transport and media configuration information necessary to establish 165 the media plane. 167 With these considerations in mind, this document describes the 168 Javascript Session Establishment Protocol (JSEP) that allows for full 169 control of the signaling state machine from Javascript. As described 170 above, JSEP assumes a model in which a Javascript application 171 executes inside a runtime containing WebRTC APIs (the "JSEP 172 implementation"). The JSEP implementation is almost entirely 173 divorced from the core signaling flow, which is instead handled by 174 the Javascript making use of two interfaces: (1) passing in local and 175 remote session descriptions and (2) interacting with the ICE state 176 machine. The combination of the JSEP implementation and the 177 Javascript application is referred to throughout this document as a 178 "JSEP endpoint". 180 In this document, the use of JSEP is described as if it always occurs 181 between two JSEP endpoints. Note though in many cases it will 182 actually be between a JSEP endpoint and some kind of server, such as 183 a gateway or MCU. This distinction is invisible to the JSEP 184 endpoint; it just follows the instructions it is given via the API. 186 JSEP's handling of session descriptions is simple and 187 straightforward. Whenever an offer/answer exchange is needed, the 188 initiating side creates an offer by calling a createOffer() API. The 189 application then uses that offer to set up its local config via the 190 setLocalDescription() API. The offer is finally sent off to the 191 remote side over its preferred signaling mechanism (e.g., 192 WebSockets); upon receipt of that offer, the remote party installs it 193 using the setRemoteDescription() API. 195 To complete the offer/answer exchange, the remote party uses the 196 createAnswer() API to generate an appropriate answer, applies it 197 using the setLocalDescription() API, and sends the answer back to the 198 initiator over the signaling channel. When the initiator gets that 199 answer, it installs it using the setRemoteDescription() API, and 200 initial setup is complete. This process can be repeated for 201 additional offer/answer exchanges. 203 Regarding ICE [RFC5245], JSEP decouples the ICE state machine from 204 the overall signaling state machine, as the ICE state machine must 205 remain in the JSEP implementation, because only the implementation 206 has the necessary knowledge of candidates and other transport info. 207 Performing this separation also provides additional flexibility; in 208 protocols that decouple session descriptions from transport, such as 209 Jingle, the session description can be sent immediately and the 210 transport information can be sent when available. In protocols that 211 don't, such as SIP, the information can be used in the aggregated 212 form. Sending transport information separately can allow for faster 213 ICE and DTLS startup, since ICE checks can start as soon as any 214 transport information is available rather than waiting for all of it. 216 Through its abstraction of signaling, the JSEP approach does require 217 the application to be aware of the signaling process. While the 218 application does not need to understand the contents of session 219 descriptions to set up a call, the application must call the right 220 APIs at the right times, convert the session descriptions and ICE 221 information into the defined messages of its chosen signaling 222 protocol, and perform the reverse conversion on the messages it 223 receives from the other side. 225 One way to mitigate this is to provide a Javascript library that 226 hides this complexity from the developer; said library would 227 implement a given signaling protocol along with its state machine and 228 serialization code, presenting a higher level call-oriented interface 229 to the application developer. For example, libraries exist to adapt 230 the JSEP API into an API suitable for a SIP or XMPP. Thus, JSEP 231 provides greater control for the experienced developer without 232 forcing any additional complexity on the novice developer. 234 1.2. Other Approaches Considered 236 One approach that was considered instead of JSEP was to include a 237 lightweight signaling protocol. Instead of providing session 238 descriptions to the API, the API would produce and consume messages 239 from this protocol. While providing a more high-level API, this put 240 more control of signaling within the JSEP implementation, forcing it 241 to have to understand and handle concepts like signaling glare. In 242 addition, it prevented the application from driving the state machine 243 to a desired state, as is needed in the page reload case. 245 A second approach that was considered but not chosen was to decouple 246 the management of the media control objects from session 247 descriptions, instead offering APIs that would control each component 248 directly. This was rejected based on a feeling that requiring 249 exposure of this level of complexity to the application programmer 250 would not be beneficial; it would result in an API where even a 251 simple example would require a significant amount of code to 252 orchestrate all the needed interactions, as well as creating a large 253 API surface that needed to be agreed upon and documented. In 254 addition, these API points could be called in any order, resulting in 255 a more complex set of interactions with the media subsystem than the 256 JSEP approach, which specifies how session descriptions are to be 257 evaluated and applied. 259 One variation on JSEP that was considered was to keep the basic 260 session description-oriented API, but to move the mechanism for 261 generating offers and answers out of the JSEP implementation. 262 Instead of providing createOffer/createAnswer methods within the 263 implementation, this approach would instead expose a getCapabilities 264 API which would provide the application with the information it 265 needed in order to generate its own session descriptions. This 266 increases the amount of work that the application needs to do; it 267 needs to know how to generate session descriptions from capabilities, 268 and especially how to generate the correct answer from an arbitrary 269 offer and the supported capabilities. While this could certainly be 270 addressed by using a library like the one mentioned above, it 271 basically forces the use of said library even for a simple example. 272 Providing createOffer/createAnswer avoids this problem. 274 2. Terminology 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 278 document are to be interpreted as described in [RFC2119]. 280 3. Semantics and Syntax 282 3.1. Signaling Model 284 JSEP does not specify a particular signaling model or state machine, 285 other than the generic need to exchange session descriptions in the 286 fashion described by [RFC3264](offer/answer) in order for both sides 287 of the session to know how to conduct the session. JSEP provides 288 mechanisms to create offers and answers, as well as to apply them to 289 a session. However, the JSEP implementation is totally decoupled 290 from the actual mechanism by which these offers and answers are 291 communicated to the remote side, including addressing, 292 retransmission, forking, and glare handling. These issues are left 293 entirely up to the application; the application has complete control 294 over which offers and answers get handed to the implementation, and 295 when. 297 +-----------+ +-----------+ 298 | Web App |<--- App-Specific Signaling -->| Web App | 299 +-----------+ +-----------+ 300 ^ ^ 301 | SDP | SDP 302 V V 303 +-----------+ +-----------+ 304 | JSEP |<----------- Media ------------>| JSEP | 305 | Impl. | | Impl. | 306 +-----------+ +-----------+ 308 Figure 1: JSEP Signaling Model 310 3.2. Session Descriptions and State Machine 312 In order to establish the media plane, the user agent needs specific 313 parameters to indicate what to transmit to the remote side, as well 314 as how to handle the media that is received. These parameters are 315 determined by the exchange of session descriptions in offers and 316 answers, and there are certain details to this process that must be 317 handled in the JSEP APIs. 319 Whether a session description applies to the local side or the remote 320 side affects the meaning of that description. For example, the list 321 of codecs sent to a remote party indicates what the local side is 322 willing to receive, which, when intersected with the set of codecs 323 the remote side supports, specifies what the remote side should send. 324 However, not all parameters follow this rule; for example, the 325 fingerprints [I-D.ietf-mmusic-4572-update] sent to a remote party are 326 calculated based on the local certificate(s) offered; the remote 327 party MUST either accept these parameters or reject them altogether, 328 with no option to choose different values. 330 In addition, various RFCs put different conditions on the format of 331 offers versus answers. For example, an offer may propose an 332 arbitrary number of m= sections (i.e., media descriptions as 333 described in [RFC4566], Section 5.14), but an answer must contain the 334 exact same number as the offer. 336 Lastly, while the exact media parameters are only known only after an 337 offer and an answer have been exchanged, it is possible for the 338 offerer to receive media after they have sent an offer and before 339 they have received an answer. To properly process incoming media in 340 this case, the offerer's media handler must be aware of the details 341 of the offer before the answer arrives. 343 Therefore, in order to handle session descriptions properly, the user 344 agent needs: 346 1. To know if a session description pertains to the local or remote 347 side. 349 2. To know if a session description is an offer or an answer. 351 3. To allow the offer to be specified independently of the answer. 353 JSEP addresses this by adding both setLocalDescription and 354 setRemoteDescription methods and having session description objects 355 contain a type field indicating the type of session description being 356 supplied. This satisfies the requirements listed above for both the 357 offerer, who first calls setLocalDescription(sdp [offer]) and then 358 later setRemoteDescription(sdp [answer]), as well as for the 359 answerer, who first calls setRemoteDescription(sdp [offer]) and then 360 later setLocalDescription(sdp [answer]). 362 JSEP also allows for an answer to be treated as provisional by the 363 application. Provisional answers provide a way for an answerer to 364 communicate initial session parameters back to the offerer, in order 365 to allow the session to begin, while allowing a final answer to be 366 specified later. This concept of a final answer is important to the 367 offer/answer model; when such an answer is received, any extra 368 resources allocated by the caller can be released, now that the exact 369 session configuration is known. These "resources" can include things 370 like extra ICE components, TURN candidates, or video decoders. 371 Provisional answers, on the other hand, do no such deallocation; as a 372 result, multiple dissimilar provisional answers, with their own codec 373 choices, transport parameters, etc., can be received and applied 374 during call setup. Note that the final answer itself may be 375 different than any received provisional answers. 377 In [RFC3264], the constraint at the signaling level is that only one 378 offer can be outstanding for a given session, but at the media stack 379 level, a new offer can be generated at any point. For example, when 380 using SIP for signaling, if one offer is sent, then cancelled using a 381 SIP CANCEL, another offer can be generated even though no answer was 382 received for the first offer. To support this, the JSEP media layer 383 can provide an offer via the createOffer() method whenever the 384 Javascript application needs one for the signaling. The answerer can 385 send back zero or more provisional answers, and finally end the 386 offer-answer exchange by sending a final answer. The state machine 387 for this is as follows: 389 setRemote(OFFER) setLocal(PRANSWER) 390 /-----\ /-----\ 391 | | | | 392 v | v | 393 +---------------+ | +---------------+ | 394 | |----/ | |----/ 395 | | setLocal(PRANSWER) | | 396 | Remote-Offer |------------------- >| Local-Pranswer| 397 | | | | 398 | | | | 399 +---------------+ +---------------+ 400 ^ | | 401 | | setLocal(ANSWER) | 402 setRemote(OFFER) | | 403 | V setLocal(ANSWER) | 404 +---------------+ | 405 | | | 406 | |<---------------------------+ 407 | Stable | 408 | |<---------------------------+ 409 | | | 410 +---------------+ setRemote(ANSWER) | 411 ^ | | 412 | | setLocal(OFFER) | 413 setRemote(ANSWER) | | 414 | V | 415 +---------------+ +---------------+ 416 | | | | 417 | | setRemote(PRANSWER) | | 418 | Local-Offer |------------------- >|Remote-Pranswer| 419 | | | | 420 | |----\ | |----\ 421 +---------------+ | +---------------+ | 422 ^ | ^ | 423 | | | | 424 \-----/ \-----/ 425 setLocal(OFFER) setRemote(PRANSWER) 427 Figure 2: JSEP State Machine 429 Aside from these state transitions there is no other difference 430 between the handling of provisional ("pranswer") and final ("answer") 431 answers. 433 3.3. Session Description Format 435 JSEP's session descriptions use SDP syntax for their internal 436 representation. While this format is not optimal for manipulation 437 from Javascript, it is widely accepted, and frequently updated with 438 new features; any alternate encoding of session descriptions would 439 have to keep pace with the changes to SDP, at least until the time 440 that this new encoding eclipsed SDP in popularity. 442 However, to simplify Javascript processing, and provide for future 443 flexibility, the SDP syntax is encapsulated within a 444 SessionDescription object, which can be constructed from SDP, and be 445 serialized out to SDP. If future specifications agree on a JSON 446 format for session descriptions, we could easily enable this object 447 to generate and consume that JSON. 449 Other methods may be added to SessionDescription in the future to 450 simplify handling of SessionDescriptions from Javascript. In the 451 meantime, Javascript libraries can be used to perform these 452 manipulations. 454 Note that most applications should be able to treat the 455 SessionDescriptions produced and consumed by these various API calls 456 as opaque blobs; that is, the application will not need to read or 457 change them. 459 3.4. Session Description Control 461 In order to give the application control over various common session 462 parameters, JSEP provides control surfaces which tell the JSEP 463 implementation how to generate session descriptions. This avoids the 464 need for Javascript to modify session descriptions in most cases. 466 Changes to these objects result in changes to the session 467 descriptions generated by subsequent createOffer/Answer calls. 469 3.4.1. RtpTransceivers 471 RtpTransceivers allow the application to control the RTP media 472 associated with one m= section. Each RtpTransceiver has an RtpSender 473 and an RtpReceiver, which an application can use to control the 474 sending and receiving of RTP media. The application may also modify 475 the RtpTransceiver directly, for instance, by stopping it. 477 RtpTransceivers generally have a 1:1 mapping with m= sections, 478 although there may be more RtpTransceivers than m= sections when 479 RtpTransceivers are created but not yet associated with a m= section, 480 or if RtpTransceivers have been stopped and disassociated from m= 481 sections. An RtpTransceiver is said to be associated with an m= 482 section if its mid property is non-null; otherwise it is said to be 483 disassociated. The associated m= section is determined using a 484 mapping between transceivers and m= section indices, formed when 485 creating an offer or applying a remote offer. An RtpTransceiver is 486 never associated with more than one m= section, and once a session 487 description is applied, a m= section is always associated with 488 exactly one RtpTransceiver. 490 RtpTransceivers can be created explicitly by the application or 491 implicitly by calling setRemoteDescription with an offer that adds 492 new m= sections. 494 3.4.2. RtpSenders 496 RtpSenders allow the application to control how RTP media is sent. 497 An RtpSender is conceptually responsible for the outgoing RTP 498 stream(s) described by an m= section. This includes encoding the 499 attached MediaStreamTrack, sending RTP media packets, and generating/ 500 processing RTCP for the outgoing RTP streams(s). 502 3.4.3. RtpReceivers 504 RtpReceivers allow the application to inspect how RTP media is 505 received. An RtpReceiver is conceptually responsible for the 506 incoming RTP stream(s) described by an m= section. This includes 507 processing received RTP media packets, decoding the incoming 508 stream(s) to produce a remote MediaStreamTrack, and generating/ 509 processing RTCP for the incoming RTP stream(s). 511 3.5. ICE 513 3.5.1. ICE Gathering Overview 515 JSEP gathers ICE candidates as needed by the application. Collection 516 of ICE candidates is referred to as a gathering phase, and this is 517 triggered either by the addition of a new or recycled m= section to 518 the local session description, or new ICE credentials in the 519 description, indicating an ICE restart. Use of new ICE credentials 520 can be triggered explicitly by the application, or implicitly by the 521 JSEP implementation in response to changes in the ICE configuration. 523 When the ICE configuration changes in a way that requires a new 524 gathering phase, a 'needs-ice-restart' bit is set. When this bit is 525 set, calls to the createOffer API will generate new ICE credentials. 526 This bit is cleared by a call to the setLocalDescription API with new 527 ICE credentials from either an offer or an answer, i.e., from either 528 a local- or remote-initiated ICE restart. 530 When a new gathering phase starts, the ICE agent will notify the 531 application that gathering is occurring through an event. Then, when 532 each new ICE candidate becomes available, the ICE agent will supply 533 it to the application via an additional event; these candidates will 534 also automatically be added to the current and/or pending local 535 session description. Finally, when all candidates have been 536 gathered, an event will be dispatched to signal that the gathering 537 process is complete. 539 Note that gathering phases only gather the candidates needed by 540 new/recycled/restarting m= sections; other m= sections continue to 541 use their existing candidates. Also, when bundling is active, 542 candidates are only gathered (and exchanged) for the m= sections 543 referenced in BUNDLE-tags, as described in 544 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 546 3.5.2. ICE Candidate Trickling 548 Candidate trickling is a technique through which a caller may 549 incrementally provide candidates to the callee after the initial 550 offer has been dispatched; the semantics of "Trickle ICE" are defined 551 in [I-D.ietf-ice-trickle]. This process allows the callee to begin 552 acting upon the call and setting up the ICE (and perhaps DTLS) 553 connections immediately, without having to wait for the caller to 554 gather all possible candidates. This results in faster media setup 555 in cases where gathering is not performed prior to initiating the 556 call. 558 JSEP supports optional candidate trickling by providing APIs, as 559 described above, that provide control and feedback on the ICE 560 candidate gathering process. Applications that support candidate 561 trickling can send the initial offer immediately and send individual 562 candidates when they get the notified of a new candidate; 563 applications that do not support this feature can simply wait for the 564 indication that gathering is complete, and then create and send their 565 offer, with all the candidates, at this time. 567 Upon receipt of trickled candidates, the receiving application will 568 supply them to its ICE agent. This triggers the ICE agent to start 569 using the new remote candidates for connectivity checks. 571 3.5.2.1. ICE Candidate Format 573 In JSEP, ICE candidates are abstracted by an IceCandidate object, and 574 as with session descriptions, SDP syntax is used for the internal 575 representation. 577 The candidate details are specified in an IceCandidate field, using 578 the same SDP syntax as the "candidate-attribute" field defined in 579 [RFC5245], Section 15.1. For example: 581 candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host 583 The IceCandidate object contains a field to indicate which ICE ufrag 584 it is associated with, as defined in [RFC5245], Section 15.4. This 585 value is used to determine which session description (and thereby 586 which gathering phase) this IceCandidate belongs to, which helps 587 resolve ambiguities during ICE restarts. If this field is absent in 588 a received IceCandidate (perhaps when communicating with a non-JSEP 589 endpoint), the most recently received session description is assumed. 591 The IceCandidate object also contains fields to indicate which m= 592 section it is associated with, which can be identified in one of two 593 ways, either by a m= section index, or a MID. The m= section index 594 is a zero-based index, with index N referring to the N+1th m= section 595 in the session description referenced by this IceCandidate. The MID 596 is a "media stream identification" value, as defined in [RFC5888], 597 Section 4, which provides a more robust way to identify the m= 598 section in the session description, using the MID of the associated 599 RtpTransceiver object (which may have been locally generated by the 600 answerer when interacting with a non-JSEP endpoint that does not 601 support the MID attribute, as discussed in Section 5.9 below). If 602 the MID field is present in a received IceCandidate, it MUST be used 603 for identification; otherwise, the m= section index is used instead. 605 When creating an IceCandidate object, JSEP implementations MUST 606 populate all of these fields. 608 3.5.3. ICE Candidate Policy 610 Typically, when gathering ICE candidates, the JSEP implementation 611 will gather all possible forms of initial candidates - host, server 612 reflexive, and relay. However, in certain cases, applications may 613 want to have more specific control over the gathering process, due to 614 privacy or related concerns. For example, one may want to only use 615 relay candidates, to leak as little location information as possible 616 (keeping in mind that this choice comes with corresponding 617 operational costs). To accomplish this, JSEP allows the application 618 to restrict which ICE candidates are used in a session. Note that 619 this filtering is applied on top of any restrictions the 620 implementation chooses to enforce regarding which IP addresses are 621 permitted for the application, as discussed in 622 [I-D.ietf-rtcweb-ip-handling]. 624 There may also be cases where the application wants to change which 625 types of candidates are used while the session is active. A prime 626 example is where a callee may initially want to use only relay 627 candidates, to avoid leaking location information to an arbitrary 628 caller, but then change to use all candidates (for lower operational 629 cost) once the user has indicated they want to take the call. For 630 this scenario, the JSEP implementation MUST allow the candidate 631 policy to be changed in mid-session, subject to the aforementioned 632 interactions with local policy. 634 To administer the ICE candidate policy, the JSEP implementation will 635 determine the current setting at the start of each gathering phase. 636 Then, during the gathering phase, the implementation MUST NOT expose 637 candidates disallowed by the current policy to the application, use 638 them as the source of connectivity checks, or indirectly expose them 639 via other fields, such as the raddr/rport attributes for other ICE 640 candidates. Later, if a different policy is specified by the 641 application, the application can apply it by kicking off a new 642 gathering phase via an ICE restart. 644 3.5.4. ICE Candidate Pool 646 JSEP applications typically inform the JSEP implementation to begin 647 ICE gathering via the information supplied to setLocalDescription, as 648 this is where the app specifies the number of media streams, and 649 thereby ICE components, for which to gather candidates. However, to 650 accelerate cases where the application knows the number of ICE 651 components to use ahead of time, it may ask the implementation to 652 gather a pool of potential ICE candidates to help ensure rapid media 653 setup. 655 When setLocalDescription is eventually called, and the JSEP 656 implementation goes to gather the needed ICE candidates, it SHOULD 657 start by checking if any candidates are available in the pool. If 658 there are candidates in the pool, they SHOULD be handed to the 659 application immediately via the ICE candidate event. If the pool 660 becomes depleted, either because a larger-than-expected number of ICE 661 components is used, or because the pool has not had enough time to 662 gather candidates, the remaining candidates are gathered as usual. 663 This only occurs for the first offer/answer exchange, after which the 664 candidate pool is emptied and no longer used. 666 One example of where this concept is useful is an application that 667 expects an incoming call at some point in the future, and wants to 668 minimize the time it takes to establish connectivity, to avoid 669 clipping of initial media. By pre-gathering candidates into the 670 pool, it can exchange and start sending connectivity checks from 671 these candidates almost immediately upon receipt of a call. Note 672 though that by holding on to these pre-gathered candidates, which 673 will be kept alive as long as they may be needed, the application 674 will consume resources on the STUN/TURN servers it is using. 676 3.6. Video Size Negotiation 678 Video size negotiation is the process through which a receiver can 679 use the "a=imageattr" SDP attribute [RFC6236] to indicate what video 680 frame sizes it is capable of receiving. A receiver may have hard 681 limits on what its video decoder can process, or it may have some 682 maximum set by policy. 684 Note that certain codecs support transmission of samples with aspect 685 ratios other than 1.0 (i.e., non-square pixels). JSEP 686 implementations will not transmit non-square pixels, but SHOULD 687 receive and render such video with the correct aspect ratio. 688 However, sample aspect ratio has no impact on the size negotiation 689 described below; all dimensions are measured in pixels, whether 690 square or not. 692 3.6.1. Creating an imageattr Attribute 694 The receiver will first intersect any known local limits (e.g., 695 hardware decoder capababilities, local policy) to determine the 696 absolute minimum and maximum sizes it can receive. If there are no 697 known local limits, the "a=imageattr" attribute SHOULD be omitted. 699 Otherwise, an "a=imageattr" attribute is created with "recv" 700 direction, and the resulting resolution space formed from the 701 aforementioned intersection is used to specify its minimum and 702 maximum x= and y= values. If the intersection is the null set, i.e., 703 the degenerate case of no permitted resolutions, this MUST be 704 represented by x=0 and y=0 values. 706 The rules here express a single set of preferences, and therefore, 707 the "a=imageattr" q= value is not important. It SHOULD be set to 708 1.0. 710 The "a=imageattr" field is payload type specific. When all video 711 codecs supported have the same capabilities, use of a single 712 attribute, with the wildcard payload type (*), is RECOMMENDED. 713 However, when the supported video codecs have different limitations, 714 specific "a=imageattr" attributes MUST be inserted for each payload 715 type. 717 As an example, consider a system with a multiformat video decoder, 718 which is capable of decoding any resolution from 48x48 to 720p, In 719 this case, the implementation would generate this attribute: 721 a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0] 723 This declaration indicates that the receiver is capable of decoding 724 any image resolution from 48x48 up to 1280x720 pixels. 726 3.6.2. Interpreting an imageattr Attribute 728 [RFC6236] defines "a=imageattr" to be an advisory field. This means 729 that it does not absolutely constrain the video formats that the 730 sender can use, but gives an indication of the preferred values. 732 This specification prescribes more specific behavior. When a sender 733 of a given MediaStreamTrack, which is producing video of a certain 734 resolution, receives an "a=imageattr recv" attribute, it MUST check 735 to see if the original resolution meets the size criteria specified 736 in the attribute, and adapt the resolution accordingly by scaling (if 737 appropriate). Note that when considering a MediaStreamTrack that is 738 producing rotated video, the unrotated resolution MUST be used. This 739 is required regardless of whether the receiver supports performing 740 receive-side rotation (e.g., through CVO [TS26.114]), as it 741 significantly simplifies the matching logic. 743 For the purposes of resolution negotiation, only size limits are 744 considered. Any other values, e.g. picture or sample aspect ratio, 745 MUST be ignored. 747 When communicating with a non-JSEP endpoint, multiple relevant 748 "a=imageattr recv" attributes may be present in a received m= 749 section. If this occurs, attributes other than the one with the 750 highest "q=" value MUST be ignored. If multiple attributes have the 751 same "q=" value, those that appear after the first such attribute in 752 the m= section MUST be ignored. 754 If an "a=imageattr recv" attribute references a different video 755 payload type than what has been selected for sending the 756 MediaStreamTrack, it MUST be ignored. 758 If the original resolution matches the size limits in the attribute, 759 the track MUST be transmitted untouched. 761 If the original resolution exceeds the size limits in the attribute, 762 the sender SHOULD apply downscaling to the output of the 763 MediaStreamTrack in order to satisfy the limits. Downscaling MUST 764 NOT change the track aspect ratio. 766 If the original resolution is less than the size limits in the 767 attribute, upscaling is needed, but this may not be appropriate in 768 all cases. To address this concern, the application can set an 769 upscaling policy for each sent track. For this case, if upscaling is 770 permitted by policy, the sender SHOULD apply upscaling in order to 771 provide the desired resolution. Otherwise, the sender MUST NOT apply 772 upscaling. The sender SHOULD NOT upscale in other cases, even if the 773 policy permits it. Upscaling MUST NOT change the track aspect ratio. 775 If there is no appropriate and permitted scaling mechanism that 776 allows the received size limits to be satisfied, the sender MUST NOT 777 transmit the track. 779 If the attribute includes a "sar=" (sample aspect ratio) value set to 780 something other than "1.0", indicating the receiver wants to receive 781 non-square pixels, this cannot be satisfied and the sender MUST NOT 782 transmit the track. 784 In the special case of receiving a maximum resolution of [0, 0], as 785 described above, the sender MUST NOT transmit the track. 787 3.7. Simulcast 789 JSEP supports simulcast transmission of a MediaStreamTrack, where 790 multiple encodings of the source media can be transmitted within the 791 context of a single m= section. The current JSEP API is designed to 792 allow applications to send simulcasted media but only to receive a 793 single encoding. This allows for multi-user scenarios where each 794 sending client sends multiple encodings to a server, which then, for 795 each receiving client, chooses the appropriate encoding to forward. 797 Applications request support for simulcast by configuring multiple 798 encodings on an RtpSender, which, upon generation of an offer or 799 answer, are indicated in SDP markings on the corresponding m= 800 section, as described below. Receivers that understand simulcast and 801 are willing to receive it will also include SDP markings to indicate 802 their support, and JSEP endpoints will use these markings to 803 determine whether simulcast is permitted for a given RtpSender. If 804 simulcast support is not negotiated, the RtpSender will only use the 805 first configured encoding. 807 Note that the exact simulcast parameters are up to the sending 808 application. While the aforementioned SDP markings are provided to 809 ensure the remote side can receive and demux multiple simulcast 810 encodings, the specific resolutions and bitrates to be used for each 811 encoding are purely a send-side decision in JSEP. 813 JSEP currently does not provide a mechanism to configure receipt of 814 simulcast. This means that if simulcast is offered by the remote 815 endpoint, the answer generated by a JSEP endpoint will not indicate 816 support for receipt of simulcast, and as such the remote endpoint 817 will only send a single encoding per m= section. 819 In addition, JSEP does not provide a mechanism to handle an incoming 820 offer requesting simulcast from the JSEP endpoint. This means that 821 established simulcast streams will continue to work through a 822 received re-offer, but setting up initial simulcast by way of a 823 received offer requires out-of-band signaling or SDP inspection. 824 Future versions of this specification may add additional APIs to 825 provide direct control. 827 When using JSEP to transmit multiple encodings from a RtpSender, the 828 techniques from [I-D.ietf-mmusic-sdp-simulcast] and 829 [I-D.ietf-mmusic-rid] are used. Specifically, when multiple 830 encodings have been configured for a RtpSender, the m= section for 831 the RtpSender will include an "a=simulcast" attribute, as defined in 832 [I-D.ietf-mmusic-sdp-simulcast], Section 6.2, with a "send" simulcast 833 stream description that lists each desired encoding, and no "recv" 834 simulcast stream description. The m= section will also include an 835 "a=rid" attribute for each encoding, as specified in 836 [I-D.ietf-mmusic-rid], Section 4; the use of RID identifiers allows 837 the individual encodings to be disambiguated even though they are all 838 part of the same m= section. 840 3.8. Interactions With Forking 842 Some call signaling systems allow various types of forking where an 843 SDP Offer may be provided to more than one device. For example, SIP 844 [RFC3261] defines both a "Parallel Search" and "Sequential Search". 845 Although these are primarily signaling level issues that are outside 846 the scope of JSEP, they do have some impact on the configuration of 847 the media plane that is relevant. When forking happens at the 848 signaling layer, the Javascript application responsible for the 849 signaling needs to make the decisions about what media should be sent 850 or received at any point of time, as well as which remote endpoint it 851 should communicate with; JSEP is used to make sure the media engine 852 can make the RTP and media perform as required by the application. 853 The basic operations that the applications can have the media engine 854 do are: 856 o Start exchanging media with a given remote peer, but keep all the 857 resources reserved in the offer. 859 o Start exchanging media with a given remote peer, and free any 860 resources in the offer that are not being used. 862 3.8.1. Sequential Forking 864 Sequential forking involves a call being dispatched to multiple 865 remote callees, where each callee can accept the call, but only one 866 active session ever exists at a time; no mixing of received media is 867 performed. 869 JSEP handles sequential forking well, allowing the application to 870 easily control the policy for selecting the desired remote endpoint. 871 When an answer arrives from one of the callees, the application can 872 choose to apply it either as a provisional answer, leaving open the 873 possibility of using a different answer in the future, or apply it as 874 a final answer, ending the setup flow. 876 In a "first-one-wins" situation, the first answer will be applied as 877 a final answer, and the application will reject any subsequent 878 answers. In SIP parlance, this would be ACK + BYE. 880 In a "last-one-wins" situation, all answers would be applied as 881 provisional answers, and any previous call leg will be terminated. 882 At some point, the application will end the setup process, perhaps 883 with a timer; at this point, the application could reapply the 884 pending remote description as a final answer. 886 3.8.2. Parallel Forking 888 Parallel forking involves a call being dispatched to multiple remote 889 callees, where each callee can accept the call, and multiple 890 simultaneous active signaling sessions can be established as a 891 result. If multiple callees send media at the same time, the 892 possibilities for handling this are described in Section 3.1 of 893 [RFC3960]. Most SIP devices today only support exchanging media with 894 a single device at a time, and do not try to mix multiple early media 895 audio sources, as that could result in a confusing situation. For 896 example, consider having a European ringback tone mixed together with 897 the North American ringback tone - the resulting sound would not be 898 like either tone, and would confuse the user. If the signaling 899 application wishes to only exchange media with one of the remote 900 endpoints at a time, then from a media engine point of view, this is 901 exactly like the sequential forking case. 903 In the parallel forking case where the Javascript application wishes 904 to simultaneously exchange media with multiple peers, the flow is 905 slightly more complex, but the Javascript application can follow the 906 strategy that [RFC3960] describes using UPDATE. The UPDATE approach 907 allows the signaling to set up a separate media flow for each peer 908 that it wishes to exchange media with. In JSEP, this offer used in 909 the UPDATE would be formed by simply creating a new PeerConnection 910 and making sure that the same local media streams have been added 911 into this new PeerConnection. Then the new PeerConnection object 912 would produce a SDP offer that could be used by the signaling to 913 perform the UPDATE strategy discussed in [RFC3960]. 915 As a result of sharing the media streams, the application will end up 916 with N parallel PeerConnection sessions, each with a local and remote 917 description and their own local and remote addresses. The media flow 918 from these sessions can be managed using setDirection (see 919 Section 4.2.3), or the application can choose to play out the media 920 from all sessions mixed together. Of course, if the application 921 wants to only keep a single session, it can simply terminate the 922 sessions that it no longer needs. 924 4. Interface 926 This section details the basic operations that must be present to 927 implement JSEP functionality. The actual API exposed in the W3C API 928 may have somewhat different syntax, but should map easily to these 929 concepts. 931 4.1. PeerConnection 933 4.1.1. Constructor 935 The PeerConnection constructor allows the application to specify 936 global parameters for the media session, such as the STUN/TURN 937 servers and credentials to use when gathering candidates, as well as 938 the initial ICE candidate policy and pool size, and also the bundle 939 policy to use. 941 If an ICE candidate policy is specified, it functions as described in 942 Section 3.5.3, causing the JSEP implementation to only surface the 943 permitted candidates (including any implementation-internal 944 filtering) to the application, and only use those candidates for 945 connectivity checks. The set of available policies is as follows: 947 all: All candidates permitted by implementation policy will be 948 gathered and used. 950 relay: All candidates except relay candidates will be filtered out. 951 This obfuscates the location information that might be ascertained 952 by the remote peer from the received candidates. Depending on how 953 the application deploys and chooses relay servers, this could 954 obfuscate location to a metro or possibly even global level. 956 The default ICE candidate policy MUST be set to "all" as this is 957 generally the desired policy, and also typically reduces use of 958 application TURN server resources significantly. 960 If a size is specified for the ICE candidate pool, this indicates the 961 number of ICE components to pre-gather candidates for. Because pre- 962 gathering results in utilizing STUN/TURN server resources for 963 potentially long periods of time, this must only occur upon 964 application request, and therefore the default candidate pool size 965 MUST be zero. 967 The application can specify its preferred policy regarding use of 968 bundle, the multiplexing mechanism defined in 969 [I-D.ietf-mmusic-sdp-bundle-negotiation]. Regardless of policy, the 970 application will always try to negotiate bundle onto a single 971 transport, and will offer a single bundle group across all m= 972 sections; use of this single transport is contingent upon the 973 answerer accepting bundle. However, by specifying a policy from the 974 list below, the application can control exactly how aggressively it 975 will try to bundle media streams together, which affects how it will 976 interoperate with a non-bundle-aware endpoint. When negotiating with 977 a non-bundle-aware endpoint, only the streams not marked as bundle- 978 only streams will be established. 980 The set of available policies is as follows: 982 balanced: The first m= section of each type (audio, video, or 983 application) will contain transport parameters, which will allow 984 an answerer to unbundle that section. The second and any 985 subsequent m= section of each type will be marked bundle-only. 986 The result is that if there are N distinct media types, then 987 candidates will be gathered for for N media streams. This policy 988 balances desire to multiplex with the need to ensure basic audio 989 and video can still be negotiated in legacy cases. When acting as 990 answerer, if there is no bundle group in the offer, the 991 implementation will reject all but the first m= section of each 992 type. 994 max-compat: All m= sections will contain transport parameters; none 995 will be marked as bundle-only. This policy will allow all streams 996 to be received by non-bundle-aware endpoints, but require separate 997 candidates to be gathered for each media stream. 999 max-bundle: Only the first m= section will contain transport 1000 parameters; all streams other than the first will be marked as 1001 bundle-only. This policy aims to minimize candidate gathering and 1002 maximize multiplexing, at the cost of less compatibility with 1003 legacy endpoints. When acting as answerer, the implementation 1004 will reject any m= sections other than the first m= section, 1005 unless they are in the same bundle group as that m= section. 1007 As it provides the best tradeoff between performance and 1008 compatibility with legacy endpoints, the default bundle policy MUST 1009 be set to "balanced". 1011 The application can specify its preferred policy regarding use of 1012 RTP/RTCP multiplexing [RFC5761] using one of the following policies: 1014 negotiate: The JSEP implementation will gather both RTP and RTCP 1015 candidates but also will offer "a=rtcp-mux", thus allowing for 1016 compatibility with either multiplexing or non-multiplexing 1017 endpoints. 1019 require: The JSEP implementation will only gather RTP candidates and 1020 will insert an "a=rtcp-mux-only" indication into any new m= 1021 sections in offers it generates. This halves the number of 1022 candidates that the offerer needs to gather. Applying a 1023 description with an m= section that does not contain an "a=rtcp- 1024 mux" attribute will cause an error to be returned. 1026 The default multiplexing policy MUST be set to "require". 1027 Implementations MAY choose to reject attempts by the application to 1028 set the multiplexing policy to "negotiate". 1030 4.1.2. addTrack 1032 The addTrack method adds a MediaStreamTrack to the PeerConnection, 1033 using the MediaStream argument to associate the track with other 1034 tracks in the same MediaStream, so that they can be added to the same 1035 "LS" group when creating an offer or answer. addTrack attempts to 1036 minimize the number of transceivers as follows: If the PeerConnection 1037 is in the "have-remote-offer" state, the track will be attached to 1038 the first compatible transceiver that was created by the most recent 1039 call to setRemoteDescription() and does not have a local track. 1040 Otherwise, a new transceiver will be created, as described in 1041 Section 4.1.4. 1043 4.1.3. removeTrack 1045 The removeTrack method removes a MediaStreamTrack from the 1046 PeerConnection, using the RtpSender argument to indicate which sender 1047 should have its track removed. The sender's track is cleared, and 1048 the sender stops sending. Future calls to createOffer will mark the 1049 m= section associated with the sender as recvonly (if 1050 transceiver.currentDirection is sendrecv) or as inactive (if 1051 transceiver.currentDirection is sendonly). 1053 4.1.4. addTransceiver 1055 The addTransceiver method adds a new RtpTransceiver to the 1056 PeerConnection. If a MediaStreamTrack argument is provided, then the 1057 transceiver will be configured with that media type and the track 1058 will be attached to the transceiver. Otherwise, the application MUST 1059 explicitly specify the type; this mode is useful for creating 1060 recvonly transceivers as well as for creating transceivers to which a 1061 track can be attached at some later point. 1063 At the time of creation, the application can also specify a 1064 transceiver direction attribute, a set of MediaStreams which the 1065 transceiver is associated with (allowing LS group assignments), and a 1066 set of encodings for the media (used for simulcast as described in 1067 Section 3.7). 1069 4.1.5. createDataChannel 1071 The createDataChannel method creates a new data channel and attaches 1072 it to the PeerConnection. If no data channel currently exists for 1073 this PeerConnection, then a new offer/answer exchange is required. 1074 All data channels on a given PeerConnection share the same SCTP/DTLS 1075 association and therefore the same m= section, so subsequent creation 1076 of data channels does not have any impact on the JSEP state. 1078 The createDataChannel method also includes a number of arguments 1079 which are used by the PeerConnection (e.g., maxPacketLifetime) but 1080 are not reflected in the SDP and do not affect the JSEP state. 1082 4.1.6. createOffer 1084 The createOffer method generates a blob of SDP that contains a 1085 [RFC3264] offer with the supported configurations for the session, 1086 including descriptions of the media added to this PeerConnection, the 1087 codec/RTP/RTCP options supported by this implementation, and any 1088 candidates that have been gathered by the ICE agent. An options 1089 parameter may be supplied to provide additional control over the 1090 generated offer. This options parameter allows an application to 1091 trigger an ICE restart, for the purpose of reestablishing 1092 connectivity. 1094 In the initial offer, the generated SDP will contain all desired 1095 functionality for the session (functionality that is supported but 1096 not desired by default may be omitted); for each SDP line, the 1097 generation of the SDP will follow the process defined for generating 1098 an initial offer from the document that specifies the given SDP line. 1099 The exact handling of initial offer generation is detailed in 1100 Section 5.2.1 below. 1102 In the event createOffer is called after the session is established, 1103 createOffer will generate an offer to modify the current session 1104 based on any changes that have been made to the session, e.g., adding 1105 or stopping RtpTransceivers, or requesting an ICE restart. For each 1106 existing stream, the generation of each SDP line must follow the 1107 process defined for generating an updated offer from the RFC that 1108 specifies the given SDP line. For each new stream, the generation of 1109 the SDP must follow the process of generating an initial offer, as 1110 mentioned above. If no changes have been made, or for SDP lines that 1111 are unaffected by the requested changes, the offer will only contain 1112 the parameters negotiated by the last offer-answer exchange. The 1113 exact handling of subsequent offer generation is detailed in 1114 Section 5.2.2. below. 1116 Session descriptions generated by createOffer must be immediately 1117 usable by setLocalDescription; if a system has limited resources 1118 (e.g. a finite number of decoders), createOffer should return an 1119 offer that reflects the current state of the system, so that 1120 setLocalDescription will succeed when it attempts to acquire those 1121 resources. 1123 Calling this method may do things such as generating new ICE 1124 credentials, but does not result in candidate gathering, or cause 1125 media to start or stop flowing. Specifically, the offer is not 1126 applied, and does not become the pending local description, until 1127 setLocalDescription is called. 1129 4.1.7. createAnswer 1131 The createAnswer method generates a blob of SDP that contains a 1132 [RFC3264] SDP answer with the supported configuration for the session 1133 that is compatible with the parameters supplied in the most recent 1134 call to setRemoteDescription, which MUST have been called prior to 1135 calling createAnswer. Like createOffer, the returned blob contains 1136 descriptions of the media added to this PeerConnection, the 1137 codec/RTP/RTCP options negotiated for this session, and any 1138 candidates that have been gathered by the ICE agent. An options 1139 parameter may be supplied to provide additional control over the 1140 generated answer. 1142 As an answer, the generated SDP will contain a specific configuration 1143 that specifies how the media plane should be established; for each 1144 SDP line, the generation of the SDP must follow the process defined 1145 for generating an answer from the document that specifies the given 1146 SDP line. The exact handling of answer generation is detailed in 1147 Section 5.3. below. 1149 Session descriptions generated by createAnswer must be immediately 1150 usable by setLocalDescription; like createOffer, the returned 1151 description should reflect the current state of the system. 1153 Calling this method may do things such as generating new ICE 1154 credentials, but does not trigger candidate gathering or cause a 1155 media state change. Specifically, the answer is not applied, and 1156 does not become the pending local description, until 1157 setLocalDescription is called. 1159 4.1.8. SessionDescriptionType 1161 Session description objects (RTCSessionDescription) may be of type 1162 "offer", "pranswer", "answer" or "rollback". These types provide 1163 information as to how the description parameter should be parsed, and 1164 how the media state should be changed. 1166 "offer" indicates that a description should be parsed as an offer; 1167 said description may include many possible media configurations. A 1168 description used as an "offer" may be applied anytime the 1169 PeerConnection is in a stable state, or as an update to a previously 1170 supplied but unanswered "offer". 1172 "pranswer" indicates that a description should be parsed as an 1173 answer, but not a final answer, and so should not result in the 1174 freeing of allocated resources. It may result in the start of media 1175 transmission, if the answer does not specify an inactive media 1176 direction. A description used as a "pranswer" may be applied as a 1177 response to an "offer", or an update to a previously sent "pranswer". 1179 "answer" indicates that a description should be parsed as an answer, 1180 the offer-answer exchange should be considered complete, and any 1181 resources (decoders, candidates) that are no longer needed can be 1182 released. A description used as an "answer" may be applied as a 1183 response to an "offer", or an update to a previously sent "pranswer". 1185 The only difference between a provisional and final answer is that 1186 the final answer results in the freeing of any unused resources that 1187 were allocated as a result of the offer. As such, the application 1188 can use some discretion on whether an answer should be applied as 1189 provisional or final, and can change the type of the session 1190 description as needed. For example, in a serial forking scenario, an 1191 application may receive multiple "final" answers, one from each 1192 remote endpoint. The application could choose to accept the initial 1193 answers as provisional answers, and only apply an answer as final 1194 when it receives one that meets its criteria (e.g. a live user 1195 instead of voicemail). 1197 "rollback" is a special session description type implying that the 1198 state machine should be rolled back to the previous stable state, as 1199 described in Section 4.1.8.2. The contents MUST be empty. 1201 4.1.8.1. Use of Provisional Answers 1203 Most applications will not need to create answers using the 1204 "pranswer" type. While it is good practice to send an immediate 1205 response to an offer, in order to warm up the session transport and 1206 prevent media clipping, the preferred handling for a JSEP application 1207 is to create and send a "sendonly" final answer with a null 1208 MediaStreamTrack immediately after receiving the offer, which will 1209 prevent media from being sent by the caller, and allow media to be 1210 sent immediately upon answer by the callee. Later, when the callee 1211 actually accepts the call, the application can plug in the real 1212 MediaStreamTrack and create a new "sendrecv" offer to update the 1213 previous offer/answer pair and start bidirectional media flow. While 1214 this could also be done with a "sendonly" pranswer, followed by a 1215 "sendrecv" answer, the initial pranswer leaves the offer-answer 1216 exchange open, which means that the caller cannot send an updated 1217 offer during this time. 1219 As an example, consider a typical JSEP application that wants to set 1220 up audio and video as quickly as possible. When the callee receives 1221 an offer with audio and video MediaStreamTracks, it will send an 1222 immediate answer accepting these tracks as sendonly (meaning that the 1223 caller will not send the callee any media yet, and because the callee 1224 has not yet added its own MediaStreamTracks, the callee will not send 1225 any media either). It will then ask the user to accept the call and 1226 acquire the needed local tracks. Upon acceptance by the user, the 1227 application will plug in the tracks it has acquired, which, because 1228 ICE and DTLS handshaking have likely completed by this point, can 1229 start transmitting immediately. The application will also send a new 1230 offer to the remote side indicating call acceptance and moving the 1231 audio and video to be two-way media. A detailed example flow along 1232 these lines is shown in Section 7.3. 1234 Of course, some applications may not be able to perform this double 1235 offer-answer exchange, particularly ones that are attempting to 1236 gateway to legacy signaling protocols. In these cases, pranswer can 1237 still provide the application with a mechanism to warm up the 1238 transport. 1240 4.1.8.2. Rollback 1242 In certain situations it may be desirable to "undo" a change made to 1243 setLocalDescription or setRemoteDescription. Consider a case where a 1244 call is ongoing, and one side wants to change some of the session 1245 parameters; that side generates an updated offer and then calls 1246 setLocalDescription. However, the remote side, either before or 1247 after setRemoteDescription, decides it does not want to accept the 1248 new parameters, and sends a reject message back to the offerer. Now, 1249 the offerer, and possibly the answerer as well, need to return to a 1250 stable state and the previous local/remote description. To support 1251 this, we introduce the concept of "rollback". 1253 A rollback discards any proposed changes to the session, returning 1254 the state machine to the stable state, and setting the pending local 1255 and/or remote description (see Section 4.1.12 and Section 4.1.14) to 1256 null. Any resources or candidates that were allocated by the 1257 abandoned local description are discarded; any media that is received 1258 will be processed according to the previous local and remote 1259 descriptions. Rollback can only be used to cancel proposed changes; 1260 there is no support for rolling back from a stable state to a 1261 previous stable state. Note that this implies that once the answerer 1262 has performed setLocalDescription with his answer, this cannot be 1263 rolled back. 1265 A rollback will disassociate any RtpTransceivers that were associated 1266 with m= sections by the application of the rolled-back session 1267 description (see Section 5.9 and Section 5.8). This means that some 1268 RtpTransceivers that were previously associated will no longer be 1269 associated with any m= section; in such cases, the value of the 1270 RtpTransceiver's mid property MUST be set to null, and the mapping 1271 between the transceiver and its m= section index MUST be discarded. 1272 RtpTransceivers that were created by applying a remote offer that was 1273 subsequently rolled back MUST be stopped and removed from the 1274 PeerConnection. However, a RtpTransceiver MUST NOT be removed if a 1275 track was attached to the RtpTransceiver via the addTrack method. 1276 This is so that an application may call addTrack, then call 1277 setRemoteDescription with an offer, then roll back that offer, then 1278 call createOffer and have a m= section for the added track appear in 1279 the generated offer. 1281 A rollback is performed by supplying a session description of type 1282 "rollback" with empty contents to either setLocalDescription or 1283 setRemoteDescription, depending on which was most recently used (i.e. 1284 if the new offer was supplied to setLocalDescription, the rollback 1285 should be done using setLocalDescription as well). 1287 4.1.9. setLocalDescription 1289 The setLocalDescription method instructs the PeerConnection to apply 1290 the supplied session description as its local configuration. The 1291 type field indicates whether the description should be processed as 1292 an offer, provisional answer, or final answer; offers and answers are 1293 checked differently, using the various rules that exist for each SDP 1294 line. 1296 This API changes the local media state; among other things, it sets 1297 up local resources for receiving and decoding media. In order to 1298 successfully handle scenarios where the application wants to offer to 1299 change from one media format to a different, incompatible format, the 1300 PeerConnection must be able to simultaneously support use of both the 1301 current and pending local descriptions (e.g., support the codecs that 1302 exist in either description). This dual processing begins when the 1303 PeerConnection enters the have-local-offer state, and continues until 1304 setRemoteDescription is called with either a final answer, at which 1305 point the PeerConnection can fully adopt the pending local 1306 description, or a rollback, which results in a revert to the current 1307 local description. 1309 This API indirectly controls the candidate gathering process. When a 1310 local description is supplied, and the number of transports currently 1311 in use does not match the number of transports needed by the local 1312 description, the PeerConnection will create transports as needed and 1313 begin gathering candidates for each transport, using ones from the 1314 candidate pool if available. 1316 If setRemoteDescription was previously called with an offer, and 1317 setLocalDescription is called with an answer (provisional or final), 1318 and the media directions are compatible, and media is available to 1319 send, this will result in the starting of media transmission. 1321 4.1.10. setRemoteDescription 1323 The setRemoteDescription method instructs the PeerConnection to apply 1324 the supplied session description as the desired remote configuration. 1325 As in setLocalDescription, the type field of the description 1326 indicates how it should be processed. 1328 This API changes the local media state; among other things, it sets 1329 up local resources for sending and encoding media. 1331 If setLocalDescription was previously called with an offer, and 1332 setRemoteDescription is called with an answer (provisional or final), 1333 and the media directions are compatible, and media is available to 1334 send, this will result in the starting of media transmission. 1336 4.1.11. currentLocalDescription 1338 The currentLocalDescription method returns the current negotiated 1339 local description - i.e., the local description from the last 1340 successful offer/answer exchange - in addition to any local 1341 candidates that have been generated by the ICE agent since the local 1342 description was set. 1344 A null object will be returned if an offer/answer exchange has not 1345 yet been completed. 1347 4.1.12. pendingLocalDescription 1349 The pendingLocalDescription method returns a copy of the local 1350 description currently in negotiation - i.e., a local offer set 1351 without any corresponding remote answer - in addition to any local 1352 candidates that have been generated by the ICE agent since the local 1353 description was set. 1355 A null object will be returned if the state of the PeerConnection is 1356 "stable" or "have-remote-offer". 1358 4.1.13. currentRemoteDescription 1360 The currentRemoteDescription method returns a copy of the current 1361 negotiated remote description - i.e., the remote description from the 1362 last successful offer/answer exchange - in addition to any remote 1363 candidates that have been supplied via processIceMessage since the 1364 remote description was set. 1366 A null object will be returned if an offer/answer exchange has not 1367 yet been completed. 1369 4.1.14. pendingRemoteDescription 1371 The pendingRemoteDescription method returns a copy of the remote 1372 description currently in negotiation - i.e., a remote offer set 1373 without any corresponding local answer - in addition to any remote 1374 candidates that have been supplied via processIceMessage since the 1375 remote description was set. 1377 A null object will be returned if the state of the PeerConnection is 1378 "stable" or "have-local-offer". 1380 4.1.15. canTrickleIceCandidates 1382 The canTrickleIceCandidates property indicates whether the remote 1383 side supports receiving trickled candidates. There are three 1384 potential values: 1386 null: No SDP has been received from the other side, so it is not 1387 known if it can handle trickle. This is the initial value before 1388 setRemoteDescription() is called. 1390 true: SDP has been received from the other side indicating that it 1391 can support trickle. 1393 false: SDP has been received from the other side indicating that it 1394 cannot support trickle. 1396 As described in Section 3.5.2, JSEP implementations always provide 1397 candidates to the application individually, consistent with what is 1398 needed for Trickle ICE. However, applications can use the 1399 canTrickleIceCandidates property to determine whether their peer can 1400 actually do Trickle ICE, i.e., whether it is safe to send an initial 1401 offer or answer followed later by candidates as they are gathered. 1402 As "true" is the only value that definitively indicates remote 1403 Trickle ICE support, an application which compares 1404 canTrickleIceCandidates against "true" will by default attempt Half 1405 Trickle on initial offers and Full Trickle on subsequent interactions 1406 with a Trickle ICE-compatible agent. 1408 4.1.16. setConfiguration 1410 The setConfiguration method allows the global configuration of the 1411 PeerConnection, which was initially set by constructor parameters, to 1412 be changed during the session. The effects of this method call 1413 depend on when it is invoked, and differ depending on which specific 1414 parameters are changed: 1416 o Any changes to the STUN/TURN servers to use affect the next 1417 gathering phase. If an ICE gathering phase has already started or 1418 completed, the 'needs-ice-restart' bit mentioned in Section 3.5.1 1419 will be set. This will cause the next call to createOffer to 1420 generate new ICE credentials, for the purpose of forcing an ICE 1421 restart and kicking off a new gathering phase, in which the new 1422 servers will be used. If the ICE candidate pool has a nonzero 1423 size, and a local description has not yet been applied, any 1424 existing candidates will be discarded, and new candidates will be 1425 gathered from the new servers. 1427 o Any change to the ICE candidate policy affects the next gathering 1428 phase. If an ICE gathering phase has already started or 1429 completed, the 'needs-ice-restart' bit will be set. Either way, 1430 changes to the policy have no effect on the candidate pool, 1431 because pooled candidates are not surfaced to the application 1432 until a gathering phase occurs, and so any necessary filtering can 1433 still be done on any pooled candidates. 1435 o The ICE candidate pool size MUST NOT be changed after applying a 1436 local description. If a local description has not yet been 1437 applied, any changes to the ICE candidate pool size take effect 1438 immediately; if increased, additional candidates are pre-gathered; 1439 if decreased, the now-superfluous candidates are discarded. 1441 o The bundle and RTCP-multiplexing policies MUST NOT be changed 1442 after the construction of the PeerConnection. 1444 This call may result in a change to the state of the ICE Agent. 1446 4.1.17. addIceCandidate 1448 The addIceCandidate method provides a remote candidate to the ICE 1449 agent, which, if parsed successfully, will be added to the current 1450 and/or pending remote description according to the rules defined for 1451 Trickle ICE. The pair of MID and ufrag is used to determine the m= 1452 section and ICE candidate generation to which the candidate belongs. 1453 If the MID is not present, the m= section index is used to look up 1454 the locally generated MID (see Section 5.9), which is used in place 1455 of a supplied MID. If these values or the candidate string are 1456 invalid, an error is generated. 1458 The purpose of the ufrag is to resolve ambiguities when trickle ICE 1459 is in progress during an ICE restart. If the ufrag is absent, the 1460 candidate MUST be assumed to belong to the most recently applied 1461 remote description. Connectivity checks will be sent to the new 1462 candidate. 1464 This method can also be used to provide an end-of-candidates 1465 indication to the ICE agent, as defined in [I-D.ietf-ice-trickle]). 1466 The MID and ufrag are used as described above to determine the m= 1467 section and ICE generation for which candidate gathering is complete. 1468 If the ufrag is not present, then the end-of-candidates indication 1469 MUST be assumed to apply to the relevant m= section in the most 1470 recently applied remote description. If neither the MID nor the m= 1471 index is present, then the indication MUST be assumed to apply to all 1472 m= sections in the most recently applied remote description. 1474 This call will result in a change to the state of the ICE Agent, and 1475 may result in a change to media state if it results in connectivity 1476 being established. 1478 4.2. RtpTransceiver 1480 4.2.1. stop 1482 The stop method stops an RtpTransceiver. This will cause future 1483 calls to createOffer to generate a zero port for the associated m= 1484 section. See below for more details. 1486 4.2.2. stopped 1488 The stopped property indicates whether the transceiver has been 1489 stopped, either by a call to stopTransceiver or by applying an answer 1490 that rejects the associated m= section. In either of these cases, it 1491 is set to "true", and otherwise will be set to "false". 1493 A stopped RtpTransceiver does not send any outgoing RTP or RTCP or 1494 process any incoming RTP or RTCP. It cannot be restarted. 1496 4.2.3. setDirection 1498 The setDirection method sets the direction of a transceiver, which 1499 affects the direction property of the associated m= section on future 1500 calls to createOffer and createAnswer. 1502 When creating offers, the transceiver direction is directly reflected 1503 in the output, even for reoffers. When creating answers, the 1504 transceiver direction is intersected with the offered direction, as 1505 explained in the Section 5.3 section below. 1507 Note that while setDirection sets the direction property of the 1508 transceiver immediately (Section 4.2.4), this property does not 1509 immediately affect whether the transceiver's RtpSender will send or 1510 its RtpReceiver will receive. The direction in effect is represented 1511 by the currentDirection property, which is only updated when an 1512 answer is applied. 1514 4.2.4. direction 1516 The direction property indicates the last value passed into 1517 setDirection. If setDirection has never been called, it is set to 1518 the direction the transceiver was initialized with. 1520 4.2.5. currentDirection 1522 The currentDirection property indicates the last negotiated direction 1523 for the transceiver's associated m= section. More specifically, it 1524 indicates the [RFC3264] directional attribute of the associated m= 1525 section in the last applied answer, with "send" and "recv" directions 1526 reversed if it was a remote answer. For example, if the directional 1527 attribute for the associated m= section in a remote answer is 1528 "recvonly", currentDirection is set to "sendonly". 1530 If an answer that references this transceiver has not yet been 1531 applied, or if the transceiver is stopped, currentDirection is set to 1532 null. 1534 4.2.6. setCodecPreferences 1536 The setCodecPreferences method sets the codec preferences of a 1537 transceiver, which in turn affect the presence and order of codecs of 1538 the associated m= section on future calls to createOffer and 1539 createAnswer. Note that setCodecPreferences does not directly affect 1540 which codec the implementation decides to send. It only affects 1541 which codecs the implementation indicates that it prefers to receive, 1542 via the offer or answer. Even when a codec is excluded by 1543 setCodecPreferences, it still may be used to send until the next 1544 offer/answer exchange discards it. 1546 The codec preferences of an RtpTransceiver can cause codecs to be 1547 excluded by subsequent calls to createOffer and createAnswer, in 1548 which case the corresponding media formats in the associated m= 1549 section will be excluded. The codec preferences cannot add media 1550 formats that would otherwise not be present. This includes codecs 1551 that were not negotiated in a previous offer/answer exchange that 1552 included the transceiver. 1554 The codec preferences of an RtpTransceiver can also determine the 1555 order of codecs in subsequent calls to createOffer and createAnswer, 1556 in which case the order of the media formats in the associated m= 1557 section will follow the specified preferences. 1559 5. SDP Interaction Procedures 1561 This section describes the specific procedures to be followed when 1562 creating and parsing SDP objects. 1564 5.1. Requirements Overview 1566 JSEP implementations must comply with the specifications listed below 1567 that govern the creation and processing of offers and answers. 1569 5.1.1. Usage Requirements 1571 All session descriptions handled by JSEP implementations, both local 1572 and remote, MUST indicate support for the following specifications. 1573 If any of these are absent, this omission MUST be treated as an 1574 error. 1576 o ICE, as specified in [RFC5245], MUST be used. Note that the 1577 remote endpoint may use a Lite implementation; implementations 1578 MUST properly handle remote endpoints which do ICE-Lite. 1580 o DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as 1581 appropriate for the media type, as specified in 1582 [I-D.ietf-rtcweb-security-arch] 1584 The SDES SRTP keying mechanism from [RFC4568] MUST NOT be used, as 1585 discussed in [I-D.ietf-rtcweb-security-arch]. 1587 5.1.2. Profile Names and Interoperability 1589 For media m= sections, JSEP implementations MUST support the 1590 "UDP/TLS/RTP/SAVPF" profile specified in [RFC7850], and MUST indicate 1591 this profile for each media m= line they produce in an offer. For 1592 data m= sections, implementations MUST support the "UDP/DTLS/SCTP" 1593 profile and MUST indicate this profile for each data m= line they 1594 produce in an offer. Because ICE can select either UDP [RFC5245] or 1595 TCP [RFC6544] transport depending on network conditions, this 1596 advertisement is consistent with ICE eventually selecting either 1597 either UDP or TCP. 1599 Unfortunately, in an attempt at compatibility, some endpoints 1600 generate other profile strings even when they mean to support one of 1601 these profiles. For instance, an endpoint might generate "RTP/AVP" 1602 but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its 1603 willingness to support "(UDP,TCP)/TLS/RTP/SAVPF". In order to 1604 simplify compatibility with such endpoints, JSEP implementations MUST 1605 follow the following rules when processing the media m= sections in 1606 an offer: 1608 o The profile in any "m=" line in any answer MUST exactly match the 1609 profile provided in the offer. 1611 o Any profile matching the following patterns MUST be accepted: 1612 "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" 1614 o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no 1615 effect; support for DTLS-SRTP is determined by the presence of one 1616 or more "a=fingerprint" attribute. Note that lack of an 1617 "a=fingerprint" attribute will lead to negotiation failure. 1619 o The use of AVPF or AVP simply controls the timing rules used for 1620 RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute 1621 is present, assume AVPF timing, i.e., a default value of "trr- 1622 int=0". Otherwise, assume that AVPF is being used in an AVP 1623 compatible mode and use a value of "trr-int=4000". 1625 o For data m= sections, implementations MUST support receiving the 1626 "UDP/DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards 1627 compatibility) profiles. 1629 Note that re-offers by JSEP implementations MUST use the correct 1630 profile strings even if the initial offer/answer exchange used an 1631 (incorrect) older profile string. 1633 5.2. Constructing an Offer 1635 When createOffer is called, a new SDP description must be created 1636 that includes the functionality specified in 1637 [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are 1638 explained below. 1640 5.2.1. Initial Offers 1642 When createOffer is called for the first time, the result is known as 1643 the initial offer. 1645 The first step in generating an initial offer is to generate session- 1646 level attributes, as specified in [RFC4566], Section 5. 1647 Specifically: 1649 o The first SDP line MUST be "v=0", as specified in [RFC4566], 1650 Section 5.1 1652 o The second SDP line MUST be an "o=" line, as specified in 1653 [RFC4566], Section 5.2. The value of the field SHOULD 1654 be "-". [RFC3264] requires that the be representable as 1655 a 64-bit signed integer. It is RECOMMENDED that the be 1656 generated as a 64-bit quantity with the high bit being sent to 1657 zero and the remaining 63 bits being cryptographically random. 1658 The value of the tuple 1659 SHOULD be set to a non-meaningful address, such as IN IP4 0.0.0.0, 1660 to prevent leaking the local address in this field. As mentioned 1661 in [RFC4566], the entire o= line needs to be unique, but selecting 1662 a random number for is sufficient to accomplish this. 1664 o The third SDP line MUST be a "s=" line, as specified in [RFC4566], 1665 Section 5.3; to match the "o=" line, a single dash SHOULD be used 1666 as the session name, e.g. "s=-". Note that this differs from the 1667 advice in [RFC4566] which proposes a single space, but as both 1668 "o=" and "s=" are meaningless, having the same meaningless value 1669 seems clearer. 1671 o Session Information ("i="), URI ("u="), Email Address ("e="), 1672 Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") 1673 lines are not useful in this context and SHOULD NOT be included. 1675 o Encryption Keys ("k=") lines do not provide sufficient security 1676 and MUST NOT be included. 1678 o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; 1679 both and SHOULD be set to zero, e.g. "t=0 1680 0". 1682 o An "a=ice-options" line with the "trickle" option MUST be added, 1683 as specified in [I-D.ietf-ice-trickle], Section 4. 1685 o If WebRTC identity is being used, an "a=identity" line as 1686 described in [I-D.ietf-rtcweb-security-arch], Section 5. 1688 The next step is to generate m= sections, as specified in [RFC4566] 1689 Section 5.14. An m= section is generated for each RtpTransceiver 1690 that has been added to the PeerConnection, excluding any stopped 1691 RtpTransceivers. This is done in the order the RtpTransceivers were 1692 added to the PeerConnection. 1694 For each m= section generated for an RtpTransceiver, establish a 1695 mapping between the transceiver and the index of the generated m= 1696 section. 1698 Each m= section, provided it is not marked as bundle-only, MUST 1699 generate a unique set of ICE credentials and gather its own unique 1700 set of ICE candidates. Bundle-only m= sections MUST NOT contain any 1701 ICE credentials and MUST NOT gather any candidates. 1703 For DTLS, all m= sections MUST use all the certificate(s) that have 1704 been specified for the PeerConnection; as a result, they MUST all 1705 have the same [I-D.ietf-mmusic-4572-update] fingerprint value(s), or 1706 these value(s) MUST be session-level attributes. 1708 Each m= section should be generated as specified in [RFC4566], 1709 Section 5.14. For the m= line itself, the following rules MUST be 1710 followed: 1712 o The port value is set to the port of the default ICE candidate for 1713 this m= section, but given that no candidates are available yet, 1714 the "dummy" port value of 9 (Discard) MUST be used, as indicated 1715 in [I-D.ietf-ice-trickle], Section 5.1. 1717 o To properly indicate use of DTLS, the field MUST be set to 1718 "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. 1720 o If codec preferences have been set for the associated transceiver, 1721 media formats MUST be generated in the corresponding order, and 1722 MUST exclude any codecs not present in the codec preferences. 1724 o The media formats in the answer MAY include codecs present in the 1725 offer that were discarded in a previous offer/answer exchange. 1726 This is necessary for compatibility with third- party call control 1727 and SIP use cases. 1729 o Unless excluded by the above restrictions, the media formats MUST 1730 include the mandatory audio/video codecs as specified in 1731 [I-D.ietf-rtcweb-audio](see Section 3) and 1732 [I-D.ietf-rtcweb-video](see Section 5). 1734 The m= line MUST be followed immediately by a "c=" line, as specified 1735 in [RFC4566], Section 5.7. Again, as no candidates are available 1736 yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", 1737 as defined in [I-D.ietf-ice-trickle], Section 5.1. 1739 [I-D.ietf-mmusic-sdp-mux-attributes] groups SDP attributes into 1740 different categories. To avoid unnecessary duplication when 1741 bundling, Section 8.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation] 1742 specifies that attributes of category IDENTICAL or TRANSPORT should 1743 not be repeated in bundled m= sections. 1745 The following attributes, which are of a category other than 1746 IDENTICAL or TRANSPORT, MUST be included in each m= section: 1748 o An "a=mid" line, as specified in [RFC5888], Section 4. All MID 1749 values MUST be generated in a fashion that does not leak user 1750 information, e.g., randomly or using a per-PeerConnection counter, 1751 and SHOULD be 3 bytes or less, to allow them to efficiently fit 1752 into the RTP header extension defined in 1753 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14. Note that 1754 this does not set the RtpTransceiver mid property, as that only 1755 occurs when the description is applied. The generated MID value 1756 can be considered a "proposed" MID at this point. 1758 o A direction attribute which is the same as that of the associated 1759 transceiver. 1761 o For each media format on the m= line, "a=rtpmap" and "a=fmtp" 1762 lines, as specified in [RFC4566], Section 6, and [RFC3264], 1763 Section 5.1. 1765 o For each primary codec where RTP retransmission should be used, a 1766 corresponding "a=rtpmap" line indicating "rtx" with the clock rate 1767 of the primary codec and an "a=fmtp" line that references the 1768 payload type of the primary codec, as specified in [RFC4588], 1769 Section 8.1. 1771 o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, 1772 as specified in [RFC4566], Section 6. The FEC mechanisms that 1773 MUST be supported are specified in [I-D.ietf-rtcweb-fec], 1774 Section 6, and specific usage for each media type is outlined in 1775 Sections 4 and 5. 1777 o If this m= section is for media with configurable durations of 1778 media per packet, e.g., audio, an "a=maxptime" line, indicating 1779 the maximum amount of media, specified in milliseconds, that can 1780 be encapsulated in each packet, as specified in [RFC4566], 1781 Section 6. This value is set to the smallest of the maximum 1782 duration values across all the codecs included in the m= section. 1784 o If this m= section is for video media, and there are known 1785 limitations on the size of images which can be decoded, an 1786 "a=imageattr" line, as specified in Section 3.6. 1788 o For each supported RTP header extension, an "a=extmap" line, as 1789 specified in [RFC5285], Section 5. The list of header extensions 1790 that SHOULD/MUST be supported is specified in 1791 [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions 1792 that require encryption MUST be specified as indicated in 1793 [RFC6904], Section 4. 1795 o For each supported RTCP feedback mechanism, an "a=rtcp-fb" 1796 mechanism, as specified in [RFC4585], Section 4.2. The list of 1797 RTCP feedback mechanisms that SHOULD/MUST be supported is 1798 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. 1800 o If the RtpTransceiver has a sendrecv or sendonly direction: 1802 * For each MediaStream that was associated with the transceiver 1803 when it was created via addTrack or addTransceiver, an "a=msid" 1804 line, as specified in [I-D.ietf-mmusic-msid], Section 2. If a 1805 MediaStreamTrack is attached to the transceiver's RtpSender, 1806 the "a=msid" lines MUST use that track's ID. If no 1807 MediaStreamTrack is attached, a valid ID MUST be generated, in 1808 the same way that the implementation generates IDs for local 1809 tracks. 1811 * If no MediaStream is associated with the transceiver, a single 1812 "a=msid" line with the special value "-" in place of the 1813 MediaStream ID, as specified in [I-D.ietf-mmusic-msid], 1814 Section 3. The track ID MUST be selected as described above. 1816 o If the RtpTransceiver has a sendrecv or sendonly direction, and 1817 the application has specified RID values or has specified more 1818 than one encoding in the RtpSenders's parameters, an "a=rid" line 1819 for each encoding specified. The "a=rid" line is specified in 1820 [I-D.ietf-mmusic-rid], and its direction MUST be "send". If the 1821 application has chosen a RID value, it MUST be used as the rid- 1822 identifier; otherwise a RID value MUST be generated by the 1823 implementation. RID values MUST be generated in a fashion that 1824 does not leak user information, e.g., randomly or using a per- 1825 PeerConnection counter, and SHOULD be 3 bytes or less, to allow 1826 them to efficiently fit into the RTP header extension defined in 1827 [I-D.ietf-avtext-rid], Section 3. If no encodings have been 1828 specified, or only one encoding is specified but without a RID 1829 value, then no "a=rid" lines are generated. 1831 o If the RtpTransceiver has a sendrecv or sendonly direction and 1832 more than one "a=rid" line has been generated, an "a=simulcast" 1833 line, with direction "send", as defined in 1834 [I-D.ietf-mmusic-sdp-simulcast], Section 6.2. The list of RIDs 1835 MUST include all of the RID identifiers used in the "a=rid" lines 1836 for this m= section. 1838 o If the bundle policy for this PeerConnection is set to "max- 1839 bundle", and this is not the first m= section, or the bundle 1840 policy is set to "balanced", and this is not the first m= section 1841 for this media type, an "a=bundle-only" line. 1843 The following attributes, which are of category IDENTICAL or 1844 TRANSPORT, MUST appear only in "m=" sections which either have a 1845 unique address or which are associated with the bundle-tag. (In 1846 initial offers, this means those "m=" sections which do not contain 1847 an "a=bundle-only" attribute.) 1848 o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245], 1849 Section 15.4. 1851 o An "a=fingerprint" line for each of the endpoint's certificates, 1852 as specified in [RFC4572], Section 5; the digest algorithm used 1853 for the fingerprint MUST match that used in the certificate 1854 signature. 1856 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1857 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1858 The role value in the offer MUST be "actpass". 1860 o An "a=dtls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp] 1861 Section 5.2. 1863 o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, 1864 containing the dummy value "9 IN IP4 0.0.0.0", because no 1865 candidates have yet been gathered. 1867 o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.3. 1869 o If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- 1870 only" line, as specified in [I-D.ietf-mmusic-mux-exclusive], 1871 Section 4. 1873 o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. 1875 Lastly, if a data channel has been created, a m= section MUST be 1876 generated for data. The field MUST be set to "application" 1877 and the field MUST be set to "UDP/DTLS/SCTP" 1878 [I-D.ietf-mmusic-sctp-sdp]. The "fmt" value MUST be set to "webrtc- 1879 datachannel" as specified in [I-D.ietf-mmusic-sctp-sdp], Section 4.1. 1881 Within the data m= section, an "a=mid" line MUST be generated and 1882 included as described above, along with an "a=sctp-port" line 1883 referencing the SCTP port number, as defined in 1884 [I-D.ietf-mmusic-sctp-sdp], Section 5.1, and, if appropriate, an 1885 "a=max-message-size" line, as defined in [I-D.ietf-mmusic-sctp-sdp], 1886 Section 6.1. 1888 As discussed above, the following attributes of category IDENTICAL or 1889 TRANSPORT are included only if the data m= section either has a 1890 unique address or is associated with the bundle-tag (e.g., if it is 1891 the only m= section): 1893 o "a=ice-ufrag" 1895 o "a=ice-pwd" 1896 o "a=fingerprint" 1898 o "a=setup" 1900 o "a=dtls-id" 1902 Once all m= sections have been generated, a session-level "a=group" 1903 attribute MUST be added as specified in [RFC5888]. This attribute 1904 MUST have semantics "BUNDLE", and MUST include the mid identifiers of 1905 each m= section. The effect of this is that the JSEP implementation 1906 offers all m= sections as one bundle group. However, whether the m= 1907 sections are bundle-only or not depends on the bundle policy. 1909 The next step is to generate session-level lip sync groups as defined 1910 in [RFC5888], Section 7. For each MediaStream referenced by more 1911 than one RtpTransceiver (by passing those MediaStreams as arguments 1912 to the addTrack and addTransceiver methods), a group of type "LS" 1913 MUST be added that contains the mid values for each RtpTransceiver. 1915 Attributes which SDP permits to either be at the session level or the 1916 media level SHOULD generally be at the media level even if they are 1917 identical. This promotes readability, especially if one of a set of 1918 initially identical attributes is subsequently changed. 1920 Attributes other than the ones specified above MAY be included, 1921 except for the following attributes which are specifically 1922 incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], 1923 and MUST NOT be included: 1925 o "a=crypto" 1927 o "a=key-mgmt" 1929 o "a=ice-lite" 1931 Note that when bundle is used, any additional attributes that are 1932 added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] 1933 on how those attributes interact with bundle. 1935 Note that these requirements are in some cases stricter than those of 1936 SDP. Implementations MUST be prepared to accept compliant SDP even 1937 if it would not conform to the requirements for generating SDP in 1938 this specification. 1940 5.2.2. Subsequent Offers 1942 When createOffer is called a second (or later) time, or is called 1943 after a local description has already been installed, the processing 1944 is somewhat different than for an initial offer. 1946 If the initial offer was not applied using setLocalDescription, 1947 meaning the PeerConnection is still in the "stable" state, the steps 1948 for generating an initial offer should be followed, subject to the 1949 following restriction: 1951 o The fields of the "o=" line MUST stay the same except for the 1952 field, which MUST increment by one on each call 1953 to createOffer if the offer might differ from the output of the 1954 previous call to createOffer; implementations MAY opt to increment 1955 on every call. The value of the generated 1956 is independent of the of the 1957 current local description; in particular, in the case where the 1958 current version is N, an offer is created and applied with version 1959 N+1, and then that offer is rolled back so that the current 1960 version is again N, the next generated offer will still have 1961 version N+2. 1963 Note that if the application creates an offer by reading 1964 currentLocalDescription instead of calling createOffer, the returned 1965 SDP may be different than when setLocalDescription was originally 1966 called, due to the addition of gathered ICE candidates, but the 1967 will not have changed. There are no known 1968 scenarios in which this causes problems, but if this is a concern, 1969 the solution is simply to use createOffer to ensure a unique 1970 . 1972 If the initial offer was applied using setLocalDescription, but an 1973 answer from the remote side has not yet been applied, meaning the 1974 PeerConnection is still in the "local-offer" state, an offer is 1975 generated by following the steps in the "stable" state above, along 1976 with these exceptions: 1978 o The "s=" and "t=" lines MUST stay the same. 1980 o If any RtpTransceiver has been added, and there exists an m= 1981 section with a zero port in the current local description or the 1982 current remote description, that m= section MUST be recycled by 1983 generating an m= section for the added RtpTransceiver as if the m= 1984 section were being added to the session description, placed at the 1985 same index as the m= section with a zero port. 1987 o If an RtpTransceiver is stopped and is not associated with an m= 1988 section, an m= section MUST NOT be generated for it. This 1989 prevents adding back RtpTransceivers whose m= sections were 1990 recycled and used for a new RtpTransceiver in a previous offer/ 1991 answer exchange, as described above. 1993 o If an RtpTransceiver has been stopped and is associated with an m= 1994 section, and the m= section is not being recycled as described 1995 above, an m= section MUST be generated for it with the port set to 1996 zero and all "a=msid" lines removed. 1998 o For RtpTransceivers that are not stopped, the "a=msid" line(s) 1999 MUST stay the same if they are present in the current description, 2000 regardless of changes to the transceiver's direction or track. If 2001 no "a=msid" line is present in the current description, "a=msid" 2002 line(s) MUST be generated according to the same rules as for an 2003 initial offer. 2005 o Each "m=" and c=" line MUST be filled in with the port, protocol, 2006 and address of the default candidate for the m= section, as 2007 described in [RFC5245], Section 4.3. If ICE checking has already 2008 completed for one or more candidate pairs and a candidate pair is 2009 in active use, then that pair MUST be used, even if ICE has not 2010 yet completed. Note that this differs from the guidance in 2011 [RFC5245], Section 9.1.2.2, which only refers to offers created 2012 when ICE has completed. In each case, if no RTP candidates have 2013 yet been gathered, dummy values MUST be used, as described above. 2015 o Each "a=mid" line MUST stay the same. 2017 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless 2018 the ICE configuration has changed (either changes to the supported 2019 STUN/TURN servers, or the ICE candidate policy), or the 2020 "IceRestart" option ( Section 5.2.3.1 was specified. If the m= 2021 section is bundled into another m= section, it still MUST NOT 2022 contain any ICE credentials. 2024 o If the m= section is not bundled into another m= section, its 2025 "a=rtcp" attribute line MUST be filled in with the port and 2026 address of the default RTCP candidate, as indicated in [RFC5761], 2027 Section 5.1.3. If no RTCP candidates have yet been gathered, 2028 dummy values MUST be used, as described in the initial offer 2029 section above. 2031 o If the m= section is not bundled into another m= section, for each 2032 candidate that has been gathered during the most recent gathering 2033 phase (see Section 3.5.1), an "a=candidate" line MUST be added, as 2034 defined in [RFC5245], Section 4.3., paragraph 3. If candidate 2035 gathering for the section has completed, an "a=end-of-candidates" 2036 attribute MUST be added, as described in [I-D.ietf-ice-trickle], 2037 Section 9.3. If the m= section is bundled into another m= 2038 section, both "a=candidate" and "a=end-of-candidates" MUST be 2039 omitted. 2041 o For RtpTransceivers that are still present, the "a=rid" lines MUST 2042 stay the same. 2044 o For RtpTransceivers that are still present, any "a=simulcast" line 2045 MUST stay the same. 2047 o If any RtpTransceiver has been stopped, the port MUST be set to 2048 zero and all "a=msid" lines MUST be removed. 2050 o If any RtpTransceiver has been added, and there exists a m= 2051 section with a zero port in the current local description or the 2052 current remote description, that m= section MUST be recycled by 2053 generating a m= section for the added RtpTransceiver as if the m= 2054 section were being added to session description, except that 2055 instead of adding it, the generated m= section replaces the m= 2056 section with a zero port. The new m= section MUST contain a new 2057 MID. 2059 If the initial offer was applied using setLocalDescription, and an 2060 answer from the remote side has been applied using 2061 setRemoteDescription, meaning the PeerConnection is in the "remote- 2062 pranswer" or "stable" states, an offer is generated based on the 2063 negotiated session descriptions by following the steps mentioned for 2064 the "local-offer" state above. 2066 In addition, for each non-recycled, non-rejected m= section in the 2067 new offer, the following adjustments are made based on the contents 2068 of the corresponding m= section in the current remote description, if 2069 any: 2071 o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST 2072 only include codecs present in the most recent answer which have 2073 not been excluded by the codec preferences of the associated 2074 transceiver. Note that non-JSEP endpoints are not subject to 2075 these restrictions, and might offer media formats that were not 2076 present in the most recent answer, as specified in [RFC3264], 2077 Section 8. Therefore, JSEP implementations MUST be prepared to 2078 receive such offers. 2080 o Unless codec preferences have been set for the associated 2081 transceiver, the media formats on the m= line MUST be generated in 2082 the same order as in the current local description. 2084 o The RTP header extensions MUST only include those that are present 2085 in the most recent answer. 2087 o The RTCP feedback extensions MUST only include those that are 2088 present in the most recent answer. 2090 o The "a=rtcp" line MUST only be added if the most recent answer did 2091 not include an "a=rtcp-mux" line. 2093 o The "a=rtcp-mux" line MUST only be added if present in the most 2094 recent answer. 2096 o The "a=rtcp-mux-only" line MUST NOT be added. 2098 o The "a=rtcp-rsize" line MUST only be added if present in the most 2099 recent answer. 2101 o An "a=bundle-only" line MUST NOT be added, as indicated in 2102 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 6. Instead, 2103 JSEP implementations MUST simply omit parameters in the IDENTICAL 2104 and TRANSPORT categories for bundled m= sections, as described in 2105 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. 2107 o Note that if media m= sections are bundled into a data m= section, 2108 then certain TRANSPORT and IDENTICAL attributes may appear in the 2109 data m= section even if they would otherwise only be appropriate 2110 for a media m= section (e.g., "a=rtcp-mux"). This cannot happen 2111 in initial offers because in the initial offer JSEP 2112 implementations always list media m= sections (if any) before the 2113 data m= section (if any), and at least one of those media m= 2114 sections will not have the "a=bundle-only" attribute. Therefore, 2115 in initial offers, any "a=bundle-only" m= sections will be bundled 2116 into a preceding non-bundle-only media m= section. 2118 The "a=group:BUNDLE" attribute MUST include the MID identifiers 2119 specified in the bundle group in the most recent answer, minus any m= 2120 sections that have been marked as rejected, plus any newly added or 2121 re-enabled m= sections. In other words, the bundle attribute must 2122 contain all m= sections that were previously bundled, as long as they 2123 are still alive, as well as any new m= sections. 2125 "a=group:LS" attributes are generated in the same way as for initial 2126 offers, with the additional stipulation that any lip sync groups that 2127 were present in the most recent answer MUST continue to exist and 2128 MUST contain any previously existing MID identifiers, as long as the 2129 identified m= sections still exist and are not rejected, and the 2130 group still contains at least two MID identifiers. This ensures that 2131 any synchronized "recvonly" m= sections continue to be synchronized 2132 in the new offer. 2134 5.2.3. Options Handling 2136 The createOffer method takes as a parameter an RTCOfferOptions 2137 object. Special processing is performed when generating a SDP 2138 description if the following options are present. 2140 5.2.3.1. IceRestart 2142 If the "IceRestart" option is specified, with a value of "true", the 2143 offer MUST indicate an ICE restart by generating new ICE ufrag and 2144 pwd attributes, as specified in [RFC5245], Section 9.1.1.1. If this 2145 option is specified on an initial offer, it has no effect (since a 2146 new ICE ufrag and pwd are already generated). Similarly, if the ICE 2147 configuration has changed, this option has no effect, since new ufrag 2148 and pwd attributes will be generated automatically. This option is 2149 primarily useful for reestablishing connectivity in cases where 2150 failures are detected by the application. 2152 5.2.3.2. VoiceActivityDetection 2154 If the "VoiceActivityDetection" option is specified, with a value of 2155 "true", the offer MUST indicate support for silence suppression in 2156 the audio it receives by including comfort noise ("CN") codecs for 2157 each offered audio codec, as specified in [RFC3389], Section 5.1, 2158 except for codecs that have their own internal silence suppression 2159 support. For codecs that have their own internal silence suppression 2160 support, the appropriate fmtp parameters for that codec MUST be 2161 specified to indicate that silence suppression for received audio is 2162 desired. For example, when using the Opus codec [RFC6716], the 2163 "usedtx=1" parameter, specified in [RFC7587], would be used in the 2164 offer. This option allows the endpoint to significantly reduce the 2165 amount of audio bandwidth it receives, at the cost of some fidelity, 2166 depending on the quality of the remote VAD algorithm. 2168 If the "VoiceActivityDetection" option is specified, with a value of 2169 "false", the JSEP implementation MUST NOT emit "CN" codecs. For 2170 codecs that have their own internal silence suppression support, the 2171 appropriate fmtp parameters for that codec MUST be specified to 2172 indicate that silence suppression for received audio is not desired. 2173 For example, when using the Opus codec, the "usedtx=0" parameter 2174 would be specified in the offer. 2176 Note that setting the "VoiceActivityDetection" parameter when 2177 generating an offer is a request to receive audio with silence 2178 suppression. It has no impact on whether the local endpoint does 2179 silence suppression for the audio it sends. 2181 The "VoiceActivityDetection" option does not have any impact on the 2182 setting of the "vad" value in the signaling of the client to mixer 2183 audio level header extension described in [RFC6464], Section 4. 2185 5.3. Generating an Answer 2187 When createAnswer is called, a new SDP description must be created 2188 that is compatible with the supplied remote description as well as 2189 the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact 2190 details of this process are explained below. 2192 5.3.1. Initial Answers 2194 When createAnswer is called for the first time after a remote 2195 description has been provided, the result is known as the initial 2196 answer. If no remote description has been installed, an answer 2197 cannot be generated, and an error MUST be returned. 2199 Note that the remote description SDP may not have been created by a 2200 JSEP endpoint and may not conform to all the requirements listed in 2201 Section 5.2. For many cases, this is not a problem. However, if any 2202 mandatory SDP attributes are missing, or functionality listed as 2203 mandatory-to-use above is not present, this MUST be treated as an 2204 error, and MUST cause the affected m= sections to be marked as 2205 rejected. 2207 The first step in generating an initial answer is to generate 2208 session-level attributes. The process here is identical to that 2209 indicated in the initial offers section above, except that the 2210 "a=ice-options" line, with the "trickle" option as specified in 2211 [I-D.ietf-ice-trickle], Section 4, is only included if such an option 2212 was present in the offer. 2214 The next step is to generate session-level lip sync groups, as 2215 defined in [RFC5888], Section 7. For each group of type "LS" present 2216 in the offer, select the local RtpTransceivers that are referenced by 2217 the MID values in the specified group, and determine which of them 2218 either reference a common local MediaStream (specified in the calls 2219 to addTrack/addTransceiver used to create them), or have no 2220 MediaStream to reference because they were not created by addTrack/ 2221 addTransceiver. If at least two such RtpTransceivers exist, a group 2222 of type "LS" with the mid values of these RtpTransceivers MUST be 2223 added. Otherwise the offered "LS" group MUST be ignored and no 2224 corresponding group generated in the answer. 2226 As a simple example, consider the following offer of a single audio 2227 and single video track contained in the same MediaStream. SDP lines 2228 not relevant to this example have been removed for clarity. As 2229 explained in Section 5.2, a group of type "LS" has been added that 2230 references each track's RtpTransceiver. 2232 a=group:LS a1 v1 2233 m=audio 10000 UDP/TLS/RTP/SAVPF 0 2234 a=mid:a1 2235 a=msid:ms1 mst1a 2236 m=video 10001 UDP/TLS/RTP/SAVPF 96 2237 a=mid:v1 2238 a=msid:ms1 mst1v 2240 If the answerer uses a single MediaStream when it adds its tracks, 2241 both of its transceivers will reference this stream, and so the 2242 subsequent answer will contain a "LS" group identical to that in the 2243 offer, as shown below: 2245 a=group:LS a1 v1 2246 m=audio 20000 UDP/TLS/RTP/SAVPF 0 2247 a=mid:a1 2248 a=msid:ms2 mst2a 2249 m=video 20001 UDP/TLS/RTP/SAVPF 96 2250 a=mid:v1 2251 a=msid:ms2 mst2v 2253 However, if the answerer groups its tracks into separate 2254 MediaStreams, its transceivers will reference different streams, and 2255 so the subsequent answer will not contain a "LS" group. 2257 m=audio 20000 UDP/TLS/RTP/SAVPF 0 2258 a=mid:a1 2259 a=msid:ms2a mst2a 2260 m=video 20001 UDP/TLS/RTP/SAVPF 96 2261 a=mid:v1 2262 a=msid:ms2b mst2v 2264 Finally, if the answerer does not add any tracks, its transceivers 2265 will not reference any MediaStreams, causing the preferences of the 2266 offerer to be maintained, and so the subsequent answer will contain 2267 an identical "LS" group. 2269 a=group:LS a1 v1 2270 m=audio 20000 UDP/TLS/RTP/SAVPF 0 2271 a=mid:a1 2272 a=recvonly 2273 m=video 20001 UDP/TLS/RTP/SAVPF 96 2274 a=mid:v1 2275 a=recvonly 2277 The Section 7.2 example later in this document shows a more involved 2278 case of "LS" group generation. 2280 The next step is to generate m= sections for each m= section that is 2281 present in the remote offer, as specified in [RFC3264], Section 6. 2282 For the purposes of this discussion, any session-level attributes in 2283 the offer that are also valid as media-level attributes are 2284 considered to be present in each m= section. 2286 The next step is to go through each offered m= section. Each offered 2287 m= section will have an associated RtpTransceiver, as described in 2288 Section 5.9. If there are more RtpTransceivers than there are m= 2289 sections, the unmatched RtpTransceivers will need to be associated in 2290 a subsequent offer. 2292 For each offered m= section, if any of the following conditions are 2293 true, the corresponding m= section in the answer MUST be marked as 2294 rejected by setting the port in the m= line to zero, as indicated in 2295 [RFC3264], Section 6., and further processing for this m= section can 2296 be skipped: 2298 o The associated RtpTransceiver has been stopped. 2300 o No supported codec is present in the offer. 2302 o The bundle policy is "max-bundle", and this is not the first m= 2303 section or in the same bundle group as the first m= section. 2305 o The bundle policy is "balanced", and this is not the first m= 2306 section for this media type or in the same bundle group as the 2307 first m= section for this media type. 2309 Otherwise, each m= section in the answer should then be generated as 2310 specified in [RFC3264], Section 6.1. For the m= line itself, the 2311 following rules must be followed: 2313 o The port value would normally be set to the port of the default 2314 ICE candidate for this m= section, but given that no candidates 2315 are available yet, the "dummy" port value of 9 (Discard) MUST be 2316 used, as indicated in [I-D.ietf-ice-trickle], Section 5.1. 2318 o The field MUST be set to exactly match the field 2319 for the corresponding m= line in the offer. 2321 o If codec preferences have been set for the associated transceiver, 2322 media formats MUST be generated in the corresponding order, and 2323 MUST exclude any codecs not present in the codec preferences or 2324 not present in the offer. Note that non-JSEP endpoints are not 2325 subject to this restriction, and might add media formats in the 2326 answer that are not present in the offer, as specified in 2327 [RFC3264], Section 6.1. Therefore, JSEP implementations MUST be 2328 prepared to receive such answers. 2330 o Unless excluded by the above restrictions, the media formats MUST 2331 include the mandatory audio/video codecs as specified in 2332 [I-D.ietf-rtcweb-audio](see Section 3) and 2333 [I-D.ietf-rtcweb-video](see Section 5). 2335 The m= line MUST be followed immediately by a "c=" line, as specified 2336 in [RFC4566], Section 5.7. Again, as no candidates are available 2337 yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", 2338 as defined in [I-D.ietf-ice-trickle], Section 5.1. 2340 If the offer supports bundle, all m= sections to be bundled must use 2341 the same ICE credentials and candidates; all m= sections not being 2342 bundled must use unique ICE credentials and candidates. Each m= 2343 section MUST contain the following attributes (which are of attribute 2344 types other than IDENTICAL and TRANSPORT): 2346 o If and only if present in the offer, an "a=mid" line, as specified 2347 in [RFC5888], Section 9.1. The "mid" value MUST match that 2348 specified in the offer. 2350 o A direction attribute, determined by applying the rules regarding 2351 the offered direction specified in [RFC3264], Section 6.1, and 2352 then intersecting with the direction of the associated 2353 RtpTransceiver. For example, in the case where an m= section is 2354 offered as "sendonly", and the local transceiver is set to 2355 "sendrecv", the result in the answer is a "recvonly" direction. 2357 o For each media format on the m= line, "a=rtpmap" and "a=fmtp" 2358 lines, as specified in [RFC4566], Section 6, and [RFC3264], 2359 Section 6.1. 2361 o If "rtx" is present in the offer, for each primary codec where RTP 2362 retransmission should be used, a corresponding "a=rtpmap" line 2363 indicating "rtx" with the clock rate of the primary codec and an 2364 "a=fmtp" line that references the payload type of the primary 2365 codec, as specified in [RFC4588], Section 8.1. 2367 o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, 2368 as specified in [RFC4566], Section 6. The FEC mechanisms that 2369 MUST be supported are specified in [I-D.ietf-rtcweb-fec], 2370 Section 6, and specific usage for each media type is outlined in 2371 Sections 4 and 5. 2373 o If this m= section is for media with configurable durations of 2374 media per packet, e.g., audio, an "a=maxptime" line, as described 2375 in Section 5.2. 2377 o If this m= section is for video media, and there are known 2378 limitations on the size of images which can be decoded, an 2379 "a=imageattr" line, as specified in Section 3.6. 2381 o For each supported RTP header extension that is present in the 2382 offer, an "a=extmap" line, as specified in [RFC5285], Section 5. 2383 The list of header extensions that SHOULD/MUST be supported is 2384 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header 2385 extensions that require encryption MUST be specified as indicated 2386 in [RFC6904], Section 4. 2388 o For each supported RTCP feedback mechanism that is present in the 2389 offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], 2390 Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ 2391 MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], 2392 Section 5.1. 2394 o If the RtpTransceiver has a sendrecv or sendonly direction: 2396 * For each MediaStream that was associated with the transceiver 2397 when it was created via addTrack or addTransceiver, an "a=msid" 2398 line, as specified in [I-D.ietf-mmusic-msid], Section 2. If a 2399 MediaStreamTrack is attached to the transceiver's RtpSender, 2400 the "a=msid" lines MUST use that track's ID. If no 2401 MediaStreamTrack is attached, a valid ID MUST be generated, in 2402 the same way that the implementation generates IDs for local 2403 tracks. 2405 * If no MediaStream is associated with the transceiver, a single 2406 "a=msid" line with the special value "-" in place of the 2407 MediaStream ID, as specified in [I-D.ietf-mmusic-msid], 2408 Section 3. The track ID MUST be selected as described above. 2410 Each m= section which is not bundled into another m= section, MUST 2411 contain the following attributes (which are of category IDENTICAL or 2412 TRANSPORT): 2414 o "a=ice-ufrag" and "a=ice-pwd" lines, as specified in [RFC5245], 2415 Section 15.4. 2417 o An "a=fingerprint" line for each of the endpoint's certificates, 2418 as specified in [RFC4572], Section 5; the digest algorithm used 2419 for the fingerprint MUST match that used in the certificate 2420 signature. 2422 o An "a=setup" line, as specified in [RFC4145], Section 4, and 2423 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 2424 The role value in the answer MUST be "active" or "passive"; the 2425 "active" role is RECOMMENDED. 2427 o An "a=dtls-id" line, as specified in [I-D.ietf-mmusic-dtls-sdp] 2428 Section 5.3. 2430 o If present in the offer, an "a=rtcp-mux" line, as specified in 2431 [RFC5761], Section 5.1.3. Otherwise, an "a=rtcp" line, as 2432 specified in [RFC3605], Section 2.1, containing the dummy value "9 2433 IN IP4 0.0.0.0" (because no candidates have yet been gathered). 2435 o If present in the offer, an "a=rtcp-rsize" line, as specified in 2436 [RFC5506], Section 5. 2438 If a data channel m= section has been offered, a m= section MUST also 2439 be generated for data. The field MUST be set to 2440 "application" and the and fields MUST be set to exactly 2441 match the fields in the offer. 2443 Within the data m= section, an "a=mid" line MUST be generated and 2444 included as described above, along with an "a=sctp-port" line 2445 referencing the SCTP port number, as defined in 2446 [I-D.ietf-mmusic-sctp-sdp], Section 5.1, and, if appropriate, an 2447 "a=max-message-size" line, as defined in [I-D.ietf-mmusic-sctp-sdp], 2448 Section 6.1. 2450 As discussed above, the following attributes of category IDENTICAL or 2451 TRANSPORT are included only if the data m= section is not bundled 2452 into another m= section: 2454 o "a=ice-ufrag" 2456 o "a=ice-pwd" 2457 o "a=fingerprint" 2459 o "a=setup" 2461 o "a=dtls-id" 2463 Note that if media m= sections are bundled into a data m= section, 2464 then certain TRANSPORT and IDENTICAL attributes may also appear in 2465 the data m= section even if they would otherwise only be appropriate 2466 for a media m= section (e.g., "a=rtcp-mux"). 2468 If "a=group" attributes with semantics of "BUNDLE" are offered, 2469 corresponding session-level "a=group" attributes MUST be added as 2470 specified in [RFC5888]. These attributes MUST have semantics 2471 "BUNDLE", and MUST include the all mid identifiers from the offered 2472 bundle groups that have not been rejected. Note that regardless of 2473 the presence of "a=bundle-only" in the offer, no m= sections in the 2474 answer should have an "a=bundle-only" line. 2476 Attributes that are common between all m= sections MAY be moved to 2477 session-level, if explicitly defined to be valid at session-level. 2479 The attributes prohibited in the creation of offers are also 2480 prohibited in the creation of answers. 2482 5.3.2. Subsequent Answers 2484 When createAnswer is called a second (or later) time, or is called 2485 after a local description has already been installed, the processing 2486 is somewhat different than for an initial answer. 2488 If the initial answer was not applied using setLocalDescription, 2489 meaning the PeerConnection is still in the "have-remote-offer" state, 2490 the steps for generating an initial answer should be followed, 2491 subject to the following restriction: 2493 o The fields of the "o=" line MUST stay the same except for the 2494 field, which MUST increment if the session 2495 description changes in any way from the previously generated 2496 answer. 2498 If any session description was previously supplied to 2499 setLocalDescription, an answer is generated by following the steps in 2500 the "have-remote-offer" state above, along with these exceptions: 2502 o The "s=" and "t=" lines MUST stay the same. 2504 o Each "m=" and c=" line MUST be filled in with the port and address 2505 of the default candidate for the m= section, as described in 2506 [RFC5245], Section 4.3. Note, however, that the m= line protocol 2507 need not match the default candidate, because this protocol value 2508 must instead match what was supplied in the offer, as described 2509 above. 2511 o Unless codec preferences have been set for the associated 2512 transceiver, the media formats on the m= line MUST be generated in 2513 the same order as in the current local description. 2515 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless 2516 the m= section is restarting, in which case new ICE credentials 2517 must be created as specified in [RFC5245], Section 9.2.1.1. If 2518 the m= section is bundled into another m= section, it still MUST 2519 NOT contain any ICE credentials. 2521 o Each "a=setup" line MUST use an "active" or "passive" role value 2522 consistent with the existing DTLS association, if the association 2523 is being continued by the offerer. 2525 o If the m= section is not bundled into another m= section and RTCP 2526 multiplexing is not active, an "a=rtcp" attribute line MUST be 2527 filled in with the port and address of the default RTCP candidate. 2528 If no RTCP candidates have yet been gathered, dummy values MUST be 2529 used, as described in the initial answer section above. 2531 o If the m= section is not bundled into another m= section, for each 2532 candidate that has been gathered during the most recent gathering 2533 phase (see Section 3.5.1), an "a=candidate" line MUST be added, as 2534 defined in [RFC5245], Section 4.3., paragraph 3. If candidate 2535 gathering for the section has completed, an "a=end-of-candidates" 2536 attribute MUST be added, as described in [I-D.ietf-ice-trickle], 2537 Section 9.3. If the m= section is bundled into another m= 2538 section, both "a=candidate" and "a=end-of-candidates" MUST be 2539 omitted. 2541 o For RtpTransceivers that are not stopped, the "a=msid" line(s) 2542 MUST stay the same, regardless of changes to the transceiver's 2543 direction or track. If no "a=msid" line is present in the current 2544 description, "a=msid" line(s) MUST be generated according to the 2545 same rules as for an initial answer. 2547 5.3.3. Options Handling 2549 The createAnswer method takes as a parameter an RTCAnswerOptions 2550 object. The set of parameters for RTCAnswerOptions is different than 2551 those supported in RTCOfferOptions; the IceRestart option is 2552 unnecessary, as ICE credentials will automatically be changed for all 2553 m= sections where the offerer chose to perform ICE restart. 2555 The following options are supported in RTCAnswerOptions. 2557 5.3.3.1. VoiceActivityDetection 2559 Silence suppression in the answer is handled as described in 2560 Section 5.2.3.2, with one exception: if support for silence 2561 suppression was not indicated in the offer, the 2562 VoiceActivityDetection parameter has no effect, and the answer should 2563 be generated as if VoiceActivityDetection was set to false. This is 2564 done on a per-codec basis (e.g., if the offerer somehow offered 2565 support for CN but set "usedtx=0" for Opus, setting 2566 VoiceActivityDetection to true would result in an answer with CN 2567 codecs and "usedtx=0"). 2569 5.4. Modifying an Offer or Answer 2571 The SDP returned from createOffer or createAnswer MUST NOT be changed 2572 before passing it to setLocalDescription. If precise control over 2573 the SDP is needed, the aforementioned createOffer/createAnswer 2574 options or RtpTransceiver APIs MUST be used. 2576 Note that the application MAY modify the SDP to reduce the 2577 capabilities in the offer it sends to the far side (post- 2578 setLocalDescription) or the offer that it installs from the far side 2579 (pre-setRemoteDescription), as long as it remains a valid SDP offer 2580 and specifies a subset of what was in the original offer. This is 2581 safe because the answer is not permitted to expand capabilities, and 2582 therefore will just respond to what is present in the offer. 2584 The application SHOULD NOT modify the SDP in the answer it transmits, 2585 as the answer contains the negotiated capabilities, and this can 2586 cause the two sides to have different ideas about what exactly was 2587 negotiated. 2589 As always, the application is solely responsible for what it sends to 2590 the other party, and all incoming SDP will be processed by the JSEP 2591 implementation to the extent of its capabilities. It is an error to 2592 assume that all SDP is well-formed; however, one should be able to 2593 assume that any implementation of this specification will be able to 2594 process, as a remote offer or answer, unmodified SDP coming from any 2595 other implementation of this specification. 2597 5.5. Processing a Local Description 2599 When a SessionDescription is supplied to setLocalDescription, the 2600 following steps MUST be performed: 2602 o First, the type of the SessionDescription is checked against the 2603 current state of the PeerConnection: 2605 * If the type is "offer", the PeerConnection state MUST be either 2606 "stable" or "have-local-offer". 2608 * If the type is "pranswer" or "answer", the PeerConnection state 2609 MUST be either "have-remote-offer" or "have-local-pranswer". 2611 o If the type is not correct for the current state, processing MUST 2612 stop and an error MUST be returned. 2614 o The SessionDescription is then checked to ensure that its contents 2615 are identical to those generated in the last call to createOffer/ 2616 createAnswer, and thus have not been altered, as discussed in 2617 Section 5.4; otherwise, processing MUST stop and an error MUST be 2618 returned. 2620 o Next, the SessionDescription is parsed into a data structure, as 2621 described in the Section 5.7 section below. If parsing fails for 2622 any reason, processing MUST stop and an error MUST be returned. 2624 o Finally, the parsed SessionDescription is applied as described in 2625 the Section 5.8 section below. 2627 5.6. Processing a Remote Description 2629 When a SessionDescription is supplied to setRemoteDescription, the 2630 following steps MUST be performed: 2632 o First, the type of the SessionDescription is checked against the 2633 current state of the PeerConnection: 2635 * If the type is "offer", the PeerConnection state MUST be either 2636 "stable" or "have-remote-offer". 2638 * If the type is "pranswer" or "answer", the PeerConnection state 2639 MUST be either "have-local-offer" or "have-remote-pranswer". 2641 o If the type is not correct for the current state, processing MUST 2642 stop and an error MUST be returned. 2644 o Next, the SessionDescription is parsed into a data structure, as 2645 described in the Section 5.7 section below. If parsing fails for 2646 any reason, processing MUST stop and an error MUST be returned. 2648 o Finally, the parsed SessionDescription is applied as described in 2649 the Section 5.9 section below. 2651 5.7. Parsing a Session Description 2653 When a SessionDescription of any type is supplied to setLocal/ 2654 RemoteDescription, the implementation must parse it and reject it if 2655 it is invalid. The exact details of this process are explained 2656 below. 2658 The SDP contained in the session description object consists of a 2659 sequence of text lines, each containing a key-value expression, as 2660 described in [RFC4566], Section 5. The SDP is read, line-by-line, 2661 and converted to a data structure that contains the deserialized 2662 information. However, SDP allows many types of lines, not all of 2663 which are relevant to JSEP applications. For each line, the 2664 implementation will first ensure it is syntactically correct 2665 according to its defining ABNF, check that it conforms to [RFC4566] 2666 and [RFC3264] semantics, and then either parse and store or discard 2667 the provided value, as described below. 2669 If any line is not well-formed, or cannot be parsed as described, the 2670 parser MUST stop with an error and reject the session description, 2671 even if the value is to be discarded. This ensures that 2672 implementations do not accidentally misinterpret ambiguous SDP. 2674 5.7.1. Session-Level Parsing 2676 First, the session-level lines are checked and parsed. These lines 2677 MUST occur in a specific order, and with a specific syntax, as 2678 defined in [RFC4566], Section 5. Note that while the specific line 2679 types (e.g. "v=", "c=") MUST occur in the defined order, lines of the 2680 same type (typically "a=") can occur in any order, and their ordering 2681 is not meaningful. 2683 The following non-attribute lines are not meaningful in the JSEP 2684 context and MAY be discarded once they have been checked. 2686 The "c=" line MUST be checked for syntax but its value is not 2687 used. This supersedes the guidance in [RFC5245], Section 6.1, to 2688 use "ice-mismatch" to indicate mismatches between "c=" and the 2689 candidate lines; because JSEP always uses ICE, "ice-mismatch" is 2690 not useful in this context. 2692 The "i=", "u=", "e=", "p=", "t=", "r=", "z=", and "k=" lines are 2693 not used by this specification; they MUST be checked for syntax 2694 but their values are not used. 2696 The remaining non-attribute lines are processed as follows: 2698 The "v=" line MUST have a version of 0, as specified in [RFC4566], 2699 Section 5.1. 2701 The "o=" line MUST be parsed as specified in [RFC4566], 2702 Section 5.2. 2704 The "b=" line, if present, MUST be parsed as specified in 2705 [RFC4566], Section 5.8, and the bwtype and bandwidth values 2706 stored. 2708 Finally, the attribute lines are processed. Specific processing MUST 2709 be applied for the following session-level attribute ("a=") lines: 2711 o Any "a=group" lines are parsed as specified in [RFC5888], 2712 Section 5, and the group's semantics and mids are stored. 2714 o If present, a single "a=ice-lite" line is parsed as specified in 2715 [RFC5245], Section 15.3, and a value indicating the presence of 2716 ice-lite is stored. 2718 o If present, a single "a=ice-ufrag" line is parsed as specified in 2719 [RFC5245], Section 15.4, and the ufrag value is stored. 2721 o If present, a single "a=ice-pwd" line is parsed as specified in 2722 [RFC5245], Section 15.4, and the password value is stored. 2724 o If present, a single "a=ice-options" line is parsed as specified 2725 in [RFC5245], Section 15.5, and the set of specified options is 2726 stored. 2728 o Any "a=fingerprint" lines are parsed as specified in [RFC4572], 2729 Section 5, and the set of fingerprint and algorithm values is 2730 stored. 2732 o If present, a single "a=setup" line is parsed as specified in 2733 [RFC4145], Section 4, and the setup value is stored. 2735 o If present, a single "a=dtls-id" line is parsed as specified in 2736 [I-D.ietf-mmusic-dtls-sdp] Section 5, and the dtls-id value is 2737 stored. 2739 o Any "a=identity" lines are parsed and the identity values stored 2740 for subsequent verification, as specified 2741 [I-D.ietf-rtcweb-security-arch], Section 5. 2743 o Any "a=extmap" lines are parsed as specified in [RFC5285], 2744 Section 5, and their values are stored. 2746 As required by [RFC4566], Section 5.13, unknown attribute lines MUST 2747 be ignored. 2749 Once all the session-level lines have been parsed, processing 2750 continues with the lines in m= sections. 2752 5.7.2. Media Section Parsing 2754 Like the session-level lines, the media section lines MUST occur in 2755 the specific order and with the specific syntax defined in [RFC4566], 2756 Section 5. 2758 The "m=" line itself MUST be parsed as described in [RFC4566], 2759 Section 5.14, and the media, port, proto, and fmt values stored. 2761 Following the "m=" line, specific processing MUST be applied for the 2762 following non-attribute lines: 2764 o As with the "c=" line at the session level, the "c=" line MUST be 2765 parsed according to [RFC4566], Section 5.7, but its value is not 2766 used. 2768 o The "b=" line, if present, MUST be parsed as specified in 2769 [RFC4566], Section 5.8, and the bwtype and bandwidth values 2770 stored. 2772 Specific processing MUST also be applied for the following attribute 2773 lines: 2775 o If present, a single "a=ice-ufrag" line is parsed as specified in 2776 [RFC5245], Section 15.4, and the ufrag value is stored. 2778 o If present, a single "a=ice-pwd" line is parsed as specified in 2779 [RFC5245], Section 15.4, and the password value is stored. 2781 o If present, a single "a=ice-options" line is parsed as specified 2782 in [RFC5245], Section 15.5, and the set of specified options is 2783 stored. 2785 o Any "a=candidate" attributes MUST be parsed as specified in 2786 [RFC5245], Section 15.1, and their values stored. 2788 o Any "a=remote-candidates" attributes MUST be parsed as specified 2789 in [RFC5245], Section 15.2, but their values are ignored. 2791 o If present, a single "a=end-of-candidates" attribute MUST be 2792 parsed as specified in [I-D.ietf-ice-trickle], Section 8.2, and 2793 its presence or absence flagged and stored. 2795 o Any "a=fingerprint" lines are parsed as specified in [RFC4572], 2796 Section 5, and the set of fingerprint and algorithm values is 2797 stored. 2799 If the "m=" proto value indicates use of RTP, as described in the 2800 Section 5.1.2 section above, the following attribute lines MUST be 2801 processed: 2803 o The "m=" fmt value MUST be parsed as specified in [RFC4566], 2804 Section 5.14, and the individual values stored. 2806 o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in 2807 [RFC4566], Section 6, and their values stored. 2809 o If present, a single "a=ptime" line MUST be parsed as described in 2810 [RFC4566], Section 6, and its value stored. 2812 o If present, a single "a=maxptime" line MUST be parsed as described 2813 in [RFC4566], Section 6, and its value stored. 2815 o If present, a single direction attribute line (e.g. "a=sendrecv") 2816 MUST be parsed as described in [RFC4566], Section 6, and its value 2817 stored. 2819 o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as 2820 specified in [RFC5576], Sections 4.1-4.2, and their values stored. 2822 o Any "a=extmap" attributes MUST be parsed as specified in 2823 [RFC5285], Section 5, and their values stored. 2825 o Any "a=rtcp-fb" attributes MUST be parsed as specified in 2826 [RFC4585], Section 4.2., and their values stored. 2828 o If present, a single "a=rtcp-mux" attribute MUST be parsed as 2829 specified in [RFC5761], Section 5.1.3, and its presence or absence 2830 flagged and stored. 2832 o If present, a single "a=rtcp-mux-only" attribute MUST be parsed as 2833 specified in [I-D.ietf-mmusic-mux-exclusive], Section 3, and its 2834 presence or absence flagged and stored. 2836 o If present, a single "a=rtcp-rsize" attribute MUST be parsed as 2837 specified in [RFC5506], Section 5, and its presence or absence 2838 flagged and stored. 2840 o If present, a single "a=rtcp" attribute MUST be parsed as 2841 specified in [RFC3605], Section 2.1, but its value is ignored, as 2842 this information is superfluous when using ICE. 2844 o If present, "a=msid" attributes MUST be parsed as specified in 2845 [I-D.ietf-mmusic-msid], Section 3.2, and their values stored. 2847 o Any "a=imageattr" attributes MUST be parsed as specified in 2848 [RFC6236], Section 3, and their values stored. 2850 o Any "a=rid" lines MUST be parsed as specified in 2851 [I-D.ietf-mmusic-rid], Section 10, and their values stored. 2853 o If present, a single "a=simulcast" line MUST be parsed as 2854 specified in [I-D.ietf-mmusic-sdp-simulcast], and its values 2855 stored. 2857 Otherwise, if the "m=" proto value indicates use of SCTP, the 2858 following attribute lines MUST be processed: 2860 o The "m=" fmt value MUST be parsed as specified in 2861 [I-D.ietf-mmusic-sctp-sdp], Section 4.3, and the application 2862 protocol value stored. 2864 o An "a=sctp-port" attribute MUST be present, and it MUST be parsed 2865 as specified in [I-D.ietf-mmusic-sctp-sdp], Section 5.2, and the 2866 value stored. 2868 o If present, a single "a=max-message-size" attribute MUST be parsed 2869 as specified in [I-D.ietf-mmusic-sctp-sdp], Section 6, and the 2870 value stored. Otherwise, use the specified default. 2872 As required by [RFC4566], Section 5.13, unknown attribute lines MUST 2873 be ignored. 2875 5.7.3. Semantics Verification 2877 Assuming parsing completes successfully, the parsed description is 2878 then evaluated to ensure internal consistency as well as proper 2879 support for mandatory features. Specifically, the following checks 2880 are performed: 2882 o For each m= section, valid values for each of the mandatory-to-use 2883 features enumerated in Section 5.1.1 MUST be present. These 2884 values MAY either be present at the media level, or inherited from 2885 the session level. 2887 * ICE ufrag and password values, which MUST comply with the size 2888 limits specified in [RFC5245], Section 15.4. 2890 * dtls-id value, which MUST be set according to 2891 [I-D.ietf-mmusic-dtls-sdp] Section 5. If this is a re-offer 2892 and the dtls-id value is different from that presently in use, 2893 the DTLS connection is not being continued and the remote 2894 description MUST be part of an ICE restart, together with new 2895 ufrag and password values. If this is an answer, the dtls-id 2896 value, if present, MUST be the same as in the offer. 2898 * DTLS setup value, which MUST be set according to the rules 2899 specified in [RFC5763], Section 5 and MUST be consistent with 2900 the selected role of the current DTLS connection, if one exists 2901 and is being continued. 2903 * DTLS fingerprint values, where at least one fingerprint MUST be 2904 present. 2906 o All RID values referenced in an "a=simulcast" line MUST exist as 2907 "a=rid" lines. 2909 o Each m= section is also checked to ensure prohibited features are 2910 not used. If this is a local description, the "ice-lite" 2911 attribute MUST NOT be specified. 2913 o If the RTP/RTCP multiplexing policy is "require", each m= section 2914 MUST contain an "a=rtcp-mux" attribute. If an "m=" section 2915 contains an "a=rtcp-mux-only" attribute then that section MUST 2916 also contain an "a=rtcp-mux" attribute. 2918 If this session description is of type "pranswer" or "answer", the 2919 following additional checks are applied: 2921 o The session description must follow the rules defined in 2922 [RFC3264], Section 6, including the requirement that the number of 2923 m= sections MUST exactly match the number of m= sections in the 2924 associated offer. 2926 o For each m= section, the media type and protocol values MUST 2927 exactly match the media type and protocol values in the 2928 corresponding m= section in the associated offer. 2930 If any of the preceding checks failed, processing MUST stop and an 2931 error MUST be returned. 2933 5.8. Applying a Local Description 2935 The following steps are performed at the media engine level to apply 2936 a local description. If an error is returned, the session MUST be 2937 restored to the state it was in before performing these steps. 2939 Next, m= sections are processed. For each m= section, the following 2940 steps MUST be performed; if any parameters are out of bounds, or 2941 cannot be applied, processing MUST stop and an error MUST be 2942 returned. 2944 o If this m= section is new, begin gathering candidates for it, as 2945 defined in [RFC5245], Section 4.1.1, unless it has been marked as 2946 bundle-only. 2948 o Or, if the ICE ufrag and password values have changed, and it has 2949 not been marked as bundle-only, trigger the ICE agent to start an 2950 ICE restart, and begin gathering new candidates for the m= section 2951 as described in [RFC5245], Section 9.1.1.1. If this description 2952 is an answer, also start checks on that media section as defined 2953 in [RFC5245], Section 9.3.1.1. 2955 o If the m= section proto value indicates use of RTP: 2957 * If there is no RtpTransceiver associated with this m= section 2958 (which will only happen when applying an offer), find one and 2959 associate it with this m= section according to the following 2960 steps: 2962 + Find the RtpTransceiver that corresponds to this m= section, 2963 using the mapping between transceivers and m= section 2964 indices established when creating the offer. 2966 + Set the value of this RtpTransceiver's mid property to the 2967 MID of the m= section. 2969 * If RTCP mux is indicated, prepare to demux RTP and RTCP from 2970 the RTP ICE component, as specified in [RFC5761], 2971 Section 5.1.3. If RTCP mux is not indicated, but was 2972 previously negotiated, i.e., the RTCP ICE component no longer 2973 exists, this MUST result in an error. 2975 * For each specified RTP header extension, establish a mapping 2976 between the extension ID and URI, as described in section 6 of 2977 [RFC5285]. If any indicated RTP header extension is not 2978 supported, this MUST result in an error. 2980 * If the MID header extension is supported, prepare to demux RTP 2981 streams intended for this m= section based on the MID header 2982 extension, as described in 2983 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14. 2985 * For each specified media format, establish a mapping between 2986 the payload type and the actual media format, as described in 2987 [RFC3264], Section 6.1. If any indicated media format is not 2988 supported, this MUST result in an error. 2990 * For each specified "rtx" media format, establish a mapping 2991 between the RTX payload type and its associated primary payload 2992 type, as described in [RFC4588], Sections 8.6 and 8.7. If any 2993 referenced primary payload types are not present, this MUST 2994 result in an error. 2996 * If the directional attribute is of type "sendrecv" or 2997 "recvonly", enable receipt and decoding of media. 2999 Finally, if this description is of type "pranswer" or "answer", 3000 follow the processing defined in the Section 5.10 section below. 3002 5.9. Applying a Remote Description 3004 The following steps are performed to apply a remote description. If 3005 an error is returned, the session MUST be restored to the state it 3006 was in before performing these steps. 3008 If the answer contains any "a=ice-options" attributes where "trickle" 3009 is listed as an attribute, update the PeerConnection canTrickle 3010 property to be true. Otherwise, set this property to false. 3012 The following steps MUST be performed for attributes at the session 3013 level; if any parameters are out of bounds, or cannot be applied, 3014 processing MUST stop and an error MUST be returned. 3016 o For any specified "CT" bandwidth value, set this as the limit for 3017 the maximum total bitrate for all m= sections, as specified in 3018 Section 5.8 of [RFC4566]. Within this overall limit, the 3019 implementation can dynamically decide how to best allocate the 3020 available bandwidth between m= sections, respecting any specific 3021 limits that have been specified for individual m= sections. 3023 o For any specified "RR" or "RS" bandwidth values, handle as 3024 specified in [RFC3556], Section 2. 3026 o Any "AS" bandwidth value MUST be ignored, as the meaning of this 3027 construct at the session level is not well defined. 3029 For each m= section, the following steps MUST be performed; if any 3030 parameters are out of bounds, or cannot be applied, processing MUST 3031 stop and an error MUST be returned. 3033 o If the PeerConnection state is "have-local-offer", and the ICE 3034 ufrag or password changed from the previous remote description, 3035 then an ICE restart is needed, as described in Section 9.1.1.1 of 3036 [RFC5245]. If the description is of type "offer", note that an 3037 ICE restart is needed. If the description is of type "answer" or 3038 "pranswer" and the current local description is also an ICE 3039 restart, then signal the ICE agent to begin checks as described in 3040 Section 9.3.1.1 of [RFC5245]. An answerer MUST change the ufrag 3041 and password in an answer if and only if ICE is restarting, as 3042 described in Section 9.2.1.1 of [RFC5245]. 3044 o If the PeerConnection state is "have-remote-pranswer", and the ICE 3045 ufrag or password changed from the previous provisional answer, 3046 then signal the ICE agent to discard any previous ICE check list 3047 state for the m= section and begin checks as if this were the 3048 first answer. However, such an answer MAY only change the ICE 3049 ufrag or password if the local offer is starting or restarting ICE 3050 for the m= section. 3052 o Configure the ICE components associated with this media section to 3053 use the supplied ICE remote ufrag and password for their 3054 connectivity checks. 3056 o Pair any supplied ICE candidates with any gathered local 3057 candidates, as described in Section 5.7 of [RFC5245] and start 3058 connectivity checks with the appropriate credentials. 3060 o If an "a=end-of-candidates" attribute is present, process the end- 3061 of-candidates indication as described in [I-D.ietf-ice-trickle] 3062 Section 11. 3064 o If the m= section proto value indicates use of RTP: 3066 * If the m= section is being recycled (see Section 5.2.2), 3067 dissociate the currently associated RtpTransceiver by setting 3068 its mid property to null, and discard the mapping between the 3069 transceiver and its m= section index. 3071 * If the m= section is not associated with any RtpTransceiver 3072 (possibly because it was dissociated in the previous step), 3073 either find an RtpTransceiver or create one according to the 3074 following steps: 3076 + If the m= section is sendrecv or recvonly, and there are 3077 RtpTransceivers of the same type that were added to the 3078 PeerConnection by addTrack and are not associated with any 3079 m= section and are not stopped, find the first (according to 3080 the canonical order described in Section 5.2.1) such 3081 RtpTransceiver. 3083 + If no RtpTransceiver was found in the previous step, create 3084 one with a recvonly direction. 3086 + Associate the found or created RtpTransceiver with the m= 3087 section by setting the value of the RtpTransceiver's mid 3088 property to the MID of the m= section, and establish a 3089 mapping between the transceiver and the index of the m= 3090 section. If the m= section does not include a MID (i.e., 3091 the remote endpoint does not support the MID extension), 3092 generate a value for the RtpTransceiver mid property, 3093 following the guidance for "a=mid" mentioned in 3094 Section 5.2.1. 3096 * For each specified media format that is also supported by the 3097 local implementation, establish a mapping between the specified 3098 payload type and the media format, as described in [RFC3264], 3099 Section 6.1. Specifically, this means that the implementation 3100 records the payload type to be used in outgoing RTP packets 3101 when sending each specified media format, as well as the 3102 relative preference for each format that is indicated in their 3103 ordering. If any indicated media format is not supported by 3104 the local implementation, it MUST be ignored. 3106 * For each specified "rtx" media format, establish a mapping 3107 between the RTX payload type and its associated primary payload 3108 type, as described in [RFC4588], Section 4. If any referenced 3109 primary payload types are not present, this MUST result in an 3110 error. 3112 * For each specified fmtp parameter that is supported by the 3113 local implementation, enable them on the associated media 3114 formats. 3116 * For each specified RTP header extension that is also supported 3117 by the local implementation, establish a mapping between the 3118 extension ID and URI, as described in [RFC5285], Section 5. 3119 Specifically, this means that the implementation records the 3120 extension ID to be used in outgoing RTP packets when sending 3121 each specified header extension. If any indicated RTP header 3122 extension is not supported by the local implementation, it MUST 3123 be ignored. 3125 * For each specified RTCP feedback mechanism that is supported by 3126 the local implementation, enable them on the associated media 3127 formats. 3129 * For any specified "TIAS" bandwidth value, set this value as a 3130 constraint on the maximum RTP bitrate to be used when sending 3131 media, as specified in [RFC3890]. If a "TIAS" value is not 3132 present, but an "AS" value is specified, generate a "TIAS" 3133 value using this formula: 3135 TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 3137 The 50 is based on 50 packets per second, the 40 is based on an 3138 estimate of total header size, the 1000 changes the unit from 3139 kbps to bps (as required by TIAS), and the 0.95 is to allocate 3140 5% to RTCP. "TIAS" is used in preference to "AS" because it 3141 provides more accurate control of bandwidth. 3143 * For any "RR" or "RS" bandwidth values, handle as specified in 3144 [RFC3556], Section 2. 3146 * Any specified "CT" bandwidth value MUST be ignored, as the 3147 meaning of this construct at the media level is not well 3148 defined. 3150 * If the m= section is of type audio: 3152 + For each specified "CN" media format, enable DTX for all 3153 supported media formats with the same clockrate, as 3154 described in [RFC3389], Section 5, except for formats that 3155 have their own internal DTX mechanisms. DTX for such 3156 formats (e.g., Opus) is controlled via fmtp parameters, as 3157 discussed in Section 5.2.3.2. 3159 + For each specified "telephone-event" media format, enable 3160 DTMF transmission for all supported media formats with the 3161 same clockrate, as described in [RFC4733], Section 2.5.1.2. 3162 If the application attempts to transmit DTMF when using a 3163 media format that does not have a corresponding telephone- 3164 event format, this MUST result in an error. 3166 + For any specified "ptime" value, configure the available 3167 media formats to use the specified packet size. If the 3168 specified size is not supported for a media format, use the 3169 next closest value instead. 3171 Finally, if this description is of type "pranswer" or "answer", 3172 follow the processing defined in the Section 5.10 section below. 3174 5.10. Applying an Answer 3176 In addition to the steps mentioned above for processing a local or 3177 remote description, the following steps are performed when processing 3178 a description of type "pranswer" or "answer". 3180 For each m= section, the following steps MUST be performed: 3182 o If the m= section has been rejected (i.e. port is set to zero in 3183 the answer), stop any reception or transmission of media for this 3184 section, and, unless a non-rejected m= section is bundled with 3185 this m= section, discard any associated ICE components, as 3186 described in Section 9.2.1.3 of [RFC5245]. 3188 o If the remote DTLS fingerprint has been changed or the dtls-id has 3189 changed, tear down the DTLS connection. This includes the case 3190 when the PeerConnection state is "have-remote-pranswer". If a 3191 DTLS connection needs to be torn down but the answer does not 3192 indicate an ICE restart or, in the case of "have-remote-pranswer", 3193 new ICE credentials, an error MUST be generated. If an ICE 3194 restart is performed without a change in dtls-id or fingerprint, 3195 then the same DTLS connection is continued over the new ICE 3196 channel. 3198 o If no valid DTLS connection exists, prepare to start a DTLS 3199 connection, using the specified roles and fingerprints, on any 3200 underlying ICE components, once they are active. 3202 o If the m= section proto value indicates use of RTP: 3204 * If the m= section references any media formats, RTP header 3205 extensions, or RTCP feedback mechanisms that were not present 3206 in the corresponding m= section in the offer, this indicates a 3207 negotiation problem and MUST result in an error. 3209 * If the m= section has RTCP mux enabled, discard the RTCP ICE 3210 component, if one exists, and begin or continue muxing RTCP 3211 over the RTP ICE component, as specified in [RFC5761], 3212 Section 5.1.3. Otherwise, prepare to transmit RTCP over the 3213 RTCP ICE component; if no RTCP ICE component exists, because 3214 RTCP mux was previously enabled, this MUST result in an error. 3216 * If the m= section has reduced-size RTCP enabled, configure the 3217 RTCP transmission for this m= section to use reduced-size RTCP, 3218 as specified in [RFC5506]. 3220 * If the directional attribute in the answer is of type 3221 "sendrecv" or "sendonly", choose the media format to send as 3222 the most preferred media format from the remote description 3223 that is also present in the answer, as described in [RFC3264], 3224 Sections 6.1 and 7, and start transmitting RTP media once the 3225 underlying transport layers have been established. If an SSRC 3226 has not already been chosen for this outgoing RTP stream, 3227 choose a random one. If media is already being transmitted, 3228 the same SSRC SHOULD be used unless the clockrate of the new 3229 codec is different, in which case a new SSRC MUST be chosen, as 3230 specified in [RFC7160], Section 3.1. 3232 * The payload type mapping from the remote description is used to 3233 determine payload types for the outgoing RTP streams, including 3234 the payload type for the send media format chosen above. Any 3235 RTP header extensions that were negotiated should be included 3236 in the outgoing RTP streams, using the extension mapping from 3237 the remote description; if the RID header extension has been 3238 negotiated, and RID values are specified, include the RID 3239 header extension in the outgoing RTP streams, as indicated in 3240 [I-D.ietf-mmusic-rid], Section 4. 3242 * If simulcast has been negotiated, send the number of Source RTP 3243 Streams as specified in [I-D.ietf-mmusic-sdp-simulcast], 3244 Section 6.2.2. 3246 * If the send media format chosen above has a corresponding "rtx" 3247 media format, or a FEC mechanism has been negotiated, establish 3248 a Redundancy RTP Stream with a random SSRC for each Source RTP 3249 Stream, and start or continue transmitting RTX/FEC packets as 3250 needed. 3252 * If the send media format chosen above has a corresponding "red" 3253 media format of the same clockrate, allow redundant encoding 3254 using the specified format for resiliency purposes, as 3255 discussed in [I-D.ietf-rtcweb-fec], Section 3.2. Note that 3256 unlike RTX or FEC media formats, the "red" format is 3257 transmitted on the Source RTP Stream, not the Redundancy RTP 3258 Stream. 3260 * Enable the RTCP feedback mechanisms referenced in the media 3261 section for all Source RTP Streams using the specified media 3262 formats. Specifically, begin or continue sending the requested 3263 feedback types and reacting to received feedback, as specified 3264 in [RFC4585], Section 4.2. When sending RTCP feedback, follow 3265 the rules and recommendations from 3266 [I-D.ietf-avtcore-rtp-multi-stream], Section 5.4.1 to select 3267 which SSRC to use. 3269 * If the directional attribute is of type "recvonly" or 3270 "inactive", stop transmitting all RTP media, but continue 3271 sending RTCP, as described in [RFC3264], Section 5.1. 3273 o If the m= section proto value indicates use of SCTP: 3275 * If an SCTP association exists, and the remote SCTP port has 3276 changed, discard the existing SCTP association. This includes 3277 the case when the PeerConnection state is "have-remote- 3278 pranswer". 3280 * If no valid SCTP association exists, prepare to initiate a SCTP 3281 association over the associated ICE component and DTLS 3282 connection, using the local SCTP port value from the local 3283 description, and the remote SCTP port value from the remote 3284 description, as described in [I-D.ietf-mmusic-sctp-sdp], 3285 Section 10.2. 3287 If the answer contains valid bundle groups, discard any ICE 3288 components for the m= sections that will be bundled onto the primary 3289 ICE components in each bundle, and begin muxing these m= sections 3290 accordingly, as described in 3291 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.2. 3293 If the description is of type "answer", and there are still remaining 3294 candidates in the ICE candidate pool, discard them. 3296 6. Processing RTP/RTCP 3298 When bundling, associating incoming RTP/RTCP with the proper m= 3299 section is defined in [I-D.ietf-mmusic-sdp-bundle-negotiation]. [The 3300 BUNDLE draft does not currently contain the necessary text to 3301 describe this demux, but when it does it will contain text like that 3302 contained in Appendix B.] When not bundling, the proper m= section 3303 is clear from the ICE component over which the RTP/RTCP is received. 3305 Once the proper m= section(s) are known, RTP/RTCP is delivered to the 3306 RtpTransceiver(s) associated with the m= section(s) and further 3307 processing of the RTP/RTCP is done at the RtpTransceiver level. This 3308 includes using RID [I-D.ietf-mmusic-rid] to distinguish between 3309 multiple Encoded Streams, as well as determine which Source RTP 3310 stream should be repaired by a given Redundancy RTP stream. 3312 7. Examples 3314 Note that this example section shows several SDP fragments. To 3315 format in 72 columns, some of the lines in SDP have been split into 3316 multiple lines, where leading whitespace indicates that a line is a 3317 continuation of the previous line. In addition, some blank lines 3318 have been added to improve readability but are not valid in SDP. 3320 More examples of SDP for WebRTC call flows can be found in 3321 [I-D.nandakumar-rtcweb-sdp]. 3323 7.1. Simple Example 3325 This section shows a very simple example that sets up a minimal audio 3326 / video call between two JSEP endpoints without using trickle ICE. 3327 The example in the following section provides a more detailed example 3328 of what could happen in a JSEP session. 3330 The code flow below shows Alice's endpoint initiating the session to 3331 Bob's endpoint. The messages from Alice's JS to Bob's JS are assumed 3332 to flow over some signaling protocol via a web server. The JS on 3333 both Alice's side and Bob's side waits for all candidates before 3334 sending the offer or answer, so the offers and answers are complete; 3335 trickle ICE is not used. Both Alice and Bob are using the default 3336 bundle policy of "balanced", and the default RTCP mux policy of 3337 "require". 3339 // set up local media state 3340 AliceJS->AliceUA: create new PeerConnection 3341 AliceJS->AliceUA: addTrack with two tracks: audio and video 3342 AliceJS->AliceUA: createOffer to get offer 3343 AliceJS->AliceUA: setLocalDescription with offer 3344 AliceUA->AliceJS: multiple onicecandidate events with candidates 3346 // wait for ICE gathering to complete 3347 AliceUA->AliceJS: onicecandidate event with null candidate 3348 AliceJS->AliceUA: get |offer-A1| from pendingLocalDescription 3350 // |offer-A1| is sent over signaling protocol to Bob 3351 AliceJS->WebServer: signaling with |offer-A1| 3352 WebServer->BobJS: signaling with |offer-A1| 3354 // |offer-A1| arrives at Bob 3355 BobJS->BobUA: create a PeerConnection 3356 BobJS->BobUA: setRemoteDescription with |offer-A1| 3357 BobUA->BobJS: ontrack events for audio and video tracks 3359 // Bob accepts call 3360 BobJS->BobUA: addTrack with local tracks 3361 BobJS->BobUA: createAnswer 3362 BobJS->BobUA: setLocalDescription with answer 3363 BobUA->BobJS: multiple onicecandidate events with candidates 3365 // wait for ICE gathering to complete 3366 BobUA->BobJS: onicecandidate event with null candidate 3367 BobJS->BobUA: get |answer-A1| from currentLocalDescription 3369 // |answer-A1| is sent over signaling protocol to Alice 3370 BobJS->WebServer: signaling with |answer-A1| 3371 WebServer->AliceJS: signaling with |answer-A1| 3373 // |answer-A1| arrives at Alice 3374 AliceJS->AliceUA: setRemoteDescription with |answer-A1| 3375 AliceUA->AliceJS: ontrack events for audio and video tracks 3377 // media flows 3378 BobUA->AliceUA: media sent from Bob to Alice 3379 AliceUA->BobUA: media sent from Alice to Bob 3381 The SDP for |offer-A1| looks like: 3383 v=0 3384 o=- 4962303333179871722 1 IN IP4 0.0.0.0 3385 s=- 3386 t=0 0 3387 a=ice-options:trickle 3388 a=group:BUNDLE a1 v1 3389 a=group:LS a1 v1 3391 m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3392 c=IN IP4 203.0.113.100 3393 a=mid:a1 3394 a=sendrecv 3395 a=rtpmap:96 opus/48000/2 3396 a=rtpmap:0 PCMU/8000 3397 a=rtpmap:8 PCMA/8000 3398 a=rtpmap:97 telephone-event/8000 3399 a=rtpmap:98 telephone-event/48000 3400 a=maxptime:120 3401 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3402 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3403 a=msid:47017fee-b6c1-4162-929c-a25110252400 3404 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 3405 a=ice-ufrag:ETEn 3406 a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl 3407 a=fingerprint:sha-256 3408 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3409 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3410 a=setup:actpass 3411 a=dtls-id:1 3412 a=rtcp:10101 IN IP4 203.0.113.100 3413 a=rtcp-mux 3414 a=rtcp-rsize 3415 a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host 3416 a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host 3417 a=end-of-candidates 3419 m=video 10102 UDP/TLS/RTP/SAVPF 100 101 3420 c=IN IP4 203.0.113.100 3421 a=mid:v1 3422 a=sendrecv 3423 a=rtpmap:100 VP8/90000 3424 a=rtpmap:101 rtx/90000 3425 a=fmtp:101 apt=100 3426 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3427 a=rtcp-fb:100 ccm fir 3428 a=rtcp-fb:100 nack 3429 a=rtcp-fb:100 nack pli 3430 a=msid:47017fee-b6c1-4162-929c-a25110252400 3431 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 3432 a=ice-ufrag:BGKk 3433 a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf 3434 a=fingerprint:sha-256 3435 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3436 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3437 a=setup:actpass 3438 a=dtls-id:1 3439 a=rtcp:10103 IN IP4 203.0.113.100 3440 a=rtcp-mux 3441 a=rtcp-rsize 3442 a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host 3443 a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host 3444 a=end-of-candidates 3446 The SDP for |answer-A1| looks like: 3448 v=0 3449 o=- 6729291447651054566 1 IN IP4 0.0.0.0 3450 s=- 3451 t=0 0 3452 a=ice-options:trickle 3453 a=group:BUNDLE a1 v1 3454 a=group:LS a1 v1 3456 m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3457 c=IN IP4 203.0.113.200 3458 a=mid:a1 3459 a=sendrecv 3460 a=rtpmap:96 opus/48000/2 3461 a=rtpmap:0 PCMU/8000 3462 a=rtpmap:8 PCMA/8000 3463 a=rtpmap:97 telephone-event/8000 3464 a=rtpmap:98 telephone-event/48000 3465 a=maxptime:120 3466 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3467 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3468 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 3469 5a7b57b8-f043-4bd1-a45d-09d4dfa31226 3470 a=ice-ufrag:6sFv 3471 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 3472 a=fingerprint:sha-256 3473 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 3474 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 3475 a=setup:active 3476 a=dtls-id:1 3477 a=rtcp-mux 3478 a=rtcp-rsize 3479 a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host 3480 a=end-of-candidates 3482 m=video 10200 UDP/TLS/RTP/SAVPF 100 101 3483 c=IN IP4 203.0.113.200 3484 a=mid:v1 3485 a=sendrecv 3486 a=rtpmap:100 VP8/90000 3487 a=rtpmap:101 rtx/90000 3488 a=fmtp:101 apt=100 3489 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3490 a=rtcp-fb:100 ccm fir 3491 a=rtcp-fb:100 nack 3492 a=rtcp-fb:100 nack pli 3493 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 3494 4ea4d4a1-2fda-4511-a9cc-1b32c2e59552 3496 7.2. Detailed Example 3498 This section shows a more involved example of a session between two 3499 JSEP endpoints. Trickle ICE is used in full trickle mode, with a 3500 bundle policy of "max-bundle", an RTCP mux policy of "require", and a 3501 single TURN server. Initially, both Alice and Bob establish an audio 3502 channel and a data channel. Later, Bob adds two video flows, one for 3503 his video feed, and one for screensharing, both supporting FEC, and 3504 with the video feed configured for simulcast. Alice accepts these 3505 video flows, but does not add video flows of her own, so they are 3506 handled as recvonly. Alice also specifies a maximum video decoder 3507 resolution. 3509 // set up local media state 3510 AliceJS->AliceUA: create new PeerConnection 3511 AliceJS->AliceUA: addTrack with an audio track 3512 AliceJS->AliceUA: createDataChannel to get data channel 3513 AliceJS->AliceUA: createOffer to get |offer-B1| 3514 AliceJS->AliceUA: setLocalDescription with |offer-B1| 3516 // |offer-B1| is sent over signaling protocol to Bob 3517 AliceJS->WebServer: signaling with |offer-B1| 3518 WebServer->BobJS: signaling with |offer-B1| 3520 // |offer-B1| arrives at Bob 3521 BobJS->BobUA: create a PeerConnection 3522 BobJS->BobUA: setRemoteDescription with |offer-B1| 3523 BobUA->BobJS: ontrack with audio track from Alice 3525 // candidates are sent to Bob 3526 AliceUA->AliceJS: onicecandidate (host) |offer-B1-candidate-1| 3527 AliceJS->WebServer: signaling with |offer-B1-candidate-1| 3528 AliceUA->AliceJS: onicecandidate (srflx) |offer-B1-candidate-2| 3529 AliceJS->WebServer: signaling with |offer-B1-candidate-2| 3530 AliceUA->AliceJS: onicecandidate (relay) |offer-B1-candidate-3| 3531 AliceJS->WebServer: signaling with |offer-B1-candidate-3| 3533 WebServer->BobJS: signaling with |offer-B1-candidate-1| 3534 BobJS->BobUA: addIceCandidate with |offer-B1-candidate-1| 3535 WebServer->BobJS: signaling with |offer-B1-candidate-2| 3536 BobJS->BobUA: addIceCandidate with |offer-B1-candidate-2| 3537 WebServer->BobJS: signaling with |offer-B1-candidate-3| 3538 BobJS->BobUA: addIceCandidate with |offer-B1-candidate-3| 3540 // Bob accepts call 3541 BobJS->BobUA: addTrack with local audio 3542 BobJS->BobUA: createDataChannel to get data channel 3543 BobJS->BobUA: createAnswer to get |answer-B1| 3544 BobJS->BobUA: setLocalDescription with |answer-B1| 3546 // |answer-B1| is sent to Alice 3547 BobJS->WebServer: signaling with |answer-B1| 3548 WebServer->AliceJS: signaling with |answer-B1| 3549 AliceJS->AliceUA: setRemoteDescription with |answer-B1| 3550 AliceUA->AliceJS: ontrack event with audio track from Bob 3552 // candidates are sent to Alice 3553 BobUA->BobJS: onicecandidate (host) |answer-B1-candidate-1| 3554 BobJS->WebServer: signaling with |answer-B1-candidate-1| 3555 BobUA->BobJS: onicecandidate (srflx) |answer-B1-candidate-2| 3556 BobJS->WebServer: signaling with |answer-B1-candidate-2| 3557 BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-3| 3558 BobJS->WebServer: signaling with |answer-B1-candidate-3| 3560 WebServer->AliceJS: signaling with |answer-B1-candidate-1| 3561 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| 3562 WebServer->AliceJS: signaling with |answer-B1-candidate-2| 3563 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-2| 3564 WebServer->AliceJS: signaling with |answer-B1-candidate-3| 3565 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-3| 3567 // data channel opens 3568 BobUA->BobJS: ondatachannel event 3569 AliceUA->AliceJS: ondatachannel event 3570 BobUA->BobJS: onopen 3571 AliceUA->AliceJS: onopen 3573 // media is flowing between endpoints 3574 BobUA->AliceUA: audio+data sent from Bob to Alice 3575 AliceUA->BobUA: audio+data sent from Alice to Bob 3577 // some time later Bob adds two video streams 3578 // note, no candidates exchanged, because of bundle 3579 BobJS->BobUA: addTrack with first video stream 3580 BobJS->BobUA: addTrack with second video stream 3581 BobJS->BobUA: createOffer to get |offer-B2| 3582 BobJS->BobUA: setLocalDescription with |offer-B2| 3584 // |offer-B2| is sent to Alice 3585 BobJS->WebServer: signaling with |offer-B2| 3586 WebServer->AliceJS: signaling with |offer-B2| 3587 AliceJS->AliceUA: setRemoteDescription with |offer-B2| 3588 AliceUA->AliceJS: ontrack event with first video track 3589 AliceUA->AliceJS: ontrack event with second video track 3590 AliceJS->AliceUA: createAnswer to get |answer-B2| 3591 AliceJS->AliceUA: setLocalDescription with |answer-B2| 3593 // |answer-B2| is sent over signaling protocol to Bob 3594 AliceJS->WebServer: signaling with |answer-B2| 3595 WebServer->BobJS: signaling with |answer-B2| 3596 BobJS->BobUA: setRemoteDescription with |answer-B2| 3598 // media is flowing between endpoints 3599 BobUA->AliceUA: audio+video+data sent from Bob to Alice 3600 AliceUA->BobUA: audio+video+data sent from Alice to Bob 3602 The SDP for |offer-B1| looks like: 3604 v=0 3605 o=- 4962303333179871723 1 IN IP4 0.0.0.0 3606 s=- 3607 t=0 0 3608 a=ice-options:trickle 3609 a=group:BUNDLE a1 d1 3611 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3612 c=IN IP4 0.0.0.0 3613 a=mid:a1 3614 a=sendrecv 3615 a=rtpmap:96 opus/48000/2 3616 a=rtpmap:0 PCMU/8000 3617 a=rtpmap:8 PCMA/8000 3618 a=rtpmap:97 telephone-event/8000 3619 a=rtpmap:98 telephone-event/48000 3620 a=maxptime:120 3621 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3622 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3623 a=msid:57017fee-b6c1-4162-929c-a25110252400 3624 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 3625 a=ice-ufrag:ATEn 3626 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 3627 a=fingerprint:sha-256 3628 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3629 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3630 a=setup:actpass 3631 a=dtls-id:1 3632 a=rtcp-mux 3633 a=rtcp-mux-only 3634 a=rtcp-rsize 3636 m=application 0 UDP/DTLS/SCTP webrtc-datachannel 3637 c=IN IP4 0.0.0.0 3638 a=mid:d1 3639 a=sctp-port:5000 3640 a=max-message-size:65536 3641 a=bundle-only 3643 |offer-B1-candidate-1| looks like: 3645 ufrag ATEn 3646 index 0 3647 mid a1 3648 attr candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host 3649 |offer-B1-candidate-2| looks like: 3651 ufrag ATEn 3652 index 0 3653 mid a1 3654 attr candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx 3655 raddr 203.0.113.100 rport 10100 3657 |offer-B1-candidate-3| looks like: 3659 ufrag ATEn 3660 index 0 3661 mid a1 3662 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay 3663 raddr 198.51.100.100 rport 11100 3665 The SDP for |answer-B1| looks like: 3667 v=0 3668 o=- 7729291447651054566 1 IN IP4 0.0.0.0 3669 s=- 3670 t=0 0 3671 a=ice-options:trickle 3672 a=group:BUNDLE a1 d1 3674 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3675 c=IN IP4 0.0.0.0 3676 a=mid:a1 3677 a=sendrecv 3678 a=rtpmap:96 opus/48000/2 3679 a=rtpmap:0 PCMU/8000 3680 a=rtpmap:8 PCMA/8000 3681 a=rtpmap:97 telephone-event/8000 3682 a=rtpmap:98 telephone-event/48000 3683 a=maxptime:120 3684 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3685 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3686 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 3687 6a7b57b8-f043-4bd1-a45d-09d4dfa31226 3688 a=ice-ufrag:7sFv 3689 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 3690 a=fingerprint:sha-256 3691 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 3692 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 3693 a=setup:active 3694 a=dtls-id:1 3695 a=rtcp-mux 3696 a=rtcp-mux-only 3697 a=rtcp-rsize 3699 m=application 9 UDP/DTLS/SCTP webrtc-datachannel 3700 c=IN IP4 0.0.0.0 3701 a=mid:d1 3702 a=sctp-port:5000 3703 a=max-message-size:65536 3705 |answer-B1-candidate-1| looks like: 3707 ufrag 7sFv 3708 index 0 3709 mid a1 3710 attr candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host 3711 |answer-B1-candidate-2| looks like: 3713 ufrag 7sFv 3714 index 0 3715 mid a1 3716 attr candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx 3717 raddr 203.0.113.200 rport 10200 3719 |answer-B1-candidate-3| looks like: 3721 ufrag 7sFv 3722 index 0 3723 mid a1 3724 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay 3725 raddr 198.51.100.200 rport 11200 3727 The SDP for |offer-B2| is shown below. In addition to the new m= 3728 sections for video, both of which are offering FEC, and one of which 3729 is offering simulcast, note the increment of the version number in 3730 the o= line, changes to the c= line, indicating the local candidate 3731 that was selected, and the inclusion of gathered candidates as 3732 a=candidate lines. 3734 v=0 3735 o=- 7729291447651054566 2 IN IP4 0.0.0.0 3736 s=- 3737 t=0 0 3738 a=ice-options:trickle 3739 a=group:BUNDLE a1 d1 v1 v2 3740 a=group:LS a1 v1 3742 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3743 c=IN IP4 192.0.2.200 3744 a=mid:a1 3745 a=sendrecv 3746 a=rtpmap:96 opus/48000/2 3747 a=rtpmap:0 PCMU/8000 3748 a=rtpmap:8 PCMA/8000 3749 a=rtpmap:97 telephone-event/8000 3750 a=rtpmap:98 telephone-event/48000 3751 a=maxptime:120 3752 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3753 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3754 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 3755 6a7b57b8-f043-4bd1-a45d-09d4dfa31226 3756 a=ice-ufrag:7sFv 3757 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 3758 a=fingerprint:sha-256 3759 7B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35: 3760 DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 3761 a=setup:actpass 3762 a=dtls-id:1 3763 a=rtcp-mux 3764 a=rtcp-mux-only 3765 a=rtcp-rsize 3766 a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host 3767 a=candidate:1 1 udp 1845494015 198.51.100.200 11200 typ srflx 3768 raddr 203.0.113.200 rport 10200 3769 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay 3770 raddr 198.51.100.200 rport 11200 3771 a=end-of-candidates 3773 m=application 12200 UDP/DTLS/SCTP webrtc-datachannel 3774 c=IN IP4 192.0.2.200 3775 a=mid:d1 3776 a=sctp-port:5000 3777 a=max-message-size:65536 3779 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 3780 c=IN IP4 192.0.2.200 3781 a=mid:v1 3782 a=sendrecv 3783 a=rtpmap:100 VP8/90000 3784 a=rtpmap:101 rtx/90000 3785 a=fmtp:101 apt=100 3786 a=rtpmap:102 flexfec/90000 3787 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3788 a=rtcp-fb:100 ccm fir 3789 a=rtcp-fb:100 nack 3790 a=rtcp-fb:100 nack pli 3791 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 3792 5ea4d4a1-2fda-4511-a9cc-1b32c2e59552 3793 a=rid:1 send 3794 a=rid:2 send 3795 a=rid:3 send 3796 a=simulcast:send 1;2;3 3798 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 102 3799 c=IN IP4 192.0.2.200 3800 a=mid:v2 3801 a=sendrecv 3802 a=rtpmap:100 VP8/90000 3803 a=rtpmap:101 rtx/90000 3804 a=fmtp:101 apt=100 3805 a=rtpmap:102 flexfec/90000 3806 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3807 a=rtcp-fb:100 ccm fir 3808 a=rtcp-fb:100 nack 3809 a=rtcp-fb:100 nack pli 3810 a=msid:81317484-2ed4-49d7-9eb7-1414322a7aae 3811 6ea4d4a1-2fda-4511-a9cc-1b32c2e59552 3813 The SDP for |answer-B2| is shown below. In addition to the 3814 acceptance of the video m= sections, the use of a=recvonly to 3815 indicate one-way video, and the use of a=imageattr to limit the 3816 received resolution, note the use of setup:passive to maintain the 3817 existing DTLS roles. 3819 v=0 3820 o=- 4962303333179871723 2 IN IP4 0.0.0.0 3821 s=- 3822 t=0 0 3823 a=ice-options:trickle 3824 a=group:BUNDLE a1 d1 v1 v2 3825 a=group:LS a1 v1 3827 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3828 c=IN IP4 192.0.2.100 3829 a=mid:a1 3830 a=sendrecv 3831 a=rtpmap:96 opus/48000/2 3832 a=rtpmap:0 PCMU/8000 3833 a=rtpmap:8 PCMA/8000 3834 a=rtpmap:97 telephone-event/8000 3835 a=rtpmap:98 telephone-event/48000 3836 a=maxptime:120 3837 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3838 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 3839 a=msid:57017fee-b6c1-4162-929c-a25110252400 3840 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 3841 a=ice-ufrag:ATEn 3842 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 3843 a=fingerprint:sha-256 3844 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04: 3845 BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 3846 a=setup:passive 3847 a=dtls-id:1 3848 a=rtcp-mux 3849 a=rtcp-mux-only 3850 a=rtcp-rsize 3851 a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host 3852 a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx 3853 raddr 203.0.113.100 rport 10100 3854 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay 3855 raddr 198.51.100.100 rport 11100 3856 a=end-of-candidates 3858 m=application 12100 UDP/DTLS/SCTP webrtc-datachannel 3859 c=IN IP4 192.0.2.100 3860 a=mid:d1 3861 a=sctp-port:5000 3862 a=max-message-size:65536 3864 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 3865 c=IN IP4 192.0.2.100 3866 a=mid:v1 3867 a=recvonly 3868 a=rtpmap:100 VP8/90000 3869 a=rtpmap:101 rtx/90000 3870 a=fmtp:101 apt=100 3871 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] 3872 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3873 a=rtcp-fb:100 ccm fir 3874 a=rtcp-fb:100 nack 3875 a=rtcp-fb:100 nack pli 3877 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 3878 c=IN IP4 192.0.2.100 3879 a=mid:v2 3880 a=recvonly 3881 a=rtpmap:100 VP8/90000 3882 a=rtpmap:101 rtx/90000 3883 a=fmtp:101 apt=100 3884 a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0] 3885 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 3886 a=rtcp-fb:100 ccm fir 3887 a=rtcp-fb:100 nack 3888 a=rtcp-fb:100 nack pli 3890 7.3. Early Transport Warmup Example 3892 This example demonstrates the early warmup technique described in 3893 Section 4.1.8.1. Here, Alice's endpoint sends an offer to Bob's 3894 endpoint to start an audio/video call. Bob immediately responds with 3895 an answer that accepts the audio/video m= sections, but marks them as 3896 sendonly (from his perspective), meaning that Alice will not yet send 3897 media. This allows the JSEP implementation to start negotiating ICE 3898 and DTLS immediately. Bob's endpoint then prompts him to answer the 3899 call, and when he does, his endpoint sends a second offer which 3900 enables the audio and video m= sections, and thereby bidirectional 3901 media transmission. The advantage of such a flow is that as soon as 3902 the first answer is received, the implementation can proceed with ICE 3903 and DTLS negotiation and establish the session transport. If the 3904 transport setup completes before the second offer is sent, then media 3905 can be transmitted immediately by the callee immediately upon 3906 answering the call, minimizing perceived post-dial-delay. The second 3907 offer/answer exchange can also change the preferred codecs or other 3908 session parameters. 3910 This example also makes use of the "relay" ICE candidate policy 3911 described in Section 3.5.3 to minimize the ICE gathering and checking 3912 needed. 3914 // set up local media state 3915 AliceJS->AliceUA: create new PeerConnection with "relay" ICE policy 3916 AliceJS->AliceUA: addTrack with two tracks: audio and video 3917 AliceJS->AliceUA: createOffer to get |offer-C1| 3918 AliceJS->AliceUA: setLocalDescription with |offer-C1| 3920 // |offer-C1| is sent over signaling protocol to Bob 3921 AliceJS->WebServer: signaling with |offer-C1| 3922 WebServer->BobJS: signaling with |offer-C1| 3924 // |offer-C1| arrives at Bob 3925 BobJS->BobUA: create new PeerConnection with "relay" ICE policy 3926 BobJS->BobUA: setRemoteDescription with |offer-C1| 3927 BobUA->BobJS: ontrack events for audio and video 3929 // a relay candidate is sent to Bob 3930 AliceUA->AliceJS: onicecandidate (relay) |offer-C1-candidate-1| 3931 AliceJS->WebServer: signaling with |offer-C1-candidate-1| 3933 WebServer->BobJS: signaling with |offer-C1-candidate-1| 3934 BobJS->BobUA: addIceCandidate with |offer-C1-candidate-1| 3936 // Bob prepares an early answer to warm up the transport 3937 BobJS->BobUA: addTransceiver with null audio and video tracks 3938 BobJS->BobUA: transceiver.setDirection(sendonly) for both 3939 BobJS->BobUA: createAnswer 3940 BobJS->BobUA: setLocalDescription with answer 3942 // |answer-C1| is sent over signaling protocol to Alice 3943 BobJS->WebServer: signaling with |answer-C1| 3944 WebServer->AliceJS: signaling with |answer-C1| 3946 // |answer-C1| (sendonly) arrives at Alice 3947 AliceJS->AliceUA: setRemoteDescription with |answer-C1| 3948 AliceUA->AliceJS: ontrack events for audio and video 3950 // a relay candidate is sent to Alice 3951 BobUA->BobJS: onicecandidate (relay) |answer-B1-candidate-1| 3952 BobJS->WebServer: signaling with |answer-B1-candidate-1| 3954 WebServer->AliceJS: signaling with |answer-B1-candidate-1| 3955 AliceJS->AliceUA: addIceCandidate with |answer-B1-candidate-1| 3957 // ICE and DTLS establish while call is ringing 3959 // Bob accepts call, starts media, and sends a new offer 3960 BobJS->BobUA: transceiver.setTrack with audio and video tracks 3961 BobUA->AliceUA: media sent from Bob to Alice 3962 BobJS->BobUA: transceiver.setDirection(sendrecv) for both 3963 transceivers 3964 BobJS->BobUA: createOffer 3965 BobJS->BobUA: setLocalDescription with offer 3967 // |offer-C2| is sent over signaling protocol to Alice 3968 BobJS->WebServer: signaling with |offer-C2| 3969 WebServer->AliceJS: signaling with |offer-C2| 3971 // |offer-C2| (sendrecv) arrives at Alice 3972 AliceJS->AliceUA: setRemoteDescription with |offer-C2| 3973 AliceJS->AliceUA: createAnswer 3974 AliceJS->AliceUA: setLocalDescription with |answer-C2| 3975 AliceUA->BobUA: media sent from Alice to Bob 3977 // |answer-C2| is sent over signaling protocol to Bob 3978 AliceJS->WebServer: signaling with |answer-C2| 3979 WebServer->BobJS: signaling with |answer-C2| 3980 BobJS->BobUA: setRemoteDescription with |answer-C2| 3982 The SDP for |offer-C1| looks like: 3984 v=0 3985 o=- 1070771854436052752 1 IN IP4 0.0.0.0 3986 s=- 3987 t=0 0 3988 a=ice-options:trickle 3989 a=group:BUNDLE a1 v1 3990 a=group:LS a1 v1 3992 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 3993 c=IN IP4 0.0.0.0 3994 a=mid:a1 3995 a=sendrecv 3996 a=rtpmap:96 opus/48000/2 3997 a=rtpmap:0 PCMU/8000 3998 a=rtpmap:8 PCMA/8000 3999 a=rtpmap:97 telephone-event/8000 4000 a=rtpmap:98 telephone-event/48000 4001 a=maxptime:120 4002 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4003 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4004 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4005 e80098db-7159-3c06-229a-00df2a9b3dbc 4006 a=ice-ufrag:4ZcD 4007 a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD 4008 a=fingerprint:sha-256 4009 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 4010 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF 4011 a=setup:actpass 4012 a=dtls-id:1 4013 a=rtcp-mux 4014 a=rtcp-mux-only 4015 a=rtcp-rsize 4017 m=video 0 UDP/TLS/RTP/SAVPF 100 101 4018 c=IN IP4 0.0.0.0 4019 a=mid:v1 4020 a=sendrecv 4021 a=rtpmap:100 VP8/90000 4022 a=rtpmap:101 rtx/90000 4023 a=fmtp:101 apt=100 4024 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4025 a=rtcp-fb:100 ccm fir 4026 a=rtcp-fb:100 nack 4027 a=rtcp-fb:100 nack pli 4028 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4029 ac701365-eb06-42df-cc93-7f22bc308789 4030 a=bundle-only 4031 |offer-C1-candidate-1| looks like: 4033 ufrag 4ZcD 4034 index 0 4035 mid a1 4036 attr candidate:1 1 udp 255 192.0.2.100 12100 typ relay 4037 raddr 0.0.0.0 rport 0 4039 The SDP for |answer-C1| looks like: 4041 v=0 4042 o=- 6386516489780559513 1 IN IP4 0.0.0.0 4043 s=- 4044 t=0 0 4045 a=ice-options:trickle 4046 a=group:BUNDLE a1 v1 4047 a=group:LS a1 v1 4049 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4050 c=IN IP4 0.0.0.0 4051 a=mid:a1 4052 a=sendonly 4053 a=rtpmap:96 opus/48000/2 4054 a=rtpmap:0 PCMU/8000 4055 a=rtpmap:8 PCMA/8000 4056 a=rtpmap:97 telephone-event/8000 4057 a=rtpmap:98 telephone-event/48000 4058 a=maxptime:120 4059 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4060 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4061 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4062 04b5a445-82cc-c9e8-9ffe-c24d0ef4b0ff 4063 a=ice-ufrag:TpaA 4064 a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ 4065 a=fingerprint:sha-256 4066 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 4067 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D 4068 a=setup:active 4069 a=dtls-id:1 4070 a=rtcp-mux 4071 a=rtcp-mux-only 4072 a=rtcp-rsize 4074 m=video 9 UDP/TLS/RTP/SAVPF 100 101 4075 c=IN IP4 0.0.0.0 4076 a=mid:v1 4077 a=sendonly 4078 a=rtpmap:100 VP8/90000 4079 a=rtpmap:101 rtx/90000 4080 a=fmtp:101 apt=100 4081 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4082 a=rtcp-fb:100 ccm fir 4083 a=rtcp-fb:100 nack 4084 a=rtcp-fb:100 nack pli 4085 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4086 39292672-c102-d075-f580-5826f31ca958 4088 |answer-C1-candidate-1| looks like: 4090 ufrag TpaA 4091 index 0 4092 mid a1 4093 attr candidate:1 1 udp 255 192.0.2.200 12200 typ relay 4094 raddr 0.0.0.0 rport 0 4096 The SDP for |offer-C2| looks like: 4098 v=0 4099 o=- 6386516489780559513 2 IN IP4 0.0.0.0 4100 s=- 4101 t=0 0 4102 a=ice-options:trickle 4103 a=group:BUNDLE a1 v1 4104 a=group:LS a1 v1 4106 m=audio 12200 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4107 c=IN IP4 192.0.2.200 4108 a=mid:a1 4109 a=sendrecv 4110 a=rtpmap:96 opus/48000/2 4111 a=rtpmap:0 PCMU/8000 4112 a=rtpmap:8 PCMA/8000 4113 a=rtpmap:97 telephone-event/8000 4114 a=rtpmap:98 telephone-event/48000 4115 a=maxptime:120 4116 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4117 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4118 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4119 04b5a445-82cc-c9e8-9ffe-c24d0ef4b0ff 4120 a=ice-ufrag:TpaA 4121 a=ice-pwd:t2Ouhc67y8JcCaYZxUUTgKw/ 4122 a=fingerprint:sha-256 4123 A2:F3:A5:6D:4C:8C:1E:B2:62:10:4A:F6:70:61:C4:FC: 4124 3C:E0:01:D6:F3:24:80:74:DA:7C:3E:50:18:7B:CE:4D 4125 a=setup:actpass 4126 a=dtls-id:1 4127 a=rtcp-mux 4128 a=rtcp-mux-only 4129 a=rtcp-rsize 4130 a=candidate:1 1 udp 255 192.0.2.200 12200 typ relay 4131 raddr 0.0.0.0 rport 0 4132 a=end-of-candidates 4133 m=video 12200 UDP/TLS/RTP/SAVPF 100 101 4134 c=IN IP4 192.0.2.200 4135 a=mid:v1 4136 a=sendrecv 4137 a=rtpmap:100 VP8/90000 4138 a=rtpmap:101 rtx/90000 4139 a=fmtp:101 apt=100 4140 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4141 a=rtcp-fb:100 ccm fir 4142 a=rtcp-fb:100 nack 4143 a=rtcp-fb:100 nack pli 4144 a=msid:751f239e-4ae0-c549-aa3d-890de772998b 4145 39292672-c102-d075-f580-5826f31ca958 4147 The SDP for |answer-C2| looks like: 4149 v=0 4150 o=- 1070771854436052752 2 IN IP4 0.0.0.0 4151 s=- 4152 t=0 0 4153 a=ice-options:trickle 4154 a=group:BUNDLE a1 v1 4155 a=group:LS a1 v1 4157 m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98 4158 c=IN IP4 192.0.2.100 4159 a=mid:a1 4160 a=sendrecv 4161 a=rtpmap:96 opus/48000/2 4162 a=rtpmap:0 PCMU/8000 4163 a=rtpmap:8 PCMA/8000 4164 a=rtpmap:97 telephone-event/8000 4165 a=rtpmap:98 telephone-event/48000 4166 a=maxptime:120 4167 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4168 a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level 4169 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4170 e80098db-7159-3c06-229a-00df2a9b3dbc 4171 a=ice-ufrag:4ZcD 4172 a=ice-pwd:ZaaG6OG7tCn4J/lehAGz+HHD 4173 a=fingerprint:sha-256 4174 C4:68:F8:77:6A:44:F1:98:6D:7C:9F:47:EB:E3:34:A4: 4175 0A:AA:2D:49:08:28:70:2E:1F:AE:18:7D:4E:3E:66:BF 4176 a=setup:passive 4177 a=dtls-id:1 4178 a=rtcp-mux 4179 a=rtcp-mux-only 4180 a=rtcp-rsize 4181 a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay 4182 raddr 0.0.0.0 rport 0 4183 a=end-of-candidates 4185 m=video 12100 UDP/TLS/RTP/SAVPF 100 101 4186 c=IN IP4 192.0.2.100 4187 a=mid:v1 4188 a=sendrecv 4189 a=rtpmap:100 VP8/90000 4190 a=rtpmap:101 rtx/90000 4191 a=fmtp:101 apt=100 4192 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid 4193 a=rtcp-fb:100 ccm fir 4194 a=rtcp-fb:100 nack 4195 a=rtcp-fb:100 nack pli 4196 a=msid:bbce3ba6-abfc-ac63-d00a-e15b286f8fce 4197 ac701365-eb06-42df-cc93-7f22bc308789 4199 8. Security Considerations 4201 The IETF has published separate documents 4202 [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing 4203 the security architecture for WebRTC as a whole. The remainder of 4204 this section describes security considerations for this document. 4206 While formally the JSEP interface is an API, it is better to think of 4207 it is an Internet protocol, with the JS being untrustworthy from the 4208 perspective of the endpoint. Thus, the threat model of [RFC3552] 4209 applies. In particular, JS can call the API in any order and with 4210 any inputs, including malicious ones. This is particularly relevant 4211 when we consider the SDP which is passed to setLocalDescription(). 4212 While correct API usage requires that the application pass in SDP 4213 which was derived from createOffer() or createAnswer(), there is no 4214 guarantee that applications do so. The JSEP implementation MUST be 4215 prepared for the JS to pass in bogus data instead. 4217 Conversely, the application programmer MUST recognize that the JS 4218 does not have complete control of endpoint behavior. One case that 4219 bears particular mention is that editing ICE candidates out of the 4220 SDP or suppressing trickled candidates does not have the expected 4221 behavior: implementations will still perform checks from those 4222 candidates even if they are not sent to the other side. Thus, for 4223 instance, it is not possible to prevent the remote peer from learning 4224 your public IP address by removing server reflexive candidates. 4226 Applications which wish to conceal their public IP address should 4227 instead configure the ICE agent to use only relay candidates. 4229 9. IANA Considerations 4231 This document requires no actions from IANA. 4233 10. Acknowledgements 4235 Harald Alvestrand, Taylor Brandstetter, Suhas Nandakumar, and Peter 4236 Thatcher provided significant text for this draft. Bernard Aboba, 4237 Adam Bergkvist, Dan Burnett, Ben Campbell, Alissa Cooper, Richard 4238 Ejzak, Stefan Hakansson, Ted Hardie, Christer Holmberg Andrew Hutton, 4239 Randell Jesup, Matthew Kaufman, Anant Narayanan, Adam Roach, Neil 4240 Stratford, Martin Thomson, Sean Turner, and Magnus Westerlund all 4241 provided valuable feedback on this proposal. 4243 11. References 4245 11.1. Normative References 4247 [I-D.ietf-avtcore-rtp-multi-stream] 4248 Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, 4249 "Sending Multiple RTP Streams in a Single RTP Session", 4250 draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), 4251 December 2015. 4253 [I-D.ietf-avtext-rid] 4254 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 4255 Identifier (RID) Source Description (SDES)", draft-ietf- 4256 avtext-rid-00 (work in progress), February 2016. 4258 [I-D.ietf-ice-trickle] 4259 Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre, 4260 "Trickle ICE: Incremental Provisioning of Candidates for 4261 the Interactive Connectivity Establishment (ICE) 4262 Protocol". 4264 [I-D.ietf-mmusic-4572-update] 4265 Holmberg, C., "Updates to RFC 4572", draft-ietf-mmusic- 4266 4572-update-05 (work in progress), June 2016. 4268 [I-D.ietf-mmusic-dtls-sdp] 4269 Holmberg, C. and R. Shpount, "Using the SDP Offer/Answer 4270 Mechanism for DTLS", draft-ietf-mmusic-dtls-sdp-14 (work 4271 in progress), July 2016. 4273 [I-D.ietf-mmusic-msid] 4274 Alvestrand, H., "Cross Session Stream Identification in 4275 the Session Description Protocol", draft-ietf-mmusic- 4276 msid-01 (work in progress), August 2013. 4278 [I-D.ietf-mmusic-mux-exclusive] 4279 Holmberg, C., "Indicating Exclusive Support of RTP/RTCP 4280 Multiplexing using SDP", draft-ietf-mmusic-mux- 4281 exclusive-08 (work in progress), June 2016. 4283 [I-D.ietf-mmusic-rid] 4284 Thatcher, P., Zanaty, M., Nandakumar, S., Burman, B., 4285 Roach, A., and B. Campen, "RTP Payload Format 4286 Constraints", draft-ietf-mmusic-rid-04 (work in progress), 4287 February 2016. 4289 [I-D.ietf-mmusic-sctp-sdp] 4290 Loreto, S. and G. Camarillo, "Stream Control Transmission 4291 Protocol (SCTP)-Based Media Transport in the Session 4292 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 4293 (work in progress), June 2013. 4295 [I-D.ietf-mmusic-sdp-bundle-negotiation] 4296 Holmberg, C., Alvestrand, H., and C. Jennings, 4297 "Multiplexing Negotiation Using Session Description 4298 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 4299 bundle-negotiation-04 (work in progress), June 2013. 4301 [I-D.ietf-mmusic-sdp-mux-attributes] 4302 Nandakumar, S., "A Framework for SDP Attributes when 4303 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-01 4304 (work in progress), February 2014. 4306 [I-D.ietf-mmusic-sdp-simulcast] 4307 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 4308 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 4309 mmusic-sdp-simulcast-04 (work in progress), February 2016. 4311 [I-D.ietf-rtcweb-audio] 4312 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 4313 Requirements", draft-ietf-rtcweb-audio-02 (work in 4314 progress), August 2013. 4316 [I-D.ietf-rtcweb-fec] 4317 Uberti, J., "WebRTC Forward Error Correction 4318 Requirements", draft-ietf-rtcweb-fec-00 (work in 4319 progress), February 2015. 4321 [I-D.ietf-rtcweb-rtp-usage] 4322 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 4323 Communication (WebRTC): Media Transport and Use of RTP", 4324 draft-ietf-rtcweb-rtp-usage-09 (work in progress), 4325 September 2013. 4327 [I-D.ietf-rtcweb-security] 4328 Rescorla, E., "Security Considerations for WebRTC", draft- 4329 ietf-rtcweb-security-06 (work in progress), January 2014. 4331 [I-D.ietf-rtcweb-security-arch] 4332 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 4333 rtcweb-security-arch-09 (work in progress), February 2014. 4335 [I-D.ietf-rtcweb-video] 4336 Roach, A., "WebRTC Video Processing and Codec 4337 Requirements", draft-ietf-rtcweb-video-00 (work in 4338 progress), July 2014. 4340 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4341 Requirement Levels", BCP 14, RFC 2119, March 1997. 4343 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 4344 A., Peterson, J., Sparks, R., Handley, M., and E. 4345 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 4346 June 2002. 4348 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 4349 with Session Description Protocol (SDP)", RFC 3264, June 4350 2002. 4352 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 4353 Text on Security Considerations", BCP 72, RFC 3552, July 4354 2003. 4356 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 4357 in Session Description Protocol (SDP)", RFC 3605, October 4358 2003. 4360 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 4361 Modifier for the Session Description Protocol (SDP)", 4362 RFC 3890, DOI 10.17487/RFC3890, September 2004, 4363 . 4365 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 4366 the Session Description Protocol (SDP)", RFC 4145, 4367 September 2005. 4369 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 4370 Description Protocol", RFC 4566, July 2006. 4372 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 4373 Transport Layer Security (TLS) Protocol in the Session 4374 Description Protocol (SDP)", RFC 4572, July 2006. 4376 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 4377 "Extended RTP Profile for Real-time Transport Control 4378 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 4379 2006. 4381 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 4382 (ICE): A Protocol for Network Address Translator (NAT) 4383 Traversal for Offer/Answer Protocols", RFC 5245, April 4384 2010. 4386 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 4387 Header Extensions", RFC 5285, July 2008. 4389 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 4390 Control Packets on a Single Port", RFC 5761, April 2010. 4392 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 4393 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 4395 [RFC6236] Johansson, I. and K. Jung, "Negotiation of Generic Image 4396 Attributes in the Session Description Protocol (SDP)", 4397 RFC 6236, May 2011. 4399 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 4400 Security Version 1.2", RFC 6347, January 2012. 4402 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 4403 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 4404 September 2012, . 4406 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 4407 Real-time Transport Protocol (SRTP)", RFC 6904, April 4408 2013. 4410 [RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple 4411 Clock Rates in an RTP Session", RFC 7160, 4412 DOI 10.17487/RFC7160, April 2014, 4413 . 4415 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 4416 for the Opus Speech and Audio Codec", RFC 7587, 4417 DOI 10.17487/RFC7587, June 2015, 4418 . 4420 [RFC7850] Nandakumar, S., "Registering Values of the SDP 'proto' 4421 Field for Transporting RTP Media over TCP under Various 4422 RTP Profiles", RFC 7850, DOI 10.17487/RFC7850, April 2016, 4423 . 4425 [RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP 4426 Header Extension for the RTP Control Protocol (RTCP) 4427 Source Description Items", RFC 7941, DOI 10.17487/RFC7941, 4428 August 2016, . 4430 11.2. Informative References 4432 [I-D.ietf-avtext-lrr] 4433 Lennox, J., Hong, D., Uberti, J., Homer, S., and M. 4434 Flodman, "The Layer Refresh Request (LRR) RTCP Feedback 4435 Message", draft-ietf-avtext-lrr-03 (work in progress), 4436 July 2016. 4438 [I-D.ietf-rtcweb-ip-handling] 4439 Uberti, J. and G. Shieh, "WebRTC IP Address Handling 4440 Recommendations", draft-ietf-rtcweb-ip-handling-01 (work 4441 in progress), March 2016. 4443 [I-D.nandakumar-rtcweb-sdp] 4444 Nandakumar, S. and C. Jennings, "SDP for the WebRTC", 4445 draft-nandakumar-rtcweb-sdp-02 (work in progress), July 4446 2013. 4448 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 4449 Comfort Noise (CN)", RFC 3389, September 2002. 4451 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 4452 Jacobson, "RTP: A Transport Protocol for Real-Time 4453 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 4454 July 2003, . 4456 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 4457 Modifiers for RTP Control Protocol (RTCP) Bandwidth", 4458 RFC 3556, July 2003. 4460 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 4461 Protocol Extended Reports (RTCP XR)", RFC 3611, 4462 DOI 10.17487/RFC3611, November 2003, 4463 . 4465 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 4466 Tone Generation in the Session Initiation Protocol (SIP)", 4467 RFC 3960, December 2004. 4469 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 4470 Description Protocol (SDP) Security Descriptions for Media 4471 Streams", RFC 4568, July 2006. 4473 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 4474 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 4475 July 2006. 4477 [RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF 4478 Digits, Telephony Tones, and Telephony Signals", RFC 4733, 4479 DOI 10.17487/RFC4733, December 2006, 4480 . 4482 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 4483 "Codec Control Messages in the RTP Audio-Visual Profile 4484 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 4485 February 2008, . 4487 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 4488 Real-Time Transport Control Protocol (RTCP): Opportunities 4489 and Consequences", RFC 5506, April 2009. 4491 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 4492 Media Attributes in the Session Description Protocol 4493 (SDP)", RFC 5576, June 2009. 4495 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 4496 for Establishing a Secure Real-time Transport Protocol 4497 (SRTP) Security Context Using Datagram Transport Layer 4498 Security (DTLS)", RFC 5763, May 2010. 4500 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 4501 Security (DTLS) Extension to Establish Keys for the Secure 4502 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 4504 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 4505 Transport Protocol (RTP) Header Extension for Client-to- 4506 Mixer Audio Level Indication", RFC 6464, 4507 DOI 10.17487/RFC6464, December 2011, 4508 . 4510 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 4511 "TCP Candidates with Interactive Connectivity 4512 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 4513 March 2012, . 4515 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 4516 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 4517 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 4518 DOI 10.17487/RFC7656, November 2015, 4519 . 4521 [TS26.114] 4522 3GPP TS 26.114 V12.8.0, "3rd Generation Partnership 4523 Project; Technical Specification Group Services and System 4524 Aspects; IP Multimedia Subsystem (IMS); Multimedia 4525 Telephony; Media handling and interaction (Release 12)", 4526 December 2014, . 4528 [W3C.WD-webrtc-20140617] 4529 Bergkvist, A., Burnett, D., Narayanan, A., and C. 4530 Jennings, "WebRTC 1.0: Real-time Communication Between 4531 Browsers", World Wide Web Consortium WD WD-webrtc- 4532 20140617, June 2014, 4533 . 4535 Appendix A. Appendix A 4537 For the syntax validation performed in Section 5.7, the following 4538 list of ABNF definitions is used: 4540 +-----------------------+-------------------------------------------+ 4541 | Attribute | Reference | 4542 +-----------------------+-------------------------------------------+ 4543 | ptime | [RFC4566] Section 9 | 4544 | maxptime | [RFC4566] Section 9 | 4545 | rtpmap | [RFC4566] Section 9 | 4546 | recvonly | [RFC4566] Section 9 | 4547 | sendrecv | [RFC4566] Section 9 | 4548 | sendonly | [RFC4566] Section 9 | 4549 | inactive | [RFC4566] Section 9 | 4550 | framerate | [RFC4566] Section 9 | 4551 | fmtp | [RFC4566] Section 9 | 4552 | quality | [RFC4566] Section 9 | 4553 | rtcp | [RFC3605] Section 2.1 | 4554 | setup | [RFC4145] Sections 3, 4, and 5 | 4555 | connection | [RFC4145] Sections 3, 4, and 5 | 4556 | fingerprint | [RFC4572] Section 5 | 4557 | rtcp-fb | [RFC4585] Section 4.2 | 4558 | candidate | [RFC5245] Section 15.1 | 4559 | remote-candidates | [RFC5245] Section 15.2 | 4560 | ice-lite | [RFC5245] Section 15.3 | 4561 | ice-ufrag | [RFC5245] Section 15.4 | 4562 | ice-pwd | [RFC5245] Section 15.4 | 4563 | ice-options | [RFC5245] Section 15.5 | 4564 | extmap | [RFC5285] Section 7 | 4565 | mid | [RFC5888] Section 4 and 5 | 4566 | group | [RFC5888] Section 4 and 5 | 4567 | imageattr | [RFC6236] Section 3.1 | 4568 | extmap (encrypt | [RFC6904] Section 4 | 4569 | option) | | 4570 | msid | [I-D.ietf-mmusic-msid] Section 2 | 4571 | rid | [I-D.ietf-mmusic-rid] Section 10 | 4572 | simulcast | [I-D.ietf-mmusic-sdp-simulcast]Section | 4573 | | 6.1 | 4574 | dtls-id | [I-D.ietf-mmusic-dtls-sdp]Section 4 | 4575 +-----------------------+-------------------------------------------+ 4577 Table 1: SDP ABNF References 4579 Appendix B. Appendix B 4581 The following text is meant to completely replace section 4582 "Associating RTP/RTCP Streams With Correct SDP Media Description" of 4583 [I-D.ietf-mmusic-sdp-bundle-negotiation]. 4585 As described in [RFC3550], RTP packets are associated with RTP 4586 streams [RFC7656]. Each RTP stream is identified by an SSRC value, 4587 and each RTP packet includes an SSRC field that is used to associate 4588 the packet with the correct RTP stream. RTCP packets also use SSRCs 4589 to identify which RTP streams the packet relates to. However, a RTCP 4590 packet can contain multiple SSRC fields, in the course of providing 4591 feedback or reports on different RTP streams, and therefore can be 4592 associated with multiple such streams. 4594 In order to be able to process received RTP/RTCP packets correctly, 4595 it must be possible to associate an RTP stream with the correct "m=" 4596 line, as the "m=" line and SDP attributes associated with the "m=" 4597 line contain information needed to process the packets. 4599 As all RTP streams associated with a BUNDLE group use the same 4600 address:port combination for sending and receiving RTP/RTCP packets, 4601 the local address:port combination cannot be used to associate an RTP 4602 stream with the correct "m=" line. In addition, multiple RTP streams 4603 might be associated with the same "m=" line. 4605 An offerer and answerer can inform each other which SSRC values they 4606 will use for an RTP stream by using the SDP 'ssrc' attribute 4607 [RFC5576]. However, an offerer will not know which SSRC values the 4608 answerer will use until the offerer has received the answer providing 4609 that information. Due to this, before the offerer has received the 4610 answer, the offerer will not be able to associate an RTP stream with 4611 the correct "m=" line using the SSRC value associated with the RTP 4612 stream. In addition, the offerer and answerer may start using new 4613 SSRC values mid-session, without informing each other using the SDP 4614 'ssrc' attribute. 4616 In order for an offerer and answerer to always be able to associate 4617 an RTP stream with the correct "m=" line, the offerer and answerer 4618 using the BUNDLE extension MUST support the mechanism defined in 4619 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 14, where the 4620 offerer and answerer insert the identification-tag associated with an 4621 "m=" line (provided by the remote peer) into RTP and RTCP packets 4622 associated with a BUNDLE group. 4624 When using this mechanism, the mapping from an SSRC to an 4625 identification-tag is carried in RTP header extensions or RTCP SDES 4626 packets, as specified in [I-D.ietf-mmusic-sdp-bundle-negotiation], 4627 Section 14). Since a compound RTCP packet can contain multiple RTCP 4628 SDES packets, and each RTCP SDES packet can contain multiple chunks, 4629 a single RTCP packet can contain several SSRC to identification-tag 4630 mappings. The offerer and answerer maintain tables used for routing 4631 that are updated each time an RTP/RTCP packet contains new 4632 information that affects how packets should be routed. 4634 However, some implementations of 4635 [I-D.ietf-mmusic-sdp-bundle-negotiation] may not include this 4636 identification-tag in their RTP and RTCP traffic when using BUNDLE, 4637 and instead use a payload type based mechanism for demuxing. In this 4638 situation, each "m=" line MUST use unique payload type values, in 4639 order for the payload type to be a reliable indicator of the relevant 4640 "m=" line for the RTP stream. 4642 Applications can implement RTP stacks in many different ways. The 4643 algorithm below details one way that demultiplexing can be 4644 accomplished, but is not meant to be prescriptive about exactly how 4645 an RTP stack needs to be implemented. Applications MAY use any 4646 algorithm that achieves equivalent results to those described in the 4647 algorithm below. 4649 To prepare for demultiplexing RTP/RTCP packets to the correct "m=" 4650 line, the following steps MUST be followed for each BUNDLE group. 4652 Construct a table mapping MID to "m=" line for each "m=" line in 4653 this BUNDLE group. Note that an "m=" line may only have one MID. 4655 Construct a table mapping incoming SSRC to "m=" line for each "m=" 4656 line in this BUNDLE group and for each SSRC configured for 4657 receiving in that "m=" line. 4659 Construct a table mapping outgoing SSRC to "m=line" for each "m=" 4660 line in this BUNDLE group and for each SSRC configured for sending 4661 in that "m=" line. 4663 Construct a table mapping payload type to "m=" line for each "m=" 4664 line in the BUNDLE group and for each payload type configured for 4665 receiving in that "m=" line. If any payload type is configured 4666 for receiving in more than one "m=" line in the BUNDLE group, do 4667 not it include it in the table, as it cannot be used to uniquely 4668 identify a "m=" line. 4670 Note that for each of these tables, there can only be one mapping 4671 for any given key (MID, SSRC, or PT). In other words, the tables 4672 are not multimaps. 4674 As "m=" lines are added or removed from the BUNDLE groups, or their 4675 configurations are changed, the tables above MUST also be updated. 4677 For each RTP packet received, the following steps MUST be followed to 4678 route the packet to the correct "m=" section within a BUNDLE group. 4679 Note that the phrase 'deliver a packet to the "m=" line' means to 4680 further process the packet as would normally happen with RTP/RTCP, if 4681 it were received on a transport associated with that "m=" line 4682 outside of a BUNDLE group (i.e., if the "m=" line were not BUNDLEd), 4683 including dropping an RTP packet if the packet's PT does not match 4684 any PT in the "m=" line. 4686 If the packet has a MID, and that MID is not in the table mapping 4687 MID to "m=" line, drop the packet and stop. 4689 If the packet has a MID, and the packet's extended sequence number 4690 is greater than that of the last MID update, as discussed in 4691 [RFC7941], Section 4.2.6, update the incoming SSRC mapping table 4692 to include an entry that maps the packet's SSRC to the "m=" line 4693 for that MID. 4695 If the packet's SSRC is in the incoming SSRC mapping table, check 4696 that the packet's PT matches a PT included on the associated "m=" 4697 line. If so, route the packet to that associated "m=" line and 4698 stop; otherwise drop the packet and stop. 4700 If the packet's payload type is in the payload type table, update 4701 the the incoming SSRC mapping table to include an entry that maps 4702 the packet's SSRC to the "m=" line for that payload type. In 4703 addition, route the packet to the associated "m=" line and stop. 4705 Otherwise, drop the packet. 4707 For each RTCP packet received (including each RTCP packet that is 4708 part of a compound RTCP packet), the packet MUST be routed to the 4709 "m=" line for the RTP streams it contains information about. This 4710 routing is type-dependent, as each kind of RTCP packet has its own 4711 mechanism for associating it with the relevant RTP streams. 4713 Packets for which no appropriate "m=" line can be identified (i.e., 4714 for unknown RTP streams) are not relevant in the context of this 4715 algorithm and MAY be dropped. This situation may occur with certain 4716 multiparty RTP topologies. 4718 Rules for handling the various types of RTCP packets are explained 4719 below. 4721 If the packet is of type SDES, for each chunk in the packet whose 4722 SSRC is found in the incoming SSRC table, deliver a copy of the 4723 packet to the "m=" line associated with that SSRC. In addition, 4724 for any SDES MID items contained in these chunks, if the MID is 4725 found in the table mapping MID to "m=" line, update the incoming 4726 SSRC table to include an entry that maps the chunk's SSRC to the 4727 "m=" line associated with that MID, unless the packet is older 4728 than the packet that most recently updated the mapping for this 4729 SSRC, as discussed in [RFC7941], Section 4.2.6. 4731 Note that if an SDES packet is received as part of a compound RTCP 4732 packet, the SSRC to "m=" line mapping may not exist until the SDES 4733 packet is handled (e.g., in the case where RTCP for a source is 4734 received before any RTP packets). Therefore, when processing a 4735 compound packet, any contained SDES packet MUST be handled first. 4737 If the packet is of type BYE, it indicates that the RTP streams 4738 referenced in the packet are ending. Therefore, for each SSRC 4739 indicated in the packet that is found in the incoming SSRC table, 4740 first deliver a copy of the packet to the "m=" line associated 4741 with that SSRC, but then remove the entry for that SSRC from the 4742 incoming SSRC table. 4744 If the packet is of type SR or RR, for each report block in the 4745 report whose "SSRC of source" is found in the outgoing SSRC table, 4746 deliver a copy of the RTCP packet to the "m=" line associated with 4747 that SSRC. In addition, if the packet is of type SR, and the 4748 sender SSRC for the packet is found in the incoming SSRC table, 4749 deliver a copy of the packet to the "m=" line associated with that 4750 SSRC. 4752 If the implementation supports RTCP XR and the packet is of type 4753 XR, as defined in [RFC3611], for each report block in the report 4754 whose "SSRC of source" is is found in the outgoing SSRC table, 4755 deliver a copy of the RTCP packet to the "m=" line associated with 4756 that SSRC. In addition, if the sender SSRC for the packet is 4757 found in the incoming SSRC table, deliver a copy of the packet to 4758 the "m=" line associated with that SSRC. 4760 If the packet is a feedback message of type RTPFB or PSFB, as 4761 defined in [RFC4585], it will contain a media source SSRC, and 4762 this SSRC is used for routing certain subtypes of feedback 4763 messages. However, several subtypes of PSFB messages include 4764 target SSRC(s) in a section called Feedback Control Information 4765 (FCI). For these messages, the target SSRC(s) are used for 4766 routing. 4768 If the packet is a feedback message that does not include target 4769 SSRCs in its FCI section, and the media source SSRC is found in 4770 the outgoing SSRC table, deliver the packet to the "m=" line 4771 associated with that SSRC. RTPFB and PSFB types that are handled 4772 in this way include: 4774 Generic NACK: [RFC4585] (PT=RTPFB, FMT=1). 4776 Picture Loss Indication (PLI): [RFC4585] (PT=PSFB, FMT=1). 4778 Slice Loss Indication (SLI): [RFC4585] (PT=PSFB, FMT=2). 4780 Reference Picture Selection Indication (RPSI): [RFC4585] 4781 (PT=PSFB, FMT=3). 4783 If the packet is a feedback message that does include target 4784 SSRC(s) in its FCI section, it can either be a request or a 4785 notification. Requests reference a RTP stream that is being sent 4786 by the message recipient, whereas notifications are responses to 4787 an earlier request, and therefore reference a RTP stream that is 4788 being received by the message recipient. 4790 If the packet is a feedback request that includes target SSRC(s), 4791 for each target SSRC that is found in the outgoing SSRC table, 4792 deliver a copy of the RTCP packet to the "m=" line associated with 4793 that SSRC. PSFB types that are handled in this way include: 4795 Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). 4797 Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, 4798 FMT=5). 4800 H.271 Video Back Channel Message (VBCM): [RFC5104] 4801 (PT=PSFB, FMT=7). 4803 Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, 4804 FMT=TBD). 4806 If the packet is a feedback notification that include target 4807 SSRC(s), for each target SSRC that is found in the incoming SSRC 4808 table, deliver a copy of the RTCP packet to the "m=" line 4809 associated with that SSRC. PSFB types that are handled in this 4810 way include: 4812 Temporal-Spatial Trade-off Notification (TSTN): [RF 4813 C5104] (PT=PSFB, FMT=6). This message is a notification in 4814 response to a prior TSTR. 4816 If the packet is of type APP, the only routing information 4817 included is the source of the packet, and therefore the packet 4818 could be related to any existing "m=" line. Accordingly, deliver 4819 a copy of the packet to each "m=" line. 4821 Appendix C. Change log 4823 Note: This section will be removed by RFC Editor before publication. 4825 Changes in draft-19: 4827 o Examples are now machine-generated for correctness, and use IETF- 4828 approved example IP addresses. 4830 o Add early transport warmup example, and add missing attributes to 4831 existing examples. 4833 o Only send "a=rtcp-mux-only" and "a=bundle-only" on new m= 4834 sections. 4836 o Update references. 4838 o Add coverage of a=identity. 4840 o Explain the lipsync group algorithm more thoroughly. 4842 o Remove unnecessary list of MTI specs. 4844 o Allow codecs which weren't offered to appear in answers and which 4845 weren't selected to appear in subsequent offers. 4847 o Codec preferences now are applied on both initial and subsequent 4848 offers and answers. 4850 o Clarify a=msid handling for recvonly m= sections. 4852 o Clarify behavior of attributes for bundle-only data channels. 4854 o Allow media attributes to appear in data m= sections when all the 4855 media m= sections are bundle-only. 4857 o Use consistent terminology for JSEP implementations. 4859 o Describe how to handle failed API calls. 4861 o Some cleanup on routing rules. 4863 Changes in draft-18: 4865 o Update demux algorithm and move it to an appendix in preparation 4866 for merging it into BUNDLE. 4868 o Clarify why we can't handle an incoming offer to send simulcast. 4870 o Expand IceCandidate object text. 4872 o Further document use of ICE candidate pool. 4874 o Document removeTrack. 4876 o Update requirements to only accept the last generated offer/answer 4877 as an argument to setLocalDescription. 4879 o Allow round pixels. 4881 o Fix code around default timing when AVPF is not specified. 4883 o Clean up terminology around m= line and m=section. 4885 o Provide a more realistic example for minimum decoder capabilities. 4887 o Document behavior when rtcp-mux policy is require but rtcp-mux 4888 attribute not provided. 4890 o Expanded discussion of RtpSender and RtpReceiver. 4892 o Add RtpTransceiver.currentDirection and document setDirection. 4894 o Require imageattr x=0, y=0 to indicate that there are no valid 4895 resolutions. 4897 o Require a privacy-preserving MID/RID construction. 4899 o Require support for RFC 3556 bandwidth modifiers. 4901 o Update maxptime description. 4903 o Note that endpoints may encounter extra codecs in answers and 4904 subsequent offers from non-JSEP peers. 4906 o Update references. 4908 Changes in draft-17: 4910 o Split createOffer and createAnswer sections to clearly indicate 4911 attributes which always appear and which only appear when not 4912 bundled into another m= section. 4914 o Add descriptions of RtpTransceiver methods. 4916 o Describe how to process RTCP feedback attributes. 4918 o Clarify transceiver directions and their interaction with 3264. 4920 o Describe setCodecPreferences. 4922 o Update RTP demux algorithm. Include RTCP. 4924 o Update requirements for when a=rtcp is included, limiting to cases 4925 where it is needed for backward compatibility. 4927 o Clarify SAR handling. 4929 o Updated addTrack matching algorithm. 4931 o Remove a=ssrc requirements. 4933 o Handle a=setup in reoffers. 4935 o Discuss how RTX/FEC should be handled. 4937 o Discuss how telephone-event should be handled. 4939 o Discuss how CN/DTX should be handled. 4941 o Add missing references to ABNF table. 4943 Changes in draft-16: 4945 o Update addIceCandidate to indicate ICE generation and allow per-m= 4946 section end-of-candidates. 4948 o Update fingerprint handling to use draft-ietf-mmusic-4572-update. 4950 o Update text around SDP processing of RTP header extensions and 4951 payload formats. 4953 o Add sections on simulcast, addTransceiver, and createDataChannel. 4955 o Clarify text to ensure that the session ID is a positive 63 bit 4956 integer. 4958 o Clarify SDP processing for direction indication. 4960 o Describe SDP processing for rtcp-mux-only. 4962 o Specify how SDP session version in o= line. 4964 o Require that when doing an re-offer, the capabilities of the new 4965 session are mostly required to be a subset of the previously 4966 negotiated session. 4968 o Clarified ICE restart interaction with bundle-only. 4970 o Remove support for changing SDP before calling 4971 setLocalDescription. 4973 o Specify algorithm for demuxing RTP based on MID, PT, and SSRC. 4975 o Clarify rules for rejecting m= lines when bundle policy is 4976 balanced or max-bundle. 4978 Changes in draft-15: 4980 o Clarify text around codecs offered in subsequent transactions to 4981 refer to what's been negotiated. 4983 o Rewrite LS handling text to indicate edge cases and that we're 4984 living with them. 4986 o Require that answerer reject m= lines when there are no codecs in 4987 common. 4989 o Enforce max-bundle on offer processing. 4991 o Fix TIAS formula to handle bits vs. kilobits. 4993 o Describe addTrack algorithm. 4995 o Clean up references. 4997 Changes in draft-14: 4999 o Added discussion of RtpTransceivers + RtpSenders + RtpReceivers, 5000 and how they interact with createOffer/createAnswer. 5002 o Removed obsolete OfferToReceiveX options. 5004 o Explained how addIceCandidate can be used for end-of-candidates. 5006 Changes in draft-13: 5008 o Clarified which SDP lines can be ignored. 5010 o Clarified how to handle various received attributes. 5012 o Revised how attributes should be generated for bundled m= lines. 5014 o Remove unused references. 5016 o Remove text advocating use of unilateral PTs. 5018 o Trigger an ICE restart even if the ICE candidate policy is being 5019 made more strict. 5021 o Remove the 'public' ICE candidate policy. 5023 o Move open issues into GitHub issues. 5025 o Split local/remote description accessors into current/pending. 5027 o Clarify a=imageattr handling. 5029 o Add more detail on VoiceActivityDetection handling. 5031 o Reference draft-shieh-rtcweb-ip-handling. 5033 o Make it clear when an ICE restart should occur. 5035 o Resolve changes needed in references. 5037 o Remove MSID semantics. 5039 o ice-options are now at session level. 5041 o Default RTCP mux policy is now 'require'. 5043 Changes in draft-12: 5045 o Filled in sections on applying local and remote descriptions. 5047 o Discussed downscaling and upscaling to fulfill imageattr 5048 requirements. 5050 o Updated what SDP can be modified by the application. 5052 o Updated to latest datachannel SDP. 5054 o Allowed multiple fingerprint lines. 5056 o Switched back to IPv4 for dummy candidates. 5058 o Added additional clarity on ICE default candidates. 5060 Changes in draft-11: 5062 o Clarified handling of RTP CNAMEs. 5064 o Updated what SDP lines should be processed or ignored. 5066 o Specified how a=imageattr should be used. 5068 Changes in draft-10: 5070 o Described video size negotiation with imageattr. 5072 o Clarified rejection of sections that do not have mux-only. 5074 o Add handling of LS groups 5076 Changes in draft-09: 5078 o Don't return null for {local,remote}Description after close(). 5080 o Changed TCP/TLS to UDP/DTLS in RTP profile names. 5082 o Separate out bundle and mux policy. 5084 o Added specific references to FEC mechanisms. 5086 o Added canTrickle mechanism. 5088 o Added section on subsequent answers and, answer options. 5090 o Added text defining set{Local,Remote}Description behavior. 5092 Changes in draft-08: 5094 o Added new example section and removed old examples in appendix. 5096 o Fixed field handling. 5098 o Added text describing a=rtcp attribute. 5100 o Reworked handling of OfferToReceiveAudio and OfferToReceiveVideo 5101 per discussion at IETF 90. 5103 o Reworked trickle ICE handling and its impact on m= and c= lines 5104 per discussion at interim. 5106 o Added max-bundle-and-rtcp-mux policy. 5108 o Added description of maxptime handling. 5110 o Updated ICE candidate pool default to 0. 5112 o Resolved open issues around AppID/receiver-ID. 5114 o Reworked and expanded how changes to the ICE configuration are 5115 handled. 5117 o Some reference updates. 5119 o Editorial clarification. 5121 Changes in draft-07: 5123 o Expanded discussion of VAD and Opus DTX. 5125 o Added a security considerations section. 5127 o Rewrote the section on modifying SDP to require implementations to 5128 clearly indicate whether any given modification is allowed. 5130 o Clarified impact of IceRestart on CreateOffer in local-offer 5131 state. 5133 o Guidance on whether attributes should be defined at the media 5134 level or the session level. 5136 o Renamed "default" bundle policy to "balanced". 5138 o Removed default ICE candidate pool size and clarify how it works. 5140 o Defined a canonical order for assignment of MSTs to m= lines. 5142 o Removed discussion of rehydration. 5144 o Added Eric Rescorla as a draft editor. 5146 o Cleaned up references. 5148 o Editorial cleanup 5150 Changes in draft-06: 5152 o Reworked handling of m= line recycling. 5154 o Added handling of BUNDLE and bundle-only. 5156 o Clarified handling of rollback. 5158 o Added text describing the ICE Candidate Pool and its behavior. 5160 o Allowed OfferToReceiveX to create multiple recvonly m= sections. 5162 Changes in draft-05: 5164 o Fixed several issues identified in the createOffer/Answer sections 5165 during document review. 5167 o Updated references. 5169 Changes in draft-04: 5171 o Filled in sections on createOffer and createAnswer. 5173 o Added SDP examples. 5175 o Fixed references. 5177 Changes in draft-03: 5179 o Added text describing relationship to W3C specification 5181 Changes in draft-02: 5183 o Converted from nroff 5185 o Removed comparisons to old approaches abandoned by the working 5186 group 5188 o Removed stuff that has moved to W3C specification 5190 o Align SDP handling with W3C draft 5192 o Clarified section on forking. 5194 Changes in draft-01: 5196 o Added diagrams for architecture and state machine. 5198 o Added sections on forking and rehydration. 5200 o Clarified meaning of "pranswer" and "answer". 5202 o Reworked how ICE restarts and media directions are controlled. 5204 o Added list of parameters that can be changed in a description. 5206 o Updated suggested API and examples to match latest thinking. 5208 o Suggested API and examples have been moved to an appendix. 5210 Changes in draft -00: 5212 o Migrated from draft-uberti-rtcweb-jsep-02. 5214 Authors' Addresses 5216 Justin Uberti 5217 Google 5218 747 6th St S 5219 Kirkland, WA 98033 5220 USA 5222 Email: justin@uberti.name 5224 Cullen Jennings 5225 Cisco 5226 400 3rd Avenue SW 5227 Calgary, AB T2P 4H2 5228 Canada 5230 Email: fluffy@iii.ca 5232 Eric Rescorla (editor) 5233 Mozilla 5234 331 Evelyn Ave 5235 Mountain View, CA 94041 5236 USA 5238 Email: ekr@rtfm.com