idnits 2.17.1 draft-ietf-rtcweb-jsep-09.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 are 44 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 20 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- 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 -- The document date (March 9, 2015) is 3329 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) == Missing Reference: 'RFC1918' is mentioned on line 686, but not defined == Missing Reference: 'RFC4787' is mentioned on line 689, but not defined == Unused Reference: 'RFC5124' is defined on line 3107, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-msid-01 == 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 (-02) exists of draft-ietf-mmusic-trickle-ice-00 == Outdated reference: A later version (-11) exists of draft-ietf-rtcweb-audio-02 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-04 == 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 -- No information found for draft-nandakumar-mmusic-proto-iana-registration - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.nandakumar-mmusic-proto-iana-registration' ** 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 (-08) exists of draft-nandakumar-rtcweb-sdp-02 Summary: 5 errors (**), 0 flaws (~~), 19 warnings (==), 4 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 10, 2015 Cisco 6 E. Rescorla, Ed. 7 Mozilla 8 March 9, 2015 10 Javascript Session Establishment Protocol 11 draft-ietf-rtcweb-jsep-09 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 10, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . 6 61 3.3. Session Description Format . . . . . . . . . . . . . . . 10 62 3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4.1. ICE Gathering Overview . . . . . . . . . . . . . . . 10 64 3.4.2. ICE Candidate Trickling . . . . . . . . . . . . . . . 11 65 3.4.2.1. ICE Candidate Format . . . . . . . . . . . . . . 11 66 3.4.3. ICE Candidate Policy . . . . . . . . . . . . . . . . 12 67 3.4.4. ICE Candidate Pool . . . . . . . . . . . . . . . . . 13 68 3.5. Interactions With Forking . . . . . . . . . . . . . . . . 13 69 3.5.1. Sequential Forking . . . . . . . . . . . . . . . . . 14 70 3.5.2. Parallel Forking . . . . . . . . . . . . . . . . . . 14 71 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 15 74 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 17 75 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 18 76 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 19 77 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 20 78 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 20 79 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 21 80 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 21 81 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 22 82 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 22 83 4.1.9. canTrickleIceCandidates . . . . . . . . . . . . . . . 22 84 4.1.10. setConfiguration . . . . . . . . . . . . . . . . . . 23 85 4.1.11. addIceCandidate . . . . . . . . . . . . . . . . . . . 24 86 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 24 87 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 24 88 5.1.1. Implementation Requirements . . . . . . . . . . . . . 24 89 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 26 90 5.1.3. Profile Names and Interoperability . . . . . . . . . 26 91 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 27 92 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 27 93 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 32 94 5.2.3. Options Handling . . . . . . . . . . . . . . . . . . 35 95 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 35 96 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 35 97 5.2.3.3. IceRestart . . . . . . . . . . . . . . . . . . . 36 98 5.2.3.4. VoiceActivityDetection . . . . . . . . . . . . . 36 99 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 36 100 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 36 101 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 41 102 5.3.3. Options Handling . . . . . . . . . . . . . . . . . . 42 103 5.3.3.1. VoiceActivityDetection . . . . . . . . . . . . . 42 104 5.4. Processing a Local Description . . . . . . . . . . . . . 42 105 5.5. Processing a Remote Description . . . . . . . . . . . . . 43 106 5.6. Parsing a Session Description . . . . . . . . . . . . . . 43 107 5.6.1. Session-Level Parsing . . . . . . . . . . . . . . . . 44 108 5.6.2. Media Section Parsing . . . . . . . . . . . . . . . . 45 109 5.6.3. Semantics Verification . . . . . . . . . . . . . . . 47 110 5.7. Applying a Local Description . . . . . . . . . . . . . . 47 111 5.8. Applying a Remote Description . . . . . . . . . . . . . . 48 112 5.9. Applying an Answer . . . . . . . . . . . . . . . . . . . 48 113 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 48 114 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 49 115 7.1. Simple Example . . . . . . . . . . . . . . . . . . . . . 50 116 7.2. Normal Examples . . . . . . . . . . . . . . . . . . . . . 54 117 8. Security Considerations . . . . . . . . . . . . . . . . . . . 65 118 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 119 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65 120 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 121 11.1. Normative References . . . . . . . . . . . . . . . . . . 66 122 11.2. Informative References . . . . . . . . . . . . . . . . . 69 123 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 70 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 126 1. Introduction 128 This document describes how the W3C WEBRTC RTCPeerConnection 129 interface[W3C.WD-webrtc-20140617] is used to control the setup, 130 management and teardown of a multimedia session. 132 1.1. General Design of JSEP 134 The thinking behind WebRTC call setup has been to fully specify and 135 control the media plane, but to leave the signaling plane up to the 136 application as much as possible. The rationale is that different 137 applications may prefer to use different protocols, such as the 138 existing SIP or Jingle call signaling protocols, or something custom 139 to the particular application, perhaps for a novel use case. In this 140 approach, the key information that needs to be exchanged is the 141 multimedia session description, which specifies the necessary 142 transport and media configuration information necessary to establish 143 the media plane. 145 With these considerations in mind, this document describes the 146 Javascript Session Establishment Protocol (JSEP) that allows for full 147 control of the signaling state machine from Javascript. JSEP removes 148 the browser almost entirely from the core signaling flow, which is 149 instead handled by the Javascript making use of two interfaces: (1) 150 passing in local and remote session descriptions and (2) interacting 151 with the ICE state machine. 153 In this document, the use of JSEP is described as if it always occurs 154 between two browsers. Note though in many cases it will actually be 155 between a browser and some kind of server, such as a gateway or MCU. 156 This distinction is invisible to the browser; it just follows the 157 instructions it is given via the API. 159 JSEP's handling of session descriptions is simple and 160 straightforward. Whenever an offer/answer exchange is needed, the 161 initiating side creates an offer by calling a createOffer() API. The 162 application optionally modifies that offer, and then uses it to set 163 up its local config via the setLocalDescription() API. The offer is 164 then sent off to the remote side over its preferred signaling 165 mechanism (e.g., WebSockets); upon receipt of that offer, the remote 166 party installs it using the setRemoteDescription() API. 168 To complete the offer/answer exchange, the remote party uses the 169 createAnswer() API to generate an appropriate answer, applies it 170 using the setLocalDescription() API, and sends the answer back to the 171 initiator over the signaling channel. When the initiator gets that 172 answer, it installs it using the setRemoteDescription() API, and 173 initial setup is complete. This process can be repeated for 174 additional offer/answer exchanges. 176 Regarding ICE [RFC5245], JSEP decouples the ICE state machine from 177 the overall signaling state machine, as the ICE state machine must 178 remain in the browser, because only the browser has the necessary 179 knowledge of candidates and other transport info. Performing this 180 separation also provides additional flexibility; in protocols that 181 decouple session descriptions from transport, such as Jingle, the 182 session description can be sent immediately and the transport 183 information can be sent when available. In protocols that don't, 184 such as SIP, the information can be used in the aggregated form. 185 Sending transport information separately can allow for faster ICE and 186 DTLS startup, since ICE checks can start as soon as any transport 187 information is available rather than waiting for all of it. 189 Through its abstraction of signaling, the JSEP approach does require 190 the application to be aware of the signaling process. While the 191 application does not need to understand the contents of session 192 descriptions to set up a call, the application must call the right 193 APIs at the right times, convert the session descriptions and ICE 194 information into the defined messages of its chosen signaling 195 protocol, and perform the reverse conversion on the messages it 196 receives from the other side. 198 One way to mitigate this is to provide a Javascript library that 199 hides this complexity from the developer; said library would 200 implement a given signaling protocol along with its state machine and 201 serialization code, presenting a higher level call-oriented interface 202 to the application developer. For example, libraries exist to adapt 203 the JSEP API into an API suitable for a SIP or XMPP. Thus, JSEP 204 provides greater control for the experienced developer without 205 forcing any additional complexity on the novice developer. 207 1.2. Other Approaches Considered 209 One approach that was considered instead of JSEP was to include a 210 lightweight signaling protocol. Instead of providing session 211 descriptions to the API, the API would produce and consume messages 212 from this protocol. While providing a more high-level API, this put 213 more control of signaling within the browser, forcing the browser to 214 have to understand and handle concepts like signaling glare. In 215 addition, it prevented the application from driving the state machine 216 to a desired state, as is needed in the page reload case. 218 A second approach that was considered but not chosen was to decouple 219 the management of the media control objects from session 220 descriptions, instead offering APIs that would control each component 221 directly. This was rejected based on a feeling that requiring 222 exposure of this level of complexity to the application programmer 223 would not be beneficial; it would result in an API where even a 224 simple example would require a significant amount of code to 225 orchestrate all the needed interactions, as well as creating a large 226 API surface that needed to be agreed upon and documented. In 227 addition, these API points could be called in any order, resulting in 228 a more complex set of interactions with the media subsystem than the 229 JSEP approach, which specifies how session descriptions are to be 230 evaluated and applied. 232 One variation on JSEP that was considered was to keep the basic 233 session description-oriented API, but to move the mechanism for 234 generating offers and answers out of the browser. Instead of 235 providing createOffer/createAnswer methods within the browser, this 236 approach would instead expose a getCapabilities API which would 237 provide the application with the information it needed in order to 238 generate its own session descriptions. This increases the amount of 239 work that the application needs to do; it needs to know how to 240 generate session descriptions from capabilities, and especially how 241 to generate the correct answer from an arbitrary offer and the 242 supported capabilities. While this could certainly be addressed by 243 using a library like the one mentioned above, it basically forces the 244 use of said library even for a simple example. Providing 245 createOffer/createAnswer avoids this problem, but still allows 246 applications to generate their own offers/answers (to a large extent) 247 if they choose, using the description generated by createOffer as an 248 indication of the browser's capabilities. 250 2. Terminology 252 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 253 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 254 document are to be interpreted as described in [RFC2119]. 256 3. Semantics and Syntax 258 3.1. Signaling Model 260 JSEP does not specify a particular signaling model or state machine, 261 other than the generic need to exchange SDP media descriptions in the 262 fashion described by [RFC3264] (offer/answer) in order for both sides 263 of the session to know how to conduct the session. JSEP provides 264 mechanisms to create offers and answers, as well as to apply them to 265 a session. However, the browser is totally decoupled from the actual 266 mechanism by which these offers and answers are communicated to the 267 remote side, including addressing, retransmission, forking, and glare 268 handling. These issues are left entirely up to the application; the 269 application has complete control over which offers and answers get 270 handed to the browser, and when. 272 +-----------+ +-----------+ 273 | Web App |<--- App-Specific Signaling -->| Web App | 274 +-----------+ +-----------+ 275 ^ ^ 276 | SDP | SDP 277 V V 278 +-----------+ +-----------+ 279 | Browser |<----------- Media ------------>| Browser | 280 +-----------+ +-----------+ 282 Figure 1: JSEP Signaling Model 284 3.2. Session Descriptions and State Machine 286 In order to establish the media plane, the user agent needs specific 287 parameters to indicate what to transmit to the remote side, as well 288 as how to handle the media that is received. These parameters are 289 determined by the exchange of session descriptions in offers and 290 answers, and there are certain details to this process that must be 291 handled in the JSEP APIs. 293 Whether a session description applies to the local side or the remote 294 side affects the meaning of that description. For example, the list 295 of codecs sent to a remote party indicates what the local side is 296 willing to receive, which, when intersected with the set of codecs 297 the remote side supports, specifies what the remote side should send. 298 However, not all parameters follow this rule; for example, the DTLS- 299 SRTP parameters [RFC5763] sent to a remote party indicate what 300 certificate the local side will use in DTLS setup, and thereby what 301 the remote party should expect to receive; the remote party will have 302 to accept these parameters, with no option to choose different 303 values. 305 In addition, various RFCs put different conditions on the format of 306 offers versus answers. For example, an offer may propose an 307 arbitrary number of media streams (i.e. m= sections), but an answer 308 must contain the exact same number as the offer. 310 Lastly, while the exact media parameters are only known only after an 311 offer and an answer have been exchanged, it is possible for the 312 offerer to receive media after they have sent an offer and before 313 they have received an answer. To properly process incoming media in 314 this case, the offerer's media handler must be aware of the details 315 of the offer before the answer arrives. 317 Therefore, in order to handle session descriptions properly, the user 318 agent needs: 320 1. To know if a session description pertains to the local or remote 321 side. 323 2. To know if a session description is an offer or an answer. 325 3. To allow the offer to be specified independently of the answer. 327 JSEP addresses this by adding both setLocalDescription and 328 setRemoteDescription methods and having session description objects 329 contain a type field indicating the type of session description being 330 supplied. This satisfies the requirements listed above for both the 331 offerer, who first calls setLocalDescription(sdp [offer]) and then 332 later setRemoteDescription(sdp [answer]), as well as for the 333 answerer, who first calls setRemoteDescription(sdp [offer]) and then 334 later setLocalDescription(sdp [answer]). 336 JSEP also allows for an answer to be treated as provisional by the 337 application. Provisional answers provide a way for an answerer to 338 communicate initial session parameters back to the offerer, in order 339 to allow the session to begin, while allowing a final answer to be 340 specified later. This concept of a final answer is important to the 341 offer/answer model; when such an answer is received, any extra 342 resources allocated by the caller can be released, now that the exact 343 session configuration is known. These "resources" can include things 344 like extra ICE components, TURN candidates, or video decoders. 345 Provisional answers, on the other hand, do no such deallocation 346 results; as a result, multiple dissimilar provisional answers can be 347 received and applied during call setup. 349 In [RFC3264], the constraint at the signaling level is that only one 350 offer can be outstanding for a given session, but at the media stack 351 level, a new offer can be generated at any point. For example, when 352 using SIP for signaling, if one offer is sent, then cancelled using a 353 SIP CANCEL, another offer can be generated even though no answer was 354 received for the first offer. To support this, the JSEP media layer 355 can provide an offer via the createOffer() method whenever the 356 Javascript application needs one for the signaling. The answerer can 357 send back zero or more provisional answers, and finally end the 358 offer-answer exchange by sending a final answer. The state machine 359 for this is as follows: 361 setRemote(OFFER) setLocal(PRANSWER) 362 /-----\ /-----\ 363 | | | | 364 v | v | 365 +---------------+ | +---------------+ | 366 | |----/ | |----/ 367 | | setLocal(PRANSWER) | | 368 | Remote-Offer |------------------- >| Local-Pranswer| 369 | | | | 370 | | | | 371 +---------------+ +---------------+ 372 ^ | | 373 | | setLocal(ANSWER) | 374 setRemote(OFFER) | | 375 | V setLocal(ANSWER) | 376 +---------------+ | 377 | | | 378 | |<---------------------------+ 379 | Stable | 380 | |<---------------------------+ 381 | | | 382 +---------------+ setRemote(ANSWER) | 383 ^ | | 384 | | setLocal(OFFER) | 385 setRemote(ANSWER) | | 386 | V | 387 +---------------+ +---------------+ 388 | | | | 389 | | setRemote(PRANSWER) | | 390 | Local-Offer |------------------- >|Remote-Pranswer| 391 | | | | 392 | |----\ | |----\ 393 +---------------+ | +---------------+ | 394 ^ | ^ | 395 | | | | 396 \-----/ \-----/ 397 setLocal(OFFER) setRemote(PRANSWER) 399 Figure 2: JSEP State Machine 401 Aside from these state transitions there is no other difference 402 between the handling of provisional ("pranswer") and final ("answer") 403 answers. 405 3.3. Session Description Format 407 In the WebRTC specification, session descriptions are formatted as 408 SDP messages. While this format is not optimal for manipulation from 409 Javascript, it is widely accepted, and frequently updated with new 410 features. Any alternate encoding of session descriptions would have 411 to keep pace with the changes to SDP, at least until the time that 412 this new encoding eclipsed SDP in popularity. As a result, JSEP 413 currently uses SDP as the internal representation for its session 414 descriptions. 416 However, to simplify Javascript processing, and provide for future 417 flexibility, the SDP syntax is encapsulated within a 418 SessionDescription object, which can be constructed from SDP, and be 419 serialized out to SDP. If future specifications agree on a JSON 420 format for session descriptions, we could easily enable this object 421 to generate and consume that JSON. 423 Other methods may be added to SessionDescription in the future to 424 simplify handling of SessionDescriptions from Javascript. In the 425 meantime, Javascript libraries can be used to perform these 426 manipulations. 428 Note that most applications should be able to treat the 429 SessionDescriptions produced and consumed by these various API calls 430 as opaque blobs; that is, the application will not need to read or 431 change them. The W3C WebRTC API specification will provide 432 appropriate APIs to allow the application to control various session 433 parameters, which will provide the necessary information to the 434 browser about what sort of SessionDescription to produce. 436 3.4. ICE 438 3.4.1. ICE Gathering Overview 440 JSEP gathers ICE candidates as needed by the application. Collection 441 of ICE candidates is referred to as a gathering phase, and this is 442 triggered either by the addition of a new or recycled m= line to the 443 local session description, or new ICE credentials in the description, 444 indicating an ICE restart. Use of new ICE credentials can be 445 triggered explicitly by the application, or implicitly by the browser 446 in response to changes in the ICE configuration. 448 When a new gathering phase starts, the ICE Agent will notify the 449 application that gathering is occurring through an event. Then, when 450 each new ICE candidate becomes available, the ICE Agent will supply 451 it to the application via an additional event; these candidates will 452 also automatically be added to the local session description. 454 Finally, when all candidates have been gathered, an event will be 455 dispatched to signal that the gathering process is complete. 457 Note that gathering phases only gather the candidates needed by 458 new/recycled/restarting m= lines; other m= lines continue to use 459 their existing candidates. 461 3.4.2. ICE Candidate Trickling 463 Candidate trickling is a technique through which a caller may 464 incrementally provide candidates to the callee after the initial 465 offer has been dispatched; the semantics of "Trickle ICE" are defined 466 in [I-D.ietf-mmusic-trickle-ice]. This process allows the callee to 467 begin acting upon the call and setting up the ICE (and perhaps DTLS) 468 connections immediately, without having to wait for the caller to 469 gather all possible candidates. This results in faster media setup 470 in cases where gathering is not performed prior to initiating the 471 call. 473 JSEP supports optional candidate trickling by providing APIs, as 474 described above, that provide control and feedback on the ICE 475 candidate gathering process. Applications that support candidate 476 trickling can send the initial offer immediately and send individual 477 candidates when they get the notified of a new candidate; 478 applications that do not support this feature can simply wait for the 479 indication that gathering is complete, and then create and send their 480 offer, with all the candidates, at this time. 482 Upon receipt of trickled candidates, the receiving application will 483 supply them to its ICE Agent. This triggers the ICE Agent to start 484 using the new remote candidates for connectivity checks. 486 3.4.2.1. ICE Candidate Format 488 As with session descriptions, the syntax of the IceCandidate object 489 provides some abstraction, but can be easily converted to and from 490 the SDP candidate lines. 492 The candidate lines are the only SDP information that is contained 493 within IceCandidate, as they represent the only information needed 494 that is not present in the initial offer (i.e., for trickle 495 candidates). This information is carried with the same syntax as the 496 "candidate-attribute" field defined for ICE. For example: 498 candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host 500 The IceCandidate object also contains fields to indicate which m= 501 line it should be associated with. The m= line can be identified in 502 one of two ways; either by a m= line index, or a MID. The m= line 503 index is a zero-based index, with index N referring to the N+1th m= 504 line in the SDP sent by the entity which sent the IceCandidate. The 505 MID uses the "media stream identification" attribute, as defined in 506 [RFC5888], Section 4, to identify the m= line. JSEP implementations 507 creating an ICE Candidate object MUST populate both of these fields. 508 Implementations receiving an ICE Candidate object MUST use the MID if 509 present, or the m= line index, if not (as it could have come from a 510 non-JSEP endpoint). 512 3.4.3. ICE Candidate Policy 514 Typically, when gathering ICE candidates, the browser will gather all 515 possible forms of initial candidates - host, server reflexive, and 516 relay. However, in certain cases, applications may want to have more 517 specific control over the gathering process, due to privacy or 518 related concerns. For example, one may want to suppress the use of 519 host candidates, to avoid exposing information about the local 520 network, or go as far as only using relay candidates, to leak as 521 little location information as possible (note that these choices come 522 with corresponding operational costs). To accomplish this, the 523 browser MUST allow the application to restrict which ICE candidates 524 are used in a session. In addition, administrators may also wish to 525 control the set of ICE candidates, and so the browser SHOULD also 526 allow control via local policy, with the most restrictive policy 527 prevailing. 529 There may also be cases where the application wants to change which 530 types of candidates are used while the session is active. A prime 531 example is where a callee may initially want to use only relay 532 candidates, to avoid leaking location information to an arbitrary 533 caller, but then change to use all candidates (for lower operational 534 cost) once the user has indicated they want to take the call. For 535 this scenario, the browser MUST allow the candidate policy to be 536 changed in mid-session, subject to the aforementioned interactions 537 with local policy. 539 To administer the ICE candidate policy, the browser will determine 540 the current setting at the start of each gathering phase. Then, 541 during the gathering phase, the browser MUST NOT expose candidates 542 disallowed by the current policy to the application, use them as the 543 source of connectivity checks, or indirectly expose them via other 544 fields, such as the raddr/rport attributes for other ICE candidates. 545 Later, if a different policy is specified by the application, the 546 application can apply it by kicking off a new gathering phase via an 547 ICE restart. 549 3.4.4. ICE Candidate Pool 551 JSEP applications typically inform the browser to begin ICE gathering 552 via the information supplied to setLocalDescription, as this is where 553 the app specifies the number of media streams, and thereby ICE 554 components, for which to gather candidates. However, to accelerate 555 cases where the application knows the number of ICE components to use 556 ahead of time, it may ask the browser to gather a pool of potential 557 ICE candidates to help ensure rapid media setup. 559 When setLocalDescription is eventually called, and the browser goes 560 to gather the needed ICE candidates, it SHOULD start by checking if 561 any candidates are available in the pool. If there are candidates in 562 the pool, they SHOULD be handed to the application immediately via 563 the ICE candidate event. If the pool becomes depleted, either 564 because a larger-than-expected number of ICE components is used, or 565 because the pool has not had enough time to gather candidates, the 566 remaining candidates are gathered as usual. 568 One example of where this concept is useful is an application that 569 expects an incoming call at some point in the future, and wants to 570 minimize the time it takes to establish connectivity, to avoid 571 clipping of initial media. By pre-gathering candidates into the 572 pool, it can exchange and start sending connectivity checks from 573 these candidates almost immediately upon receipt of a call. Note 574 though that by holding on to these pre-gathered candidates, which 575 will be kept alive as long as they may be needed, the application 576 will consume resources on the STUN/TURN servers it is using. 578 3.5. Interactions With Forking 580 Some call signaling systems allow various types of forking where an 581 SDP Offer may be provided to more than one device. For example, SIP 582 [RFC3261] defines both a "Parallel Search" and "Sequential Search". 583 Although these are primarily signaling level issues that are outside 584 the scope of JSEP, they do have some impact on the configuration of 585 the media plane that is relevant. When forking happens at the 586 signaling layer, the Javascript application responsible for the 587 signaling needs to make the decisions about what media should be sent 588 or received at any point of time, as well as which remote endpoint it 589 should communicate with; JSEP is used to make sure the media engine 590 can make the RTP and media perform as required by the application. 591 The basic operations that the applications can have the media engine 592 do are: 594 o Start exchanging media with a given remote peer, but keep all the 595 resources reserved in the offer. 597 o Start exchanging media with a given remote peer, and free any 598 resources in the offer that are not being used. 600 3.5.1. Sequential Forking 602 Sequential forking involves a call being dispatched to multiple 603 remote callees, where each callee can accept the call, but only one 604 active session ever exists at a time; no mixing of received media is 605 performed. 607 JSEP handles sequential forking well, allowing the application to 608 easily control the policy for selecting the desired remote endpoint. 609 When an answer arrives from one of the callees, the application can 610 choose to apply it either as a provisional answer, leaving open the 611 possibility of using a different answer in the future, or apply it as 612 a final answer, ending the setup flow. 614 In a "first-one-wins" situation, the first answer will be applied as 615 a final answer, and the application will reject any subsequent 616 answers. In SIP parlance, this would be ACK + BYE. 618 In a "last-one-wins" situation, all answers would be applied as 619 provisional answers, and any previous call leg will be terminated. 620 At some point, the application will end the setup process, perhaps 621 with a timer; at this point, the application could reapply the 622 existing remote description as a final answer. 624 3.5.2. Parallel Forking 626 Parallel forking involves a call being dispatched to multiple remote 627 callees, where each callee can accept the call, and multiple 628 simultaneous active signaling sessions can be established as a 629 result. If multiple callees send media at the same time, the 630 possibilities for handling this are described in Section 3.1 of 631 [RFC3960]. Most SIP devices today only support exchanging media with 632 a single device at a time, and do not try to mix multiple early media 633 audio sources, as that could result in a confusing situation. For 634 example, consider having a European ringback tone mixed together with 635 the North American ringback tone - the resulting sound would not be 636 like either tone, and would confuse the user. If the signaling 637 application wishes to only exchange media with one of the remote 638 endpoints at a time, then from a media engine point of view, this is 639 exactly like the sequential forking case. 641 In the parallel forking case where the Javascript application wishes 642 to simultaneously exchange media with multiple peers, the flow is 643 slightly more complex, but the Javascript application can follow the 644 strategy that [RFC3960] describes using UPDATE. The UPDATE approach 645 allows the signaling to set up a separate media flow for each peer 646 that it wishes to exchange media with. In JSEP, this offer used in 647 the UPDATE would be formed by simply creating a new PeerConnection 648 and making sure that the same local media streams have been added 649 into this new PeerConnection. Then the new PeerConnection object 650 would produce a SDP offer that could be used by the signaling to 651 perform the UPDATE strategy discussed in [RFC3960]. 653 As a result of sharing the media streams, the application will end up 654 with N parallel PeerConnection sessions, each with a local and remote 655 description and their own local and remote addresses. The media flow 656 from these sessions can be managed by specifying SDP direction 657 attributes in the descriptions, or the application can choose to play 658 out the media from all sessions mixed together. Of course, if the 659 application wants to only keep a single session, it can simply 660 terminate the sessions that it no longer needs. 662 4. Interface 664 This section details the basic operations that must be present to 665 implement JSEP functionality. The actual API exposed in the W3C API 666 may have somewhat different syntax, but should map easily to these 667 concepts. 669 4.1. Methods 671 4.1.1. Constructor 673 The PeerConnection constructor allows the application to specify 674 global parameters for the media session, such as the STUN/TURN 675 servers and credentials to use when gathering candidates, as well as 676 the initial ICE candidate policy and pool size, and also the BUNDLE 677 policy to use. 679 If an ICE candidate policy is specified, it functions as described in 680 Section 3.4.3, causing the browser to only surface the permitted 681 candidates to the application, and only use those candidates for 682 connectivity checks. The set of available policies is as follows: 684 all: All candidates will be gathered and used. 686 public: Candidates with private IP addresses [RFC1918] will be 687 filtered out. This prevents exposure of internal network details, 688 at the cost of requiring relay usage even for intranet calls, if 689 the NAT does not allow hairpinning as described in [RFC4787], 690 section 6. 692 relay: All candidates except relay candidates will be filtered out. 693 This obfuscates the location information that might be ascertained 694 by the remote peer from the received candidates. Depending on how 695 the application deploys its relay servers, this could obfuscate 696 location to a metro or possibly even global level. 698 Although it can be overridden by local policy, the default ICE 699 candidate policy MUST be set to allow all candidates, as this 700 minimizes use of application STUN/TURN server resources. 702 If a size is specified for the ICE candidate pool, this indicates the 703 number of ICE components to pre-gather candidates for. Because pre- 704 gathering results in utilizing STUN/TURN server resources for 705 potentially long periods of time, this must only occur upon 706 application request, and therefore the default candidate pool size 707 MUST be zero. 709 The application can specify its preferred policy regarding use of 710 BUNDLE, the multiplexing mechanism defined in 711 [I-D.ietf-mmusic-sdp-bundle-negotiation]. By specifying a policy 712 from the list below, the application can control how aggressively it 713 will try to BUNDLE media streams together. The set of available 714 policies is as follows: 716 balanced: The application will BUNDLE all media streams of the same 717 type together. That is, if there are multiple audio and multiple 718 video MediaStreamTracks attached to a PeerConnection, all but the 719 first audio and video tracks will be marked as bundle-only, and 720 candidates will only be gathered for N media streams, where N is 721 the number of distinct media types. When talking to a non-BUNDLE- 722 aware endpoint, only the non-bundle-only streams will be 723 negotiated. This policy balances desire to multiplex with the 724 need to ensure basic audio and video still works in legacy cases. 725 Data channels will be in a separate bundle group. 727 max-compat: The application will offer BUNDLE, but mark none of its 728 streams as bundle-only. This policy will allow all streams to be 729 received by non-BUNDLE-aware endpoints, but require separate 730 candidates to be gathered for each media stream. 732 max-bundle: The application will BUNDLE all of its media streams, 733 including data channels, on a single transport. All streams other 734 than the first will be marked as bundle-only. This policy aims to 735 minimize candidate gathering and maximize multiplexing, at the 736 cost of less compatibility with legacy endpoints. 738 As it provides the best tradeoff between performance and 739 compatibility with legacy endpoints, the default BUNDLE policy MUST 740 be set to "balanced". 742 The application can specify its preferred policy regarding use of 743 RTP/RTCP multiplexing [RFC5761] using one of the following policies: 745 negotiate: The browser will gather both RTP and RTCP candidates but 746 also will offer "a=rtcp-mux", thus allowing for compatibility with 747 either multiplexing or non-multiplexing endpoints. 749 require: The browser will only gather RTP candidates. [[OPEN ISSUE: 750 how should the answerer behave. https://github.com/rtcweb- 751 wg/jsep/issues/114]] This halves the number of candidates that the 752 offerer needs to gather. 754 4.1.2. createOffer 756 The createOffer method generates a blob of SDP that contains a 757 [RFC3264] offer with the supported configurations for the session, 758 including descriptions of the local MediaStreams attached to this 759 PeerConnection, the codec/RTP/RTCP options supported by this 760 implementation, and any candidates that have been gathered by the ICE 761 Agent. An options parameter may be supplied to provide additional 762 control over the generated offer. This options parameter should 763 allow for the following manipulations to be performed: 765 o To indicate support for a media type even if no MediaStreamTracks 766 of that type have been added to the session (e.g., an audio call 767 that wants to receive video.) 769 o To trigger an ICE restart, for the purpose of reestablishing 770 connectivity. 772 In the initial offer, the generated SDP will contain all desired 773 functionality for the session (functionality that is supported but 774 not desired by default may be omitted); for each SDP line, the 775 generation of the SDP will follow the process defined for generating 776 an initial offer from the document that specifies the given SDP line. 777 The exact handling of initial offer generation is detailed in 778 Section 5.2.1 below. 780 In the event createOffer is called after the session is established, 781 createOffer will generate an offer to modify the current session 782 based on any changes that have been made to the session, e.g. adding 783 or removing MediaStreams, or requesting an ICE restart. For each 784 existing stream, the generation of each SDP line must follow the 785 process defined for generating an updated offer from the RFC that 786 specifies the given SDP line. For each new stream, the generation of 787 the SDP must follow the process of generating an initial offer, as 788 mentioned above. If no changes have been made, or for SDP lines that 789 are unaffected by the requested changes, the offer will only contain 790 the parameters negotiated by the last offer-answer exchange. The 791 exact handling of subsequent offer generation is detailed in 792 Section 5.2.2. below. 794 Session descriptions generated by createOffer must be immediately 795 usable by setLocalDescription; if a system has limited resources 796 (e.g. a finite number of decoders), createOffer should return an 797 offer that reflects the current state of the system, so that 798 setLocalDescription will succeed when it attempts to acquire those 799 resources. Because this method may need to inspect the system state 800 to determine the currently available resources, it may be implemented 801 as an async operation. 803 Calling this method may do things such as generate new ICE 804 credentials, but does not result in candidate gathering, or cause 805 media to start or stop flowing. 807 4.1.3. createAnswer 809 The createAnswer method generates a blob of SDP that contains a 810 [RFC3264] SDP answer with the supported configuration for the session 811 that is compatible with the parameters supplied in the most recent 812 call to setRemoteDescription, which MUST have been called prior to 813 calling createAnswer. Like createOffer, the returned blob contains 814 descriptions of the local MediaStreams attached to this 815 PeerConnection, the codec/RTP/RTCP options negotiated for this 816 session, and any candidates that have been gathered by the ICE Agent. 817 An options parameter may be supplied to provide additional control 818 over the generated answer. 820 As an answer, the generated SDP will contain a specific configuration 821 that specifies how the media plane should be established; for each 822 SDP line, the generation of the SDP must follow the process defined 823 for generating an answer from the document that specifies the given 824 SDP line. The exact handling of answer generation is detailed in 825 Section 5.3. below. 827 Session descriptions generated by createAnswer must be immediately 828 usable by setLocalDescription; like createOffer, the returned 829 description should reflect the current state of the system. Because 830 this method may need to inspect the system state to determine the 831 currently available resources, it may need to be implemented as an 832 async operation. 834 Calling this method may do things such as generate new ICE 835 credentials, but does not trigger candidate gathering or change media 836 state. 838 4.1.4. SessionDescriptionType 840 Session description objects (RTCSessionDescription) may be of type 841 "offer", "pranswer", or "answer". These types provide information as 842 to how the description parameter should be parsed, and how the media 843 state should be changed. 845 "offer" indicates that a description should be parsed as an offer; 846 said description may include many possible media configurations. A 847 description used as an "offer" may be applied anytime the 848 PeerConnection is in a stable state, or as an update to a previously 849 supplied but unanswered "offer". 851 "pranswer" indicates that a description should be parsed as an 852 answer, but not a final answer, and so should not result in the 853 freeing of allocated resources. It may result in the start of media 854 transmission, if the answer does not specify an inactive media 855 direction. A description used as a "pranswer" may be applied as a 856 response to an "offer", or an update to a previously sent "pranswer". 858 "answer" indicates that a description should be parsed as an answer, 859 the offer-answer exchange should be considered complete, and any 860 resources (decoders, candidates) that are no longer needed can be 861 released. A description used as an "answer" may be applied as a 862 response to a "offer", or an update to a previously sent "pranswer". 864 The only difference between a provisional and final answer is that 865 the final answer results in the freeing of any unused resources that 866 were allocated as a result of the offer. As such, the application 867 can use some discretion on whether an answer should be applied as 868 provisional or final, and can change the type of the session 869 description as needed. For example, in a serial forking scenario, an 870 application may receive multiple "final" answers, one from each 871 remote endpoint. The application could choose to accept the initial 872 answers as provisional answers, and only apply an answer as final 873 when it receives one that meets its criteria (e.g. a live user 874 instead of voicemail). 876 "rollback" is a special session description type implying that the 877 state machine should be rolled back to the previous state, as 878 described in Section 4.1.4.2. The contents MUST be empty. 880 4.1.4.1. Use of Provisional Answers 882 Most web applications will not need to create answers using the 883 "pranswer" type. While it is good practice to send an immediate 884 response to an "offer", in order to warm up the session transport and 885 prevent media clipping, the preferred handling for a web application 886 would be to create and send an "inactive" final answer immediately 887 after receiving the offer. Later, when the called user actually 888 accepts the call, the application can create a new "sendrecv" offer 889 to update the previous offer/answer pair and start the media flow. 890 While this could also be done with an inactive "pranswer", followed 891 by a sendrecv "answer", the initial "pranswer" leaves the offer- 892 answer exchange open, which means that neither side can send an 893 updated offer during this time. 895 As an example, consider a typical web application that will set up a 896 data channel, an audio channel, and a video channel. When an 897 endpoint receives an offer with these channels, it could send an 898 answer accepting the data channel for two-way data, and accepting the 899 audio and video tracks as inactive or receive-only. It could then 900 ask the user to accept the call, acquire the local media streams, and 901 send a new offer to the remote side moving the audio and video to be 902 two-way media. By the time the human has accepted the call and 903 triggered the new offer, it is likely that the ICE and DTLS 904 handshaking for all the channels will already have finished. 906 Of course, some applications may not be able to perform this double 907 offer-answer exchange, particularly ones that are attempting to 908 gateway to legacy signaling protocols. In these cases, "pranswer" 909 can still provide the application with a mechanism to warm up the 910 transport. 912 4.1.4.2. Rollback 914 In certain situations it may be desirable to "undo" a change made to 915 setLocalDescription or setRemoteDescription. Consider a case where a 916 call is ongoing, and one side wants to change some of the session 917 parameters; that side generates an updated offer and then calls 918 setLocalDescription. However, the remote side, either before or 919 after setRemoteDescription, decides it does not want to accept the 920 new parameters, and sends a reject message back to the offerer. Now, 921 the offerer, and possibly the answerer as well, need to return to a 922 stable state and the previous local/remote description. To support 923 this, we introduce the concept of "rollback". 925 A rollback discards any proposed changes to the session, returning 926 the state machine to the stable state, and setting the modified local 927 and/or remote description back to their previous values. Any 928 resources or candidates that were allocated by the abandoned local 929 description are discarded; any media that is received will be 930 processed according to the previous local and remote descriptions. 931 Rollback can only be used to cancel proposed changes; there is no 932 support for rolling back from a stable state to a previous stable 933 state. Note that this implies that once the answerer has performed 934 setLocalDescription with his answer, this cannot be rolled back. 936 A rollback is performed by supplying a session description of type 937 "rollback" with empty contents to either setLocalDescription or 938 setRemoteDescription, depending on which was most recently used (i.e. 939 if the new offer was supplied to setLocalDescription, the rollback 940 should be done using setLocalDescription as well). 942 4.1.5. setLocalDescription 944 The setLocalDescription method instructs the PeerConnection to apply 945 the supplied SDP blob as its local configuration. The type field 946 indicates whether the blob should be processed as an offer, 947 provisional answer, or final answer; offers and answers are checked 948 differently, using the various rules that exist for each SDP line. 950 This API changes the local media state; among other things, it sets 951 up local resources for receiving and decoding media. In order to 952 successfully handle scenarios where the application wants to offer to 953 change from one media format to a different, incompatible format, the 954 PeerConnection must be able to simultaneously support use of both the 955 old and new local descriptions (e.g. support codecs that exist in 956 both descriptions) until a final answer is received, at which point 957 the PeerConnection can fully adopt the new local description, or roll 958 back to the old description if the remote side denied the change. 960 This API indirectly controls the candidate gathering process. When a 961 local description is supplied, and the number of transports currently 962 in use does not match the number of transports needed by the local 963 description, the PeerConnection will create transports as needed and 964 begin gathering candidates for them. 966 If setRemoteDescription was previous called with an offer, and 967 setLocalDescription is called with an answer (provisional or final), 968 and the media directions are compatible, and media are available to 969 send, this will result in the starting of media transmission. 971 4.1.6. setRemoteDescription 973 The setRemoteDescription method instructs the PeerConnection to apply 974 the supplied SDP blob as the desired remote configuration. As in 975 setLocalDescription, the type field of the indicates how the blob 976 should be processed. 978 This API changes the local media state; among other things, it sets 979 up local resources for sending and encoding media. 981 If setLocalDescription was previously called with an offer, and 982 setRemoteDescription is called with an answer (provisional or final), 983 and the media directions are compatible, and media are available to 984 send, this will result in the starting of media transmission. 986 4.1.7. localDescription 988 The localDescription method returns a copy of the current local 989 configuration, i.e. what was most recently passed to 990 setLocalDescription, plus any local candidates that have been 991 generated by the ICE Agent. 993 [[OPEN ISSUE: Do we need to expose accessors for both the current and 994 proposed local description? https://github.com/rtcweb-wg/jsep/ 995 issues/16]] 997 A null object will be returned if the local description has not yet 998 been established. 1000 4.1.8. remoteDescription 1002 The remoteDescription method returns a copy of the current remote 1003 configuration, i.e. what was most recently passed to 1004 setRemoteDescription, plus any remote candidates that have been 1005 supplied via processIceMessage. 1007 [[OPEN ISSUE: Do we need to expose accessors for both the current and 1008 proposed remote description? https://github.com/rtcweb-wg/jsep/ 1009 issues/16]] 1011 A null object will be returned if the remote description has not yet 1012 been established. 1014 4.1.9. canTrickleIceCandidates 1016 The canTrickleIceCandidates property indicates whether the remote 1017 side supports receiving trickled candidates. There are three 1018 potential values: 1020 null: No SDP has been received from the other side, so it is not 1021 known if it can handle trickle. This is the initial value before 1022 setRemoteDescription() is called. 1024 true: SDP has been received from the other side indicating that it 1025 can support trickle. 1027 false: SDP has been received from the other side indicating that it 1028 cannot support trickle. 1030 As described in Section 3.4.2, JSEP implementations always provide 1031 candidates to the application individually, consistent with what is 1032 needed for Trickle ICE. However, applications can use the 1033 canTrickleIceCandidates property to determine whether their peer can 1034 actually do Trickle ICE, i.e., whether it is safe to send an initial 1035 offer or answer followed later by candidates as they are gathered. 1036 As "true" is the only value that definitively indicates remote 1037 Trickle ICE support, an application which compares 1038 canTrickleIceCandidates against "true" will by default attempt Half 1039 Trickle on initial offers and Full Trickle on subsequent interactions 1040 with a Trickle ICE-compatible agent. 1042 4.1.10. setConfiguration 1044 The setConfiguration method allows the global configuration of the 1045 PeerConnection, which was initially set by constructor parameters, to 1046 be changed during the session. The effects of this method call 1047 depend on when it is invoked, and differ depending on which specific 1048 parameters are changed: 1050 o Any changes to the STUN/TURN servers to use affect the next 1051 gathering phase. If gathering has already occurred, this will 1052 cause the next call to createOffer to generate new ICE 1053 credentials, for the purpose of forcing an ICE restart and kicking 1054 off a new gathering phase, in which the new servers will be used. 1055 If the ICE candidate pool has a nonzero size, any existing 1056 candidates will be discarded, and new candidates will be gathered 1057 from the new servers. 1059 o Any changes to the ICE candidate policy also affect the next 1060 gathering phase, in similar fashion to the server changes 1061 described above. Note though that changes to the policy have no 1062 effect on the candidate pool, because pooled candidates are not 1063 surfaced to the application until a gathering phase occurs, and so 1064 any necessary filtering can still be done on any pooled 1065 candidates. 1067 o Any changes to the ICE candidate pool size take effect 1068 immediately; if increased, additional candidates are pre-gathered; 1069 if decreased, the now-superfluous candidates are discarded. 1071 o The BUNDLE and RTCP-multiplexing policies MUST NOT be changed 1072 after the construction of the PeerConnection. 1074 This call may result in a change to the state of the ICE Agent, and 1075 may result in a change to media state if it results in connectivity 1076 being established. 1078 4.1.11. addIceCandidate 1080 The addIceCandidate method provides a remote candidate to the ICE 1081 Agent, which, if parsed successfully, will be added to the remote 1082 description according to the rules defined for Trickle ICE. 1083 Connectivity checks will be sent to the new candidate. 1085 This call will result in a change to the state of the ICE Agent, and 1086 may result in a change to media state if it results in connectivity 1087 being established. 1089 5. SDP Interaction Procedures 1091 This section describes the specific procedures to be followed when 1092 creating and parsing SDP objects. 1094 5.1. Requirements Overview 1096 JSEP implementations must comply with the specifications listed below 1097 that govern the creation and processing of offers and answers. 1099 The first set of specifications is the "mandatory-to-implement" set. 1100 All implementations must support these behaviors, but may not use all 1101 of them if the remote side, which may not be a JSEP endpoint, does 1102 not support them. 1104 The second set of specifications is the "mandatory-to-use" set. The 1105 local JSEP endpoint and any remote endpoint must indicate support for 1106 these specifications in their session descriptions. 1108 5.1.1. Implementation Requirements 1110 This list of mandatory-to-implement specifications is derived from 1111 the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. 1113 R-1 [RFC4566] is the base SDP specification and MUST be 1114 implemented. 1116 R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF 1117 [RFC5764] and TCP/DTLS/RTP/SAVPF 1118 [I-D.nandakumar-mmusic-proto-iana-registration] RTP profiles. 1120 R-3 [RFC5245] MUST be implemented for signaling the ICE credentials 1121 and candidate lines corresponding to each media stream. The 1122 ICE implementation MUST be a Full implementation, not a Lite 1123 implementation. 1125 R-4 [RFC5763] MUST be implemented to signal DTLS certificate 1126 fingerprints. 1128 R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying 1129 information. 1131 R-6 The [RFC5888] grouping framework MUST be implemented for 1132 signaling grouping information, and MUST be used to identify m= 1133 lines via the a=mid attribute. 1135 R-7 [I-D.ietf-mmusic-msid] MUST be supported, in order to signal 1136 associations between RTP objects and W3C MediaStreams and 1137 MediaStreamTracks in a standard way. 1139 R-8 The bundle mechanism in 1140 [I-D.ietf-mmusic-sdp-bundle-negotiation] MUST be supported to 1141 signal the ability to multiplex RTP streams on a single UDP 1142 port, in order to avoid excessive use of port number resources. 1144 R-9 The SDP attributes of "sendonly", "recvonly", "inactive", and 1145 "sendrecv" from [RFC4566] MUST be implemented to signal 1146 information about media direction. 1148 R-10 [RFC5576] MUST be implemented to signal RTP SSRC values and 1149 grouping semantics. 1151 R-11 [RFC4585] MUST be implemented to signal RTCP based feedback. 1153 R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and 1154 RTCP. 1156 R-13 [RFC5506] MUST be implemented to signal reduced-size RTCP 1157 messages. 1159 R-14 [RFC4588] MUST be implemented to signal RTX payload type 1160 associations. 1162 R-15 [RFC3556] with bandwidth modifiers MAY be supported for 1163 specifying RTCP bandwidth as a fraction of the media bandwidth, 1164 RTCP fraction allocated to the senders and setting maximum 1165 media bit-rate boundaries. 1167 R-16 TODO: any others? 1168 As required by [RFC4566], Section 5.13, JSEP implementations MUST 1169 ignore unknown attribute (a=) lines. 1171 5.1.2. Usage Requirements 1173 All session descriptions handled by JSEP endpoints, both local and 1174 remote, MUST indicate support for the following specifications. If 1175 any of these are absent, this omission MUST be treated as an error. 1177 R-1 ICE, as specified in [RFC5245], MUST be used. Note that the 1178 remote endpoint may use a Lite implementation; implementations 1179 MUST properly handle remote endpoints which do ICE-Lite. 1181 R-2 DTLS [RFC6347] or DTLS-SRTP [RFC5763], MUST be used, as 1182 appropriate for the media type, as specified in 1183 [I-D.ietf-rtcweb-security-arch] 1185 5.1.3. Profile Names and Interoperability 1187 For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ 1188 RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of 1189 these two profiles for each media m= line they produce in an offer. 1190 For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ 1191 SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two 1192 profiles for each data m= line they produce in an offer. Because ICE 1193 can select either TCP or UDP transport depending on network 1194 conditions, both advertisements are consistent with ICE eventually 1195 selecting either either UDP or TCP. 1197 Unfortunately, in an attempt at compatibility, some endpoints 1198 generate other profile strings even when they mean to support one of 1199 these profiles. For instance, an endpoint might generate "RTP/AVP" 1200 but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its 1201 willingness to support "(UDP,TCP)/TLS/RTP/SAVPF". In order to 1202 simplify compatibility with such endpoints, JSEP endpoints MUST 1203 follow the following rules when processing the media m= sections in 1204 an offer: 1206 o The profile in any "m=" line in any answer MUST exactly match the 1207 profile provided in the offer. 1209 o Any profile matching the following patterns MUST be accepted: 1210 "RTP/[S]AVP[F]" and "(UDP/TCP)/TLS/RTP/SAVP[F]" 1212 o Because DTLS-SRTP is REQUIRED, the choice of SAVP or AVP has no 1213 effect; support for DTLS-SRTP is determined by the presence of the 1214 "a=fingerprint" attribute. Note that lack of an "a=fingerprint" 1215 attribute will lead to negotiation failure. 1217 o The use of AVPF or AVP simply controls the timing rules used for 1218 RTCP feedback. If AVPF is provided, or an "a=rtcp-fb" attribute 1219 is present, assume AVPF timing, i.e. a default value of "trr- 1220 int=0". Otherwise, assume that AVPF is being used in an AVP 1221 compatible mode and use AVP timing, i.e., "trr-int=4". 1223 o For data m= sections, JSEP endpoints MUST support receiving the 1224 "UDP/ DTLS/SCTP", "TCP/DTLS/SCTP", or "DTLS/SCTP" (for backwards 1225 compatibility) profiles. 1227 Note that re-offers by JSEP endpoints MUST use the correct profile 1228 strings even if the initial offer/answer exchange used an (incorrect) 1229 older profile string. 1231 5.2. Constructing an Offer 1233 When createOffer is called, a new SDP description must be created 1234 that includes the functionality specified in 1235 [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are 1236 explained below. 1238 5.2.1. Initial Offers 1240 When createOffer is called for the first time, the result is known as 1241 the initial offer. 1243 The first step in generating an initial offer is to generate session- 1244 level attributes, as specified in [RFC4566], Section 5. 1245 Specifically: 1247 o The first SDP line MUST be "v=0", as specified in [RFC4566], 1248 Section 5.1 1250 o The second SDP line MUST be an "o=" line, as specified in 1251 [RFC4566], Section 5.2. The value of the field SHOULD 1252 be "-". The value of the field SHOULD be a 1253 cryptographically random number. To ensure uniqueness, this 1254 number SHOULD be at least 64 bits long. The value of the field SHOULD be zero. The value of the 1256 tuple SHOULD be set to a non- 1257 meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the 1258 local address in this field. As mentioned in [RFC4566], the 1259 entire o= line needs to be unique, but selecting a random number 1260 for is sufficient to accomplish this. 1262 o The third SDP line MUST be a "s=" line, as specified in [RFC4566], 1263 Section 5.3; to match the "o=" line, a single dash SHOULD be used 1264 as the session name, e.g. "s=-". Note that this differs from the 1265 advice in [RFC4566] which proposes a single space, but as both 1266 "o=" and "s=" are meaningless, having the same meaningless value 1267 seems clearer. 1269 o Session Information ("i="), URI ("u="), Email Address ("e="), 1270 Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and 1271 Time Zones ("z=") lines are not useful in this context and SHOULD 1272 NOT be included. 1274 o Encryption Keys ("k=") lines do not provide sufficient security 1275 and MUST NOT be included. 1277 o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; 1278 both and SHOULD be set to zero, e.g. "t=0 1279 0". 1281 o An "a=msid-semantic:WMS" line MUST be added, as specified in 1282 [I-D.ietf-mmusic-msid], Section 4. 1284 The next step is to generate m= sections, as specified in [RFC4566] 1285 Section 5.14, for each MediaStreamTrack that has been added to the 1286 PeerConnection via the addStream method. (Note that this method 1287 takes a MediaStream, which can contain multiple MediaStreamTracks, 1288 and therefore multiple m= sections can be generated even if addStream 1289 is only called once.) m=sections MUST be sorted first by the order in 1290 which the MediaStreams were added to the PeerConnection, and then by 1291 the alphabetical ordering of the media type for the MediaStreamTrack. 1292 For example, if a MediaStream containing both an audio and a video 1293 MediaStreamTrack is added to a PeerConnection, the resultant m=audio 1294 section will precede the m=video section. If a second MediaStream 1295 containing an audio MediaStreamTrack was added, it would follow the 1296 m=video section. 1298 Each m= section, provided it is not being bundled into another m= 1299 section, MUST generate a unique set of ICE credentials and gather its 1300 own unique set of ICE candidates. Otherwise, it MUST use the same 1301 ICE credentials and candidates as the m= section into which it is 1302 being bundled. Note that this means that for offers, any m= sections 1303 which are not bundle-only MUST have unique ICE credentials and 1304 candidates, since it is possible that the answerer will accept them 1305 without bundling them. 1307 For DTLS, all m= sections MUST use the certificate for the identity 1308 that has been specified for the PeerConnection; as a result, they 1309 MUST all have the same [RFC4572] fingerprint value, or this value 1310 MUST be a session-level attribute. 1312 Each m= section should be generated as specified in [RFC4566], 1313 Section 5.14. For the m= line itself, the following rules MUST be 1314 followed: 1316 o The port value is set to the port of the default ICE candidate for 1317 this m= section, but given that no candidates have yet been 1318 gathered, the "dummy" port value of 9 (Discard) MUST be used, as 1319 indicated in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1321 o To properly indicate use of DTLS, the field MUST be set to 1322 "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8, if the 1323 default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as 1324 specified in[I-D.nandakumar-mmusic-proto-iana-registration] if the 1325 default candidate uses TCP transport. 1327 The m= line MUST be followed immediately by a "c=" line, as specified 1328 in [RFC4566], Section 5.7. Again, as no candidates have yet been 1329 gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", 1330 as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1332 Each m= section MUST include the following attribute lines: 1334 o An "a=mid" line, as specified in [RFC5888], Section 4. When 1335 generating mid values, it is RECOMMENDED that the values be 3 1336 bytes or less, to allow them to efficiently fit into the RTP 1337 header extension defined in 1338 [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 11. 1340 o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, 1341 containing the dummy value "9 IN IP6 ::", because no candidates 1342 have yet been gathered. 1344 o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], 1345 Section 2. 1347 o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1. 1349 o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as 1350 specified in [RFC4566], Section 6. The audio and video codecs 1351 that MUST be supported are specified in [I-D.ietf-rtcweb-audio] 1352 (see Section 3) and [I-D.ietf-rtcweb-video] (see Section 5). 1354 o If this m= section is for media with configurable frame sizes, 1355 e.g. audio, an "a=maxptime" line, indicating the smallest of the 1356 maximum supported frame sizes out of all codecs included above, as 1357 specified in [RFC4566], Section 6. 1359 o For each primary codec where RTP retransmission should be used, a 1360 corresponding "a=rtpmap" line indicating "rtx" with the clock rate 1361 of the primary codec and an "a=fmtp" line that references the 1362 payload type of the primary codec, as specified in [RFC4588], 1363 Section 8.1. 1365 o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, 1366 as specified in [RFC4566], Section 6. The FEC mechanisms that 1367 MUST be supported are specified in [I-D.ietf-rtcweb-fec], 1368 Section 6, and specific usage for each media type is outlined in 1369 Sections 4 and 5. 1371 o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], 1372 Section 15.4. 1374 o An "a=ice-options" line, with the "trickle" option, as specified 1375 in [I-D.ietf-mmusic-trickle-ice], Section 4. 1377 o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the 1378 algorithm used for the fingerprint MUST match that used in the 1379 certificate signature. 1381 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1382 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1383 The role value in the offer MUST be "actpass". 1385 o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1. 1387 o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. 1389 o For each supported RTP header extension, an "a=extmap" line, as 1390 specified in [RFC5285], Section 5. The list of header extensions 1391 that SHOULD/MUST be supported is specified in 1392 [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions 1393 that require encryption MUST be specified as indicated in 1394 [RFC6904], Section 4. 1396 o For each supported RTCP feedback mechanism, an "a=rtcp-fb" 1397 mechanism, as specified in [RFC4585], Section 4.2. The list of 1398 RTCP feedback mechanisms that SHOULD/MUST be supported is 1399 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. 1401 o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, 1402 indicating the SSRC to be used for sending media, along with the 1403 mandatory "cname" source attribute, as specified in Section 6.1, 1404 indicating the CNAME for the source. The CNAME must be generated 1405 in accordance with [RFC7022]. [OPEN ISSUE: How are CNAMEs 1406 specified for MSTs? Are they randomly generated for each 1407 MediaStream? If so, can two MediaStreams be synced? See: 1408 https://github.com/rtcweb-wg/jsep/issues/4] 1410 o If RTX is supported for this media type, another "a=ssrc" line 1411 with the RTX SSRC, and an "a=ssrc-group" line, as specified in 1412 [RFC5576], section 4.2, with semantics set to "FID" and including 1413 the primary and RTX SSRCs. 1415 o If FEC is supported for this media type, another "a=ssrc" line 1416 with the FEC SSRC, and an "a=ssrc-group" line with semantics set 1417 to "FEC-FR" and including the primary and FEC SSRCs, as specified 1418 in [RFC5956], section 4.3. For simplicity, if both RTX and FEC 1419 are supported, the FEC SSRC MUST be the same as the RTX SSRC. 1421 o [OPEN ISSUE: Handling of a=imageattr] 1423 o If the BUNDLE policy for this PeerConnection is set to "max- 1424 bundle", and this is not the first m= section, or the BUNDLE 1425 policy is set to "balanced", and this is not the first m= section 1426 for this media type, an "a=bundle-only" line. 1428 Lastly, if a data channel has been created, a m= section MUST be 1429 generated for data. The field MUST be set to "application" 1430 and the field MUST be set to "UDP/DTLS/SCTP" if the default 1431 candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default 1432 candidate uses TCP transport [I-D.ietf-mmusic-sctp-sdp]. The "fmt" 1433 value MUST be set to the SCTP port number, as specified in 1434 Section 4.1. [TODO: update this to use a=sctp-port, as indicated in 1435 the latest data channel docs] 1437 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- 1438 passwd", "a=ice-options", "a=candidate", "a=fingerprint", and 1439 "a=setup" lines MUST be included as mentioned above, along with an 1440 "a=sctpmap" line referencing the SCTP port number and specifying the 1441 application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. 1442 [OPEN ISSUE: the -01 of this document is missing this information.] 1444 Once all m= sections have been generated, a session-level "a=group" 1445 attribute MUST be added as specified in [RFC5888]. This attribute 1446 MUST have semantics "BUNDLE", and MUST include the mid identifiers of 1447 each m= section. The effect of this is that the browser offers all 1448 m= sections as one BUNDLE group. However, whether the m= sections 1449 are bundle-only or not depends on the BUNDLE policy. 1451 Attributes which SDP permits to either be at the session level or the 1452 media level SHOULD generally be at the media level even if they are 1453 identical. This promotes readability, especially if one of a set of 1454 initially identical attributes is subsequently changed. 1456 Attributes other than the ones specified above MAY be included, 1457 except for the following attributes which are specifically 1458 incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], 1459 and MUST NOT be included: 1461 o "a=crypto" 1463 o "a=key-mgmt" 1465 o "a=ice-lite" 1467 Note that when BUNDLE is used, any additional attributes that are 1468 added MUST follow the advice in [I-D.ietf-mmusic-sdp-mux-attributes] 1469 on how those attributes interact with BUNDLE. 1471 Note that these requirements are in some cases stricter than those of 1472 SDP. Implementations MUST be prepared to accept compliant SDP even 1473 if it would not conform to the requirements for generating SDP in 1474 this specification. 1476 5.2.2. Subsequent Offers 1478 When createOffer is called a second (or later) time, or is called 1479 after a local description has already been installed, the processing 1480 is somewhat different than for an initial offer. 1482 If the initial offer was not applied using setLocalDescription, 1483 meaning the PeerConnection is still in the "stable" state, the steps 1484 for generating an initial offer should be followed, subject to the 1485 following restriction: 1487 o The fields of the "o=" line MUST stay the same except for the 1488 field, which MUST increment if the session 1489 description changes in any way, including the addition of ICE 1490 candidates. 1492 If the initial offer was applied using setLocalDescription, but an 1493 answer from the remote side has not yet been applied, meaning the 1494 PeerConnection is still in the "local-offer" state, an offer is 1495 generated by following the steps in the "stable" state above, along 1496 with these exceptions: 1498 o The "s=" and "t=" lines MUST stay the same. 1500 o Each "m=" and c=" line MUST be filled in with the port, protocol, 1501 and address of the default candidate for the m= section, as 1502 described in [RFC5245], Section 4.3. Each "a=rtcp" attribute line 1503 MUST also be filled in with the port and address of the 1504 appropriate default candidate, either the default RTP or RTCP 1505 candidate, depending on whether RTCP multiplexing is currently 1506 active or not. Note that if RTCP multiplexing is being offered, 1507 but not yet active, the default RTCP candidate MUST be used, as 1508 indicated in [RFC5761], section 5.1.3. In each case, if no 1509 candidates of the desired type have yet been gathered, dummy 1510 values MUST be used, as described above. 1512 o Each "a=mid" line MUST stay the same. 1514 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless 1515 the ICE configuration has changed (either changes to the supported 1516 STUN/TURN servers, or the ICE candidate policy), or the 1517 "IceRestart" option (Section 5.2.3.3 was specified. 1519 o Within each m= section, for each candidate that has been gathered 1520 during the most recent gathering phase (see Section 3.4.1), an 1521 "a=candidate" line MUST be added, as specified in [RFC5245], 1522 Section 4.3., paragraph 3. If candidate gathering for the section 1523 has completed, an "a=end-of-candidates" attribute MUST be added, 1524 as described in [I-D.ietf-mmusic-trickle-ice], Section 9.3. 1526 o For MediaStreamTracks that are still present, the "a=msid", 1527 "a=ssrc", and "a=ssrc-group" lines MUST stay the same. 1529 o If any MediaStreamTracks have been removed, either through the 1530 removeStream method or by removing them from an added MediaStream, 1531 their m= sections MUST be marked as recvonly by changing the value 1532 of the [RFC3264] directional attribute to "a=recvonly". The 1533 "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed from 1534 the associated m= sections. 1536 o If any MediaStreamTracks have been added, and there exist m= 1537 sections of the appropriate media type with no associated 1538 MediaStreamTracks (i.e. as described in the preceding paragraph), 1539 those m= sections MUST be recycled by adding the new 1540 MediaStreamTrack to the m= section. This is done by adding the 1541 necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the 1542 recycled m= section, and removing the "a=recvonly" attribute. 1544 If the initial offer was applied using setLocalDescription, and an 1545 answer from the remote side has been applied using 1546 setRemoteDescription, meaning the PeerConnection is in the "remote- 1547 pranswer" or "stable" states, an offer is generated based on the 1548 negotiated session descriptions by following the steps mentioned for 1549 the "local-offer" state above, along with these exceptions: [OPEN 1550 ISSUE: should this be permitted in the remote-pranswer state?] 1551 o If a m= section exists in the current local description, but does 1552 not have an associated local MediaStreamTrack (possibly because 1553 said MediaStreamTrack was removed since the last exchange), a m= 1554 section MUST still be generated in the new offer, as indicated in 1555 [RFC3264], Section 8. The disposition of this section will depend 1556 on the state of the remote MediaStreamTrack associated with this 1557 m= section. If one exists, and it is still in the "live" state, 1558 the new m= section MUST be marked as "a=recvonly", with no 1559 "a=msid" or related attributes present. If no remote 1560 MediaStreamTrack exists, or it is in the "ended" state, the m= 1561 section MUST be marked as rejected, by setting the port to zero, 1562 as indicated in [RFC3264], Section 8.2. 1564 o If any MediaStreamTracks have been added, and there exist recvonly 1565 m= sections of the appropriate media type with no associated 1566 MediaStreamTracks, or rejected m= sections of any media type, 1567 those m= sections MUST be recycled, and a local MediaStreamTrack 1568 associated with these recycled m= sections until all such existing 1569 m= sections have been used. This includes any recvonly or 1570 rejected m= sections created by the preceding paragraph. 1572 In addition, for each non-recycled, non-rejected m= section in the 1573 new offer, the following adjustments are made based on the contents 1574 of the corresponding m= section in the current remote description: 1576 o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST 1577 only include codecs present in the remote description. 1579 o The RTP header extensions MUST only include those that are present 1580 in the remote description. 1582 o The RTCP feedback extensions MUST only include those that are 1583 present in the remote description. 1585 o The "a=rtcp-mux" line MUST only be added if present in the remote 1586 description. 1588 o The "a=rtcp-rsize" line MUST only be added if present in the 1589 remote description. 1591 The "a=group:BUNDLE" attribute MUST include the mid identifiers 1592 specified in the BUNDLE group in the most recent answer, minus any m= 1593 sections that have been marked as rejected, plus any newly added or 1594 re-enabled m= sections. In other words, the BUNDLE attribute must 1595 contain all m= sections that were previously bundled, as long as they 1596 are still alive, as well as any new m= sections. 1598 5.2.3. Options Handling 1600 The createOffer method takes as a parameter an RTCOfferOptions 1601 object. Special processing is performed when generating a SDP 1602 description if the following options are present. 1604 5.2.3.1. OfferToReceiveAudio 1606 If the "OfferToReceiveAudio" option is specified, with an integer 1607 value of N, and M audio MediaStreamTracks have been added to the 1608 PeerConnection, the offer MUST include N non-rejected m= sections 1609 with media type "audio", even if N is greater than M. This allows 1610 the offerer to receive audio, including multiple independent streams, 1611 even when not sending it; accordingly, the directional attribute on 1612 the N-M audio m= sections without associated MediaStreamTracks MUST 1613 be set to recvonly. 1615 If N is set to a value less than M, the offer MUST mark the m= 1616 sections associated with the M-N most recently added (since the last 1617 setLocalDescription) MediaStreamTracks as sendonly. This allows the 1618 offerer to indicate that it does not want to receive audio on some or 1619 all of its newly created streams. For m= sections that have 1620 previously been negotiated, this setting has no effect. [TODO: refer 1621 to RTCRtpSender in the future] 1623 For backwards compatibility with pre-standard versions of this 1624 specification, a value of "true" is interpreted as equivalent to N=1, 1625 and "false" as N=0. 1627 5.2.3.2. OfferToReceiveVideo 1629 If the "OfferToReceiveVideo" option is specified, with an integer 1630 value of N, and M video MediaStreamTracks have been added to the 1631 PeerConnection, the offer MUST include N non-rejected m= sections 1632 with media type "video", even if N is greater than M. This allows 1633 the offerer to receive video, including multiple independent streams, 1634 even when not sending it; accordingly, the directional attribute on 1635 the N-M video m= sections without associated MediaStreamTracks MUST 1636 be set to recvonly. 1638 If N is set to a value less than M, the offer MUST mark the m= 1639 sections associated with the M-N most recently added (since the last 1640 setLocalDescription) MediaStreamTracks as sendonly. This allows the 1641 offerer to indicate that it does not want to receive video on some or 1642 all of its newly created streams. For m= sections that have 1643 previously been negotiated, this setting has no effect. [TODO: refer 1644 to RTCRtpSender in the future] 1645 For backwards compatibility with pre-standard versions of this 1646 specification, a value of "true" is interpreted as equivalent to N=1, 1647 and "false" as N=0. 1649 5.2.3.3. IceRestart 1651 If the "IceRestart" option is specified, with a value of "true", the 1652 offer MUST indicate an ICE restart by generating new ICE ufrag and 1653 pwd attributes, as specified in [RFC5245], Section 9.1.1.1. If this 1654 option is specified on an initial offer, it has no effect (since a 1655 new ICE ufrag and pwd are already generated). Similarly, if the ICE 1656 configuration has changed, this option has no effect, since new ufrag 1657 and pwd attributes will be generated automatically. This option is 1658 primarily useful for reestablishing connectivity in cases where 1659 failures are detected by the application. 1661 5.2.3.4. VoiceActivityDetection 1663 If the "VoiceActivityDetection" option is specified, with a value of 1664 "true", the offer MUST indicate support for silence suppression in 1665 the audio it receives by including comfort noise ("CN") codecs for 1666 each offered audio codec, as specified in [RFC3389], Section 5.1, 1667 except for codecs that have their own internal silence suppression 1668 support. For codecs that have their own internal silence suppression 1669 support, the appropriate fmtp parameters for that codec MUST be 1670 specified to indicate that silence suppression for received audio is 1671 desired. For example, when using the Opus codec, the "usedtx=1" 1672 parameter would be specified in the offer. This option allows the 1673 endpoint to significantly reduce the amount of audio bandwidth it 1674 receives, at the cost of some fidelity, depending on the quality of 1675 the remote VAD algorithm. 1677 5.3. Generating an Answer 1679 When createAnswer is called, a new SDP description must be created 1680 that is compatible with the supplied remote description as well as 1681 the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact 1682 details of this process are explained below. 1684 5.3.1. Initial Answers 1686 When createAnswer is called for the first time after a remote 1687 description has been provided, the result is known as the initial 1688 answer. If no remote description has been installed, an answer 1689 cannot be generated, and an error MUST be returned. 1691 Note that the remote description SDP may not have been created by a 1692 JSEP endpoint and may not conform to all the requirements listed in 1693 Section 5.2. For many cases, this is not a problem. However, if any 1694 mandatory SDP attributes are missing, or functionality listed as 1695 mandatory-to-use above is not present, this MUST be treated as an 1696 error, and MUST cause the affected m= sections to be marked as 1697 rejected. 1699 The first step in generating an initial answer is to generate 1700 session-level attributes. The process here is identical to that 1701 indicated in the Initial Offers section above. 1703 The next step is to generate m= sections for each m= section that is 1704 present in the remote offer, as specified in [RFC3264], Section 6. 1705 For the purposes of this discussion, any session-level attributes in 1706 the offer that are also valid as media-level attributes SHALL be 1707 considered to be present in each m= section. 1709 The next step is to go through each offered m= section. If there is 1710 a local MediaStreamTrack of the same type which has been added to the 1711 PeerConnection via addStream and not yet associated with a m= 1712 section, and the specific m= section is either sendrecv or recvonly, 1713 the MediaStreamTrack will be associated with the m= section at this 1714 time. MediaStreamTracks are assigned to m= sections using the 1715 canonical order described in Section 5.2.1. If there are more m= 1716 sections of a certain type than MediaStreamTracks, some m= sections 1717 will not have an associated MediaStreamTrack. If there are more 1718 MediaStreamTracks of a certain type than compatible m= sections, only 1719 the first N MediaStreamTracks will be able to be associated in the 1720 constructed answer. The remainder will need to be associated in a 1721 subsequent offer. 1723 For each offered m= section, if the associated remote 1724 MediaStreamTrack has been stopped, and is therefore in state "ended", 1725 and no local MediaStreamTrack has been associated, the corresponding 1726 m= section in the answer MUST be marked as rejected by setting the 1727 port in the m= line to zero, as indicated in [RFC3264], Section 6., 1728 and further processing for this m= section can be skipped. 1730 Provided that is not the case, each m= section in the answer should 1731 then be generated as specified in [RFC3264], Section 6.1. For the m= 1732 line itself, the following rules must be followed: 1734 o The port value would normally be set to the port of the default 1735 ICE candidate for this m= section, but given that no candidates 1736 have yet been gathered, the "dummy" port value of 9 (Discard) MUST 1737 be used, as indicated in [I-D.ietf-mmusic-trickle-ice], 1738 Section 5.1. 1740 o The field MUST be set to exactly match the field 1741 for the corresponding m= line in the offer. 1743 The m= line MUST be followed immediately by a "c=" line, as specified 1744 in [RFC4566], Section 5.7. Again, as no candidates have yet been 1745 gathered, the "c=" line must contain the "dummy" value "IN IP6 ::", 1746 as defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1748 If the offer supports BUNDLE, all m= sections to be BUNDLEd must use 1749 the same ICE credentials and candidates; all m= sections not being 1750 BUNDLEd must use unique ICE credentials and candidates. Each m= 1751 section MUST include the following: 1753 o If present in the offer, an "a=mid" line, as specified in 1754 [RFC5888], Section 9.1. The "mid" value MUST match that specified 1755 in the offer. 1757 o An "a=rtcp" line, as specified in [RFC3605], Section 2.1, 1758 containing the dummy value "9 IN IP6 ::", because no candidates 1759 have yet been gathered. 1761 o If a local MediaStreamTrack has been associated, an "a=msid" line, 1762 as specified in [I-D.ietf-mmusic-msid], Section 2. 1764 o Depending on the directionality of the offer, the disposition of 1765 any associated remote MediaStreamTrack, and the presence of an 1766 associated local MediaStreamTrack, the appropriate directionality 1767 attribute, as specified in [RFC3264], Section 6.1. If the offer 1768 was sendrecv, and the remote MediaStreamTrack is still "live", and 1769 there is a local MediaStreamTrack that has been associated, the 1770 directionality MUST be set as sendrecv. If the offer was 1771 sendonly, and the remote MediaStreamTrack is still "live", the 1772 directionality MUST be set as recvonly. If the offer was 1773 recvonly, and a local MediaStreamTrack has been associated, the 1774 directionality MUST be set as sendonly. If the offer was 1775 inactive, the directionality MUST be set as inactive. 1777 o For each supported codec that is present in the offer, "a=rtpmap" 1778 and "a=fmtp" lines, as specified in [RFC4566], Section 6, and 1779 [RFC3264], Section 6.1. The audio and video codecs that MUST be 1780 supported are specified in [I-D.ietf-rtcweb-audio] (see Section 3) 1781 and [I-D.ietf-rtcweb-video] (see Section 5). Note that for 1782 simplicity, the answerer MAY use different payload types for 1783 codecs than the offerer, as it is not prohibited by Section 6.1. 1785 o If this m= section is for media with configurable frame sizes, 1786 e.g. audio, an "a=maxptime" line, indicating the smallest of the 1787 maximum supported frame sizes out of all codecs included above, as 1788 specified in [RFC4566], Section 6. 1790 o If "rtx" is present in the offer, for each primary codec where RTP 1791 retransmission should be used, a corresponding "a=rtpmap" line 1792 indicating "rtx" with the clock rate of the primary codec and an 1793 "a=fmtp" line that references the payload type of the primary 1794 codec, as specified in [RFC4588], Section 8.1. 1796 o For each supported FEC mechanism, "a=rtpmap" and "a=fmtp" lines, 1797 as specified in [RFC4566], Section 6. The FEC mechanisms that 1798 MUST be supported are specified in [I-D.ietf-rtcweb-fec], 1799 Section 6, and specific usage for each media type is outlined in 1800 Sections 4 and 5. 1802 o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], 1803 Section 15.4. 1805 o If the "trickle" ICE option is present in the offer, an "a=ice- 1806 options" line, with the "trickle" option, as specified in 1807 [I-D.ietf-mmusic-trickle-ice], Section 4. 1809 o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the 1810 algorithm used for the fingerprint MUST match that used in the 1811 certificate signature. 1813 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1814 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1815 The role value in the answer MUST be "active" or "passive"; the 1816 "active" role is RECOMMENDED. 1818 o If present in the offer, an "a=rtcp-mux" line, as specified in 1819 [RFC5761], Section 5.1.1. If the "require" RTCP multiplexing 1820 policy is set and no "a=rtcp-mux" line is present in the offer, 1821 then the m=line MUST be marked as rejected by setting the port in 1822 the m= line to zero, as indicated in [RFC3264], Section 6. 1824 o If present in the offer, an "a=rtcp-rsize" line, as specified in 1825 [RFC5506], Section 5. 1827 o For each supported RTP header extension that is present in the 1828 offer, an "a=extmap" line, as specified in [RFC5285], Section 5. 1829 The list of header extensions that SHOULD/MUST be supported is 1830 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header 1831 extensions that require encryption MUST be specified as indicated 1832 in [RFC6904], Section 4. 1834 o For each supported RTCP feedback mechanism that is present in the 1835 offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], 1836 Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ 1837 MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], 1838 Section 5.1. 1840 o If a local MediaStreamTrack has been associated, an "a=ssrc" line, 1841 as specified in [RFC5576], Section 4.1, indicating the SSRC to be 1842 used for sending media. 1844 o If a local MediaStreamTrack has been associated, and RTX has been 1845 negotiated for this m= section, another "a=ssrc" line with the RTX 1846 SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], 1847 section 4.2, with semantics set to "FID" and including the primary 1848 and RTX SSRCs. 1850 o If a local MediaStreamTrack has been associated, and FEC has been 1851 negotiated for this m= section, another "a=ssrc" line with the FEC 1852 SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" 1853 and including the primary and FEC SSRCs, as specified in 1854 [RFC5956], section 4.3. For simplicity, if both RTX and FEC are 1855 supported, the FEC SSRC MUST be the same as the RTX SSRC. 1857 o [OPEN ISSUE: Handling of a=imageattr] 1859 If a data channel m= section has been offered, a m= section MUST also 1860 be generated for data. The field MUST be set to 1861 "application" and the field MUST be set to exactly match the 1862 field in the offer; the "fmt" value MUST be set to the SCTP port 1863 number, as specified in Section 4.1. [TODO: update this to use 1864 a=sctp-port, as indicated in the latest data channel docs] 1866 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- 1867 passwd", "a=ice-options", "a=candidate", "a=fingerprint", and 1868 "a=setup" lines MUST be included as mentioned above, along with an 1869 "a=sctpmap" line referencing the SCTP port number and specifying the 1870 application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. 1871 [OPEN ISSUE: the -01 of this document is missing this information.] 1873 If "a=group" attributes with semantics of "BUNDLE" are offered, 1874 corresponding session-level "a=group" attributes MUST be added as 1875 specified in [RFC5888]. These attributes MUST have semantics 1876 "BUNDLE", and MUST include the all mid identifiers from the offered 1877 BUNDLE groups that have not been rejected. Note that regardless of 1878 the presence of "a=bundle-only" in the offer, no m= sections in the 1879 answer should have an "a=bundle-only" line. 1881 Attributes that are common between all m= sections MAY be moved to 1882 session-level, if explicitly defined to be valid at session-level. 1884 The attributes prohibited in the creation of offers are also 1885 prohibited in the creation of answers. 1887 5.3.2. Subsequent Answers 1889 When createAnswer is called a second (or later) time, or is called 1890 after a local description has already been installed, the processing 1891 is somewhat different than for an initial answer. 1893 If the initial answer was not applied using setLocalDescription, 1894 meaning the PeerConnection is still in the "have-remote-offer" state, 1895 the steps for generating an initial answer should be followed, 1896 subject to the following restriction: 1898 o The fields of the "o=" line MUST stay the same except for the 1899 field, which MUST increment if the session 1900 description changes in any way from the previously generated 1901 answer. 1903 If any session description was previously supplied to 1904 setLocalDescription, an answer is generated by following the steps in 1905 the "have-remote-offer" state above, along with these exceptions: 1907 o The "s=" and "t=" lines MUST stay the same. 1909 o Each "m=" and c=" line MUST be filled in with the port and address 1910 of the default candidate for the m= section, as described in 1911 [RFC5245], Section 4.3. Note, however, that the m= line protocol 1912 need not match the default candidate, because this protocol value 1913 must instead match what was supplied in the offer, as described 1914 above. Each "a=rtcp" attribute line MUST also be filled in with 1915 the port and address of the appropriate default candidate, either 1916 the default RTP or RTCP candidate, depending on whether RTCP 1917 multiplexing is enabled in the answer. In each case, if no 1918 candidates of the desired type have yet been gathered, dummy 1919 values MUST be used, as described in the initial answer section 1920 above. 1922 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. 1924 o Within each m= section, for each candidate that has been gathered 1925 during the most recent gathering phase (see Section 3.4.1), an 1926 "a=candidate" line MUST be added, as specified in [RFC5245], 1927 Section 4.3., paragraph 3. If candidate gathering for the section 1928 has completed, an "a=end-of-candidates" attribute MUST be added, 1929 as described in [I-D.ietf-mmusic-trickle-ice], Section 9.3. 1931 o For MediaStreamTracks that are still present, the "a=msid", 1932 "a=ssrc", and "a=ssrc-group" lines MUST stay the same. 1934 5.3.3. Options Handling 1936 The createAnswer method takes as a parameter an RTCAnswerOptions 1937 object. The set of parameters for RTCAnswerOptions is different than 1938 those supported in RTCOfferOptions; the OfferToReceiveAudio, 1939 OfferToReceiveVideo, and IceRestart options mentioned in 1940 Section 5.2.3 are meaningless in the context of generating an answer, 1941 as there is no need to generate extra m= lines in an answer, and ICE 1942 credentials will automatically be changed for all m= lines where the 1943 offerer chose to perform ICE restart. 1945 The following options are supported in RTCAnswerOptions. 1947 5.3.3.1. VoiceActivityDetection 1949 Silence suppression in the answer is handled as described in 1950 Section 5.2.3.4. 1952 5.4. Processing a Local Description 1954 When a SessionDescription is supplied to setLocalDescription, the 1955 following steps MUST be performed: 1957 o First, the type of the SessionDescription is checked against the 1958 current state of the PeerConnection: 1960 * If the type is "offer", the PeerConnection state MUST be either 1961 "stable" or "have-local-offer". 1963 * If the type is "pranswer" or "answer", the PeerConnection state 1964 MUST be either "have-remote-offer" or "have-local-pranswer". 1966 o If the type is not correct for the current state, processing MUST 1967 stop and an error MUST be returned. 1969 o Next, the SessionDescription is parsed into a data structure, as 1970 described in the Section 5.6 section below. If parsing fails for 1971 any reason, processing MUST stop and an error MUST be returned. 1973 o Finally, the parsed SessionDescription is applied as described in 1974 the Section 5.7 section below. 1976 5.5. Processing a Remote Description 1978 When a SessionDescription is supplied to setRemoteDescription, the 1979 following steps MUST be performed: 1981 o First, the type of the SessionDescription is checked against the 1982 current state of the PeerConnection: 1984 * If the type is "offer", the PeerConnection state MUST be either 1985 "stable" or "have-remote-offer". 1987 * If the type is "pranswer" or "answer", the PeerConnection state 1988 MUST be either "have-local-offer" or "have-remote-pranswer". 1990 o If the type is not correct for the current state, processing MUST 1991 stop and an error MUST be returned. 1993 o Next, the SessionDescription is parsed into a data structure, as 1994 described in the Section 5.6 section below. If parsing fails for 1995 any reason, processing MUST stop and an error MUST be returned. 1997 o Finally, the parsed SessionDescription is applied as described in 1998 the Section 5.8 section below. 2000 5.6. Parsing a Session Description 2002 [The behavior described herein is a draft version, and needs more 2003 discussion to resolve various open issues.] 2005 When a SessionDescription of any type is supplied to setLocal/ 2006 RemoteDescription, the implementation must parse it and reject it if 2007 it is invalid. The exact details of this process are explained 2008 below. 2010 The SDP contained in the session description object consists of a 2011 sequence of text lines, each containing a key-value expression, as 2012 described in [RFC4566], Section 5. The SDP is read, line-by-line, 2013 and converted to a data structure that contains the deserialized 2014 information. However, SDP allows many types of lines, not all of 2015 which are relevant to JSEP applications. For each line, the 2016 implementation will first ensure it is syntactically correct 2017 according its defining ABNF [TODO: reference], check that it conforms 2018 to [RFC4566] and [RFC3264] semantics, and then either parse and store 2019 or discard the provided value, as described below. [TODO: ensure 2020 that every line is listed below.] If the line is not well-formed, or 2021 cannot be parsed as described, the parser MUST stop with an error and 2022 reject the session description. This ensures that implementations do 2023 not accidentally misinterpret ambiguous SDP. 2025 5.6.1. Session-Level Parsing 2027 First, the session-level lines are checked and parsed. These lines 2028 MUST occur in a specific order, and with a specific syntax, as 2029 defined in [RFC4566], Section 5. Note that while the specific line 2030 types (e.g. "v=", "c=") MUST occur in the defined order, lines of the 2031 same type (typically "a=") can occur in any order, and their ordering 2032 is not meaningful. 2034 For non-attribute (non-"a=") lines, their sequencing, syntax, and 2035 semantics, are checked, as mentioned above. The following lines are 2036 not meaningful in the JSEP context and MAY be discarded once they 2037 have been checked. 2039 TODO 2041 The remaining lines are processed as follows: 2043 The "c=" line MUST be parsed and stored. 2045 [OPEN ISSUE: For example, because session-level bandwidth is 2046 ambiguous when multiple media streams are present, a "b=" line at 2047 session level is not useful and its value SHOULD be ignored. 2048 [OPEN ISSUE: is this WG consensus? Are there other non-a= lines 2049 that we need to do more than just syntactical validation, e.g. 2050 v=?] 2052 Specific processing MUST be applied for the following session-level 2053 attribute ("a=") lines: 2055 o Any "a=group" lines are parsed as specified in [RFC5888], 2056 Section 5, and the group's semantics and mids are stored. 2058 o If present, a single "a=ice-lite" line is parsed as specified in 2059 [RFC5245], Section 15.3, and a value indicating the presence of 2060 ice-lite is stored. 2062 o If present, a single "a=ice-ufrag" line is parsed as specified in 2063 [RFC5245], Section 15.4, and the ufrag value is stored. 2065 o If present, a single "a=ice-pwd" line is parsed as specified in 2066 [RFC5245], Section 15.4, and the password value is stored. 2068 o If present, a single "a=ice-options" line is parsed as specified 2069 in [RFC5245], Section 15.5, and the set of specified options is 2070 stored. 2072 o Any "a=fingerprint" lines are parsed as specified in [RFC4572], 2073 Section 5, and the set of fingerprint and algorithm values is 2074 stored. 2076 o If present, a single "a=setup" line is parsed as specified in 2077 [RFC4145], Section 4, and the setup value is stored. 2079 o Any "a=extmap" lines are parsed as specified in [RFC5285], 2080 Section 5, and their values are stored. 2082 o TODO: msid-semantic, identity, rtcp-rsize, rtcp-mux, and any other 2083 attribs valid at session level. 2085 Once all the session-level lines have been parsed, processing 2086 continues with the lines in media sections. 2088 5.6.2. Media Section Parsing 2090 Like the session-level lines, the media session lines MUST occur in 2091 the specific order and with the specific syntax defined in [RFC4566], 2092 Section 5. 2094 The "m=" line itself MUST be parsed as described in [RFC4566], 2095 Section 5.14, and the media, port, proto, and fmt values stored. 2097 Following the "m=" line, specific processing MUST be applied for the 2098 following non-attribute lines: 2100 o The "c=" line, if present, MUST be parsed as specified in 2101 [RFC4566], Section 5.7, and its contents stored. 2103 o The "b=" line, if present, MUST be parsed as specified in 2104 [RFC4566], Section 5.8, and the bwtype and bandwidth values 2105 stored. 2107 Specific processing MUST also be applied for the following attribute 2108 lines: 2110 o If present, a single "a=ice-lite" line is parsed as specified in 2111 [RFC5245], Section 15.3, and a value indicating the presence of 2112 ice-lite is stored. 2114 o If present, a single "a=ice-ufrag" line is parsed as specified in 2115 [RFC5245], Section 15.4, and the ufrag value is stored. 2117 o If present, a single "a=ice-pwd" line is parsed as specified in 2118 [RFC5245], Section 15.4, and the password value is stored. 2120 o If present, a single "a=ice-options" line is parsed as specified 2121 in [RFC5245], Section 15.5, and the set of specified options is 2122 stored. 2124 o Any "a=fingerprint" lines are parsed as specified in [RFC4572], 2125 Section 5, and the set of fingerprint and algorithm values is 2126 stored. 2128 o If present, a single "a=setup" line is parsed as specified in 2129 [RFC4145], Section 4, and the setup value is stored. 2131 If the "m=" proto value indicates use of RTP, as decribed in the 2132 Section 5.1.3 section above, the following attribute lines MUST be 2133 processed: 2135 o The "m=" fmt value MUST be parsed as specified in [RFC4566], 2136 Section 5.14, and the individual values stored. 2138 o Any "a=rtpmap" or "a=fmtp" lines MUST be parsed as specified in 2139 [RFC4566], Section 6, and their values stored. 2141 o If present, a single "a=ptime" line MUST be parsed as described in 2142 [RFC4566], Section 6, and its value stored. 2144 o If present, a single direction attribute line (e.g. "a=sendrecv") 2145 MUST be parsed as described in [RFC4566], Section 6, and its value 2146 stored. 2148 o Any "a=ssrc" or "a=ssrc-group" attributes MUST be parsed as 2149 specified in [RFC5576], Sections 4.1-4.2, and their values stored. 2151 o Any "a=extmap" attributes MUST be parsed as specified in 2152 [RFC5285], Section 5, and their values stored. 2154 o Any "a=rtcp-fb" attributes MUST be parsed as specified in 2155 [RFC4585], Section 4.2., and their values stored. 2157 o If present, a single "a=rtcp-mux" line MUST be parsed as specified 2158 in [RFC5761], Section 5.1.1, and its presence or absence flagged 2159 and stored. 2161 o TODO: a=rtcp-rsize, a=rtcp, a=msid, a=candidate, a=end-of- 2162 candidates 2164 Otherwise, if the "m=" proto value indicats use of SCTP, the 2165 following attribute lines MUST be processed: 2167 o The "m=" fmt value MUST be parsed as specified in 2168 [I-D.ietf-mmusic-sctp-sdp], Section 4.3, and the application 2169 protocol value stored. 2171 o An "a=sctp-port" attribute MUST be present, and it MUST be parsed 2172 as specified in [I-D.ietf-mmusic-sctp-sdp], Section 5.2, and the 2173 value stored. 2175 o TODO: max message size 2177 5.6.3. Semantics Verification 2179 Assuming parsing completes successfully, the parsed description is 2180 then evaluated to ensure internal consistency as well as proper 2181 support for mandatory features. Specifically, the following checks 2182 are performed: 2184 o For each m= section, valid values for each of the mandatory-to-use 2185 features enumerated in Section 5.1.2 MUST be present. These 2186 values MAY either be present at the media level, or inherited from 2187 the session level. 2189 * ICE ufrag and password values 2191 * DTLS fingerprint and setup values 2193 If this session description is of type "pranswer" or "answer", the 2194 following additional checks are applied: 2196 o The session description must follow the rules defined in 2197 [RFC3264], Section 6. 2199 o For each m= section, the protocol value MUST exactly match the 2200 protocol value in the corresponding m= section in the associated 2201 offer. 2203 5.7. Applying a Local Description 2205 The following steps are performed at the media engine level to apply 2206 a local description. 2208 First, the parsed parameters are checked to ensure that any 2209 modifications performed fall within those explicitly permitted by 2210 Section 6; otherwise, processing MUST stop and an error MUST be 2211 returned. 2213 Next, media sections are processed. For each media section, the 2214 following steps MUST be performed; if any parameters are out of 2215 bounds, or cannot be applied, processing MUST stop and an error MUST 2216 be returned. 2218 o TODO 2220 Finally, if this description is of type "pranswer" or "answer", 2221 follow the processing defined in the Section 5.9 section below. 2223 5.8. Applying a Remote Description 2225 TODO 2227 5.9. Applying an Answer 2229 TODO 2231 6. Configurable SDP Parameters 2233 It is possible to change elements in the SDP returned from 2234 createOffer before passing it to setLocalDescription. When an 2235 implementation receives modified SDP it MUST either: 2237 o Accept the changes and adjust its behavior to match the SDP. 2239 o Reject the changes and return an error via the error callback. 2241 Changes MUST NOT be silently ignored. 2243 The following elements of the SDP media description MUST NOT be 2244 changed between the createOffer and the setLocalDescription (or 2245 between the createAnswer and the setLocalDescription), since they 2246 reflect transport attributes that are solely under browser control, 2247 and the browser MUST NOT honor an attempt to change them: 2249 o The number, type and port number of m= lines. 2251 o The generated ICE credentials (a=ice-ufrag and a=ice-pwd). 2253 o The set of ICE candidates and their parameters (a=candidate). 2255 o The DTLS fingerprint(s) (a=fingerprint). 2257 The following modifications, if done by the browser to a description 2258 between createOffer/createAnswer and the setLocalDescription, MUST be 2259 honored by the browser: 2261 o Remove or reorder codecs (m=) 2262 The following parameters may be controlled by options passed into 2263 createOffer/createAnswer. As an open issue, these changes may also 2264 be be performed by manipulating the SDP returned from createOffer/ 2265 createAnswer, as indicated above, as long as the capabilities of the 2266 endpoint are not exceeded (e.g. asking for a resolution greater than 2267 what the endpoint can encode): 2269 o [[OPEN ISSUE: This is a placeholder for other modifications, which 2270 we may continue adding as use cases appear.]] 2272 Implementations MAY choose to either honor or reject any elements not 2273 listed in the above two categories, but must do so explicitly as 2274 described at the beginning of this section. Note that future 2275 standards may add new SDP elements to the list of elements which must 2276 be accepted or rejected, but due to version skew, applications must 2277 be prepared for implementations to accept changes which must be 2278 rejected and vice versa. 2280 The application can also modify the SDP to reduce the capabilities in 2281 the offer it sends to the far side or the offer that it installs from 2282 the far side in any way the application sees fit, as long as it is a 2283 valid SDP offer and specifies a subset of what was in the original 2284 offer. This is safe because the answer is not permitted to expand 2285 capabilities and therefore will just respond to what is actually in 2286 the offer. 2288 As always, the application is solely responsible for what it sends to 2289 the other party, and all incoming SDP will be processed by the 2290 browser to the extent of its capabilities. It is an error to assume 2291 that all SDP is well-formed; however, one should be able to assume 2292 that any implementation of this specification will be able to 2293 process, as a remote offer or answer, unmodified SDP coming from any 2294 other implementation of this specification. 2296 7. Examples 2298 Note that this example section shows several SDP fragments. To 2299 format in 72 columns, some of the lines in SDP have been split into 2300 multiple lines, where leading whitespace indicates that a line is a 2301 continuation of the previous line. In addition, some blank lines 2302 have been added to improve readability but are not valid in SDP. 2304 More examples of SDP for WebRTC call flows can be found in 2305 [I-D.nandakumar-rtcweb-sdp]. 2307 7.1. Simple Example 2309 This section shows a very simple example that sets up a minimal audio 2310 / video call between two browsers and does not use trickle ICE. The 2311 example in the following section provides a more realistic example of 2312 what would happen in a normal browser to browser connection. 2314 The flow shows Alice's browser initiating the session to Bob's 2315 browser. The messages from Alice's JS to Bob's JS are assumed to 2316 flow over some signaling protocol via a web server. The JS on both 2317 Alice's side and Bob's side waits for all candidates before sending 2318 the offer or answer, so the offers and answers are complete. Trickle 2319 ICE is not used. Both Alice and Bob are using the default policy of 2320 balanced. 2322 // set up local media state 2323 AliceJS->AliceUA: create new PeerConnection 2324 AliceJS->AliceUA: addStream with stream containing audio and video 2325 AliceJS->AliceUA: createOffer to get offer 2326 AliceJS->AliceUA: setLocalDescription with offer 2327 AliceUA->AliceJS: multiple onicecandidate events with candidates 2329 // wait for ICE gathering to complete 2330 AliceUA->AliceJS: onicecandidate event with null candidate 2331 AliceJS->AliceUA: get |offer-A1| from value of localDescription 2333 // |offer-A1| is sent over signaling protocol to Bob 2334 AliceJS->WebServer: signaling with |offer-A1| 2335 WebServer->BobJS: signaling with |offer-A1| 2337 // |offer-A1| arrives at Bob 2338 BobJS->BobUA: create a PeerConnection 2339 BobJS->BobUA: setRemoteDescription with |offer-A1| 2340 BobUA->BobJS: onaddstream event with remoteStream 2342 // Bob accepts call 2343 BobJS->BobUA: addStream with local media 2344 BobJS->BobUA: createAnswer 2345 BobJS->BobUA: setLocalDescription with answer 2346 BobUA->BobJS: multiple onicecandidate events with candidates 2348 // wait for ICE gathering to complete 2349 BobUA->BobJS: onicecandidate event with null candidate 2350 BobJS->BobUA: get |answer-A1| from value of localDescription 2352 // |answer-A1| is sent over signaling protocol to Alice 2353 BobJS->WebServer: signaling with |answer-A1| 2354 WebServer->AliceJS: signaling with |answer-A1| 2356 // |answer-A1| arrives at Alice 2357 AliceJS->AliceUA: setRemoteDescription with |answer-A1| 2358 AliceUA->AliceJS: onaddstream event with remoteStream 2360 // media flows 2361 BobUA->AliceUA: media sent from Bob to Alice 2362 AliceUA->BobUA: media sent from Alice to Bob 2364 The SDP for |offer-A1| looks like: 2366 v=0 2367 o=- 4962303333179871722 1 IN IP4 0.0.0.0 2368 s=- 2369 t=0 0 2370 a=msid-semantic:WMS 2371 a=group:BUNDLE a1 v1 2372 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 2373 c=IN IP4 192.0.2.1 2374 a=mid:a1 2375 a=rtcp:56501 IN IP4 192.0.2.1 2376 a=msid:47017fee-b6c1-4162-929c-a25110252400 2377 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 2378 a=sendrecv 2379 a=rtpmap:96 opus/48000/2 2380 a=rtpmap:0 PCMU/8000 2381 a=rtpmap:8 PCMA/8000 2382 a=rtpmap:97 telephone-event/8000 2383 a=rtpmap:98 telephone-event/48000 2384 a=maxptime:120 2385 a=ice-ufrag:ETEn1v9DoTMB9J4r 2386 a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl 2387 a=ice-options:trickle 2388 a=fingerprint:sha-256 2389 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2390 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2391 a=setup:actpass 2392 a=rtcp-mux 2393 a=rtcp-rsize 2394 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2395 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2396 a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7 2397 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500 2398 typ host 2399 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501 2400 typ host 2401 a=end-of-candidates 2403 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 2404 c=IN IP4 192.0.2.1 2405 a=rtcp:56503 IN IP4 192.0.2.1 2406 a=mid:v1 2407 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 2408 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 2409 a=sendrecv 2410 a=rtpmap:100 VP8/90000 2411 a=rtpmap:101 rtx/90000 2412 a=fmtp:101 apt=100 2413 a=ice-ufrag:BGKkWnG5GmiUpdIV 2414 a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf 2415 a=ice-options:trickle 2416 a=fingerprint:sha-256 2417 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2419 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2420 a=setup:actpass 2421 a=rtcp-mux 2422 a=rtcp-rsize 2423 a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid 2424 a=rtcp-fb:100 ccm fir 2425 a=rtcp-fb:100 nack 2426 a=rtcp-fb:100 nack pli 2427 a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7 2428 a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7 2429 a=ssrc-group:FID 1366781083 1366781084 2430 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502 2431 typ host 2432 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503 2433 typ host 2434 a=end-of-candidates 2436 The SDP for |answer-A1| looks like: 2438 v=0 2439 o=- 6729291447651054566 1 IN IP4 0.0.0.0 2440 s=- 2441 t=0 0 2442 a=msid-semantic:WMS 2443 m=audio 20000 UDP/TLS/RTP/SAVPF 96 0 8 97 98 2444 c=IN IP4 192.0.2.2 2445 a=mid:a1 2446 a=rtcp:20000 IN IP4 192.0.2.2 2447 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2448 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 2449 a=sendrecv 2450 a=rtpmap:96 opus/48000/2 2451 a=rtpmap:0 PCMU/8000 2452 a=rtpmap:8 PCMA/8000 2453 a=rtpmap:97 telephone-event/8000 2454 a=rtpmap:98 telephone-event/48000 2455 a=maxptime:120 2456 a=ice-ufrag:6sFvz2gdLkEwjZEr 2457 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2458 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2459 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2460 a=setup:active 2461 a=rtcp-mux 2462 a=rtcp-rsize 2463 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2464 a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5 2465 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2466 typ host 2468 a=end-of-candidates 2470 m=video 20001 UDP/TLS/RTP/SAVPF 100 101 2471 c=IN IP4 192.0.2.2 2472 a=rtcp 20001 IN IP4 192.0.2.2 2473 a=mid:v1 2474 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2475 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0 2476 a=sendrecv 2477 a=rtpmap:100 VP8/90000 2478 a=rtpmap:101 rtx/90000 2479 a=fmtp:101 apt=100 2480 a=ice-ufrag:6sFvz2gdLkEwjZEr 2481 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2482 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2483 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2484 a=setup:active 2485 a=rtcp-mux 2486 a=rtcp-rsize 2487 a=rtcp-fb:100 ccm fir 2488 a=rtcp-fb:100 nack 2489 a=rtcp-fb:100 nack pli 2490 a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5 2491 a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5 2492 a=ssrc-group:FID 3229706345 3229706346 2493 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20001 2494 typ host 2495 a=end-of-candidates 2497 7.2. Normal Examples 2499 This section shows a typical example of a session between two 2500 browsers setting up an audio channel and a data channel. Trickle ICE 2501 is used in full trickle mode with a bundle policy of max-bundle, an 2502 RTCP mux policy of require, and a single TURN server. Later, two 2503 video flows, one for the presenter and one for screen sharing, are 2504 added to the session. This example shows Alice's browser initiating 2505 the session to Bob's browser. The messages from Alice's JS to Bob's 2506 JS are assumed to flow over some signaling protocol via a web server. 2508 // set up local media state 2509 AliceJS->AliceUA: create new PeerConnection 2510 AliceJS->AliceUA: addStream that contains audio track 2511 AliceJS->AliceUA: createDataChannel to get data channel 2512 AliceJS->AliceUA: createOffer to get |offer-B1| 2513 AliceJS->AliceUA: setLocalDescription with |offer-B1| 2515 // |offer-B1| is sent over signaling protocol to Bob 2516 AliceJS->WebServer: signaling with |offer-B1| 2517 WebServer->BobJS: signaling with |offer-B1| 2519 // |offer-B1| arrives at Bob 2520 BobJS->BobUA: create a PeerConnection 2521 BobJS->BobUA: setRemoteDescription with |offer-B1| 2522 BobUA->BobJS: onaddstream with audio track from Alice 2524 // candidates are sent to Bob 2525 AliceUA->AliceJS: onicecandidate event with |candidate-B1| (host) 2526 AliceJS->WebServer: signaling with |candidate-B1| 2527 AliceUA->AliceJS: onicecandidate event with |candidate-B2| (srflx) 2528 AliceJS->WebServer: signaling with |candidate-B2| 2529 AliceUA->AliceJS: onicecandidate event with |candidate-B3| (relay) 2530 AliceJS->WebServer: signaling with |candidate-B3| 2532 WebServer->BobJS: signaling with |candidate-B1| 2533 BobJS->BobUA: addIceCandidate with |candidate-B1| 2534 WebServer->BobJS: signaling with |candidate-B2| 2535 BobJS->BobUA: addIceCandidate with |candidate-B2| 2536 WebServer->BobJS: signaling with |candidate-B3| 2537 BobJS->BobUA: addIceCandidate with |candidate-B3| 2539 // Bob accepts call 2540 BobJS->BobUA: addStream with local audio stream 2541 BobJS->BobUA: createDataChannel to get data channel 2542 BobJS->BobUA: createAnswer to get |answer-B1| 2543 BobJS->BobUA: setLocalDescription with |answer-B1| 2545 // |answer-B1| is sent to Alice 2546 BobJS->WebServer: signaling with |answer-B1| 2547 WebServer->AliceJS: signaling with |answer-B1| 2548 AliceJS->AliceUA: setRemoteDescription with |answer-B1| 2549 AliceUA->AliceJS: onaddstream event with audio track from Bob 2551 // candidates are sent to Alice 2552 BobUA->BobJS: onicecandidate event with |candidate-B4| (host) 2553 BobJS->WebServer: signaling with |candidate-B4| 2554 BobUA->BobJS: onicecandidate event with |candidate-B5| (srflx) 2555 BobJS->WebServer: signaling with |candidate-B5| 2556 BobUA->BobJS: onicecandidate event with |candidate-B6| (relay) 2557 BobJS->WebServer: signaling with |candidate-B6| 2559 WebServer->AliceJS: signaling with |candidate-B4| 2560 AliceJS->AliceUA: addIceCandidate with |candidate-B4| 2561 WebServer->AliceJS: signaling with |candidate-B5| 2562 AliceJS->AliceUA: addIceCandidate with |candidate-B5| 2563 WebServer->AliceJS: signaling with |candidate-B6| 2564 AliceJS->AliceUA: addIceCandidate with |candidate-B6| 2566 // data channel opens 2567 BobUA->BobJS: ondatachannel event 2568 AliceUA->AliceJS: ondatachannel event 2569 BobUA->BobJS: onopen 2570 AliceUA->AliceJS: onopen 2572 // media is flowing between browsers 2573 BobUA->AliceUA: audio+data sent from Bob to Alice 2574 AliceUA->BobUA: audio+data sent from Alice to Bob 2576 // some time later Bob adds two video streams 2577 // note, no candidates exchanged, because of BUNDLE 2578 BobJS->BobUA: addStream with first video stream 2579 BobJS->BobUA: addStream with second video stream 2580 BobJS->BobUA: createOffer to get |offer-B2| 2581 BobJS->BobUA: setLocalDescription with |offer-B2| 2583 // |offer-B2| is sent to Alice 2584 BobJS->WebServer: signaling with |offer-B2| 2585 WebServer->AliceJS: signaling with |offer-B2| 2586 AliceJS->AliceUA: setRemoteDescription with |offer-B2| 2587 AliceUA->AliceJS: onaddstream event with first video stream 2588 AliceUA->AliceJS: onaddstream event with second video stream 2589 AliceJS->AliceUA: createAnswer to get |answer-B2| 2590 AliceJS->AliceUA: setLocalDescription with |answer-B2| 2592 // |answer-B2| is sent over signaling protocol to Bob 2593 AliceJS->WebServer: signaling with |answer-B2| 2594 WebServer->BobJS: signaling with |answer-B2| 2595 BobJS->BobUA: setRemoteDescription with |answer-B2| 2597 // media is flowing between browsers 2598 BobUA->AliceUA: audio+video+data sent from Bob to Alice 2599 AliceUA->BobUA: audio+video+data sent from Alice to Bob 2601 The SDP for |offer-B1| looks like: 2603 v=0 2604 o=- 4962303333179871723 1 IN IP4 0.0.0.0 2605 s=- 2606 t=0 0 2607 a=msid-semantic:WMS 2608 a=group:BUNDLE a1 d1 2609 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 2610 c=IN IP6 :: 2611 a=rtcp:9 IN IP6 :: 2612 a=mid:a1 2613 a=msid:57017fee-b6c1-4162-929c-a25110252400 2614 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 2615 a=sendrecv 2616 a=rtpmap:96 opus/48000/2 2617 a=rtpmap:0 PCMU/8000 2618 a=rtpmap:8 PCMA/8000 2619 a=rtpmap:97 telephone-event/8000 2620 a=rtpmap:98 telephone-event/48000 2621 a=maxptime:120 2622 a=ice-ufrag:ATEn1v9DoTMB9J4r 2623 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 2624 a=ice-options:trickle 2625 a=fingerprint:sha-256 2626 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2627 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2628 a=setup:actpass 2629 a=rtcp-mux 2630 a=rtcp-rsize 2631 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2632 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2633 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 2635 m=application 9 UDP/DTLS/SCTP webrtc-datachannel 2636 c=IN IP6 :: 2637 a=mid:d1 2638 a=fmtp:webrtc-datachannel max-message-size=65536 2639 a=sctp-port 5000 2640 a=ice-ufrag:ATEn1v9DoTMB9J4r 2641 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 2642 a=ice-options:trickle 2643 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2644 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2645 a=setup:actpass 2647 The SDP for |candidate-B1| looks like: 2649 candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host 2650 The SDP for |candidate-B2| looks like: 2652 candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx 2653 raddr 192.168.1.2 rport 51556 2655 The SDP for |candidate-B3| looks like: 2657 candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay 2658 raddr 11.22.33.44 rport 52546 2660 The SDP for |answer-B1| looks like: 2662 v=0 2663 o=- 7729291447651054566 1 IN IP4 0.0.0.0 2664 s=- 2665 t=0 0 2666 a=msid-semantic:WMS 2667 a=group:BUNDLE a1 d1 2668 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 2669 c=IN IP6 :: 2670 a=rtcp:9 IN IP6 :: 2671 a=mid:a1 2672 a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2673 QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 2674 a=sendrecv 2675 a=rtpmap:96 opus/48000/2 2676 a=rtpmap:0 PCMU/8000 2677 a=rtpmap:8 PCMA/8000 2678 a=rtpmap:97 telephone-event/8000 2679 a=rtpmap:98 telephone-event/48000 2680 a=maxptime:120 2681 a=ice-ufrag:7sFvz2gdLkEwjZEr 2682 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 2683 a=ice-options:trickle 2684 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2685 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2686 a=setup:active 2687 a=rtcp-mux 2688 a=rtcp-rsize 2689 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2690 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2691 a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 2693 m=application 9 UDP/DTLS/SCTP webrtc-datachannel 2694 c=IN IP6 :: 2695 a=mid:d1 2696 a=fmtp:webrtc-datachannel max-message-size=65536 2697 a=sctp-port 5000 2698 a=ice-ufrag:7sFvz2gdLkEwjZEr 2699 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 2700 a=ice-options:trickle 2701 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2702 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2703 a=setup:active 2705 The SDP for |candidate-B4| looks like: 2707 candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 2709 The SDP for |candidate-B5| looks like: 2711 candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx 2712 raddr 192.168.2.3 rport 61665 2714 The SDP for |candidate-B6| looks like: 2716 candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay 2717 raddr 55.66.77.88 rport 64532 2719 The SDP for |offer-B2| looks like: (note the increment of the version 2720 number in the o= line, and the c= and a=rtcp lines, which indicate 2721 the local candidate that was selected) 2723 v=0 2724 o=- 7729291447651054566 2 IN IP4 0.0.0.0 2725 s=- 2726 t=0 0 2727 a=msid-semantic:WMS 2728 a=group:BUNDLE a1 d1 v1 v2 2729 m=audio 64532 UDP/TLS/RTP/SAVPF 96 0 8 97 98 2730 c=IN IP4 55.66.77.88 2731 a=rtcp:64532 IN IP4 55.66.77.88 2732 a=mid:a1 2733 a=msid:QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2734 QI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 2735 a=sendrecv 2736 a=rtpmap:96 opus/48000/2 2737 a=rtpmap:0 PCMU/8000 2738 a=rtpmap:8 PCMA/8000 2739 a=rtpmap:97 telephone-event/8000 2740 a=rtpmap:98 telephone-event/48000 2741 a=maxptime:120 2742 a=ice-ufrag:7sFvz2gdLkEwjZEr 2743 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 2744 a=ice-options:trickle 2745 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2746 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2747 a=setup:actpass 2748 a=rtcp-mux 2749 a=rtcp-rsize 2750 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2751 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2752 a=ssrc:4429951804 cname:Q/NWs1ao1HmN4Xa5 2753 a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 2754 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx 2755 raddr 192.168.2.3 rport 61665 2756 a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay 2757 raddr 55.66.77.88 rport 64532 2758 a=end-of-candidates 2759 m=application 64532 UDP/DTLS/SCTP webrtc-datachannel 2760 c=IN IP4 55.66.77.88 2761 a=mid:d1 2762 a=fmtp:webrtc-datachannel max-message-size=65536 2763 a=sctp-port 5000 2764 a=ice-ufrag:7sFvz2gdLkEwjZEr 2765 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 2766 a=ice-options:trickle 2767 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2768 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2769 a=setup:actpass 2770 a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 2771 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx 2772 raddr 192.168.2.3 rport 61665 2773 a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay 2774 raddr 55.66.77.88 rport 64532 2775 a=end-of-candidates 2777 m=video 64532 UDP/TLS/RTP/SAVPF 100 101 2778 c=IN IP4 55.66.77.88 2779 a=rtcp:64532 IN IP4 55.66.77.88 2780 a=mid:v1 2781 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 2782 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 2783 a=sendrecv 2784 a=rtpmap:100 VP8/90000 2785 a=rtpmap:101 rtx/90000 2786 a=fmtp:101 apt=100 2787 a=ice-ufrag:7sFvz2gdLkEwjZEr 2788 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 2789 a=ice-options:trickle 2790 a=fingerprint:sha-256 2791 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2792 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2793 a=setup:actpass 2794 a=rtcp-mux 2795 a=rtcp-rsize 2796 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2797 a=rtcp-fb:100 ccm fir 2798 a=rtcp-fb:100 nack 2799 a=rtcp-fb:100 nack pli 2800 a=ssrc:1366781083 cname:Q/NWs1ao1HmN4Xa5 2801 a=ssrc:1366781084 cname:Q/NWs1ao1HmN4Xa5 2802 a=ssrc-group:FID 1366781083 1366781084 2803 a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 2804 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx 2805 raddr 192.168.2.3 rport 61665 2806 a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay 2807 raddr 55.66.77.88 rport 64532 2808 a=end-of-candidates 2810 m=video 64532 UDP/TLS/RTP/SAVPF 100 101 2811 c=IN IP4 55.66.77.88 2812 a=rtcp:64532 IN IP4 55.66.77.88 2813 a=mid:v1 2814 a=msid:71317484-2ed4-49d7-9eb7-1414322a7aae 2815 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 2816 a=sendrecv 2817 a=rtpmap:100 VP8/90000 2818 a=rtpmap:101 rtx/90000 2819 a=fmtp:101 apt=100 2820 a=ice-ufrag:7sFvz2gdLkEwjZEr 2821 a=ice-pwd:dOTZKZNVlO9RSGsEGM63JXT2 2822 a=ice-options:trickle 2823 a=fingerprint:sha-256 2824 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2825 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2826 a=setup:actpass 2827 a=rtcp-mux 2828 a=rtcp-rsize 2829 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2830 a=rtcp-fb:100 ccm fir 2831 a=rtcp-fb:100 nack 2832 a=rtcp-fb:100 nack pli 2833 a=ssrc:2366781083 cname:Q/NWs1ao1HmN4Xa5 2834 a=ssrc:2366781084 cname:Q/NWs1ao1HmN4Xa5 2835 a=ssrc-group:FID 2366781083 2366781084 2836 a=candidate:109270924 1 udp 2122194687 192.168.2.3 61665 typ host 2837 a=candidate:4036177504 1 udp 1685987071 55.66.77.88 64532 typ srflx 2838 raddr 192.168.2.3 rport 61665 2839 a=candidate:3671762467 1 udp 41819903 66.77.88.99 50416 typ relay 2840 raddr 55.66.77.88 rport 64532 2841 a=end-of-candidates 2843 The SDP for |answer-B2| looks like: (note the use of setup:passive to 2844 maintain the existing DTLS roles, and the use of a=recvonly to 2845 indicate that the video streams are one-way) 2847 v=0 2848 o=- 4962303333179871723 2 IN IP4 0.0.0.0 2849 s=- 2850 t=0 0 2851 a=msid-semantic:WMS 2852 a=group:BUNDLE a1 d1 v1 v2 2853 m=audio 52546 UDP/TLS/RTP/SAVPF 96 0 8 97 98 2854 c=IN IP4 11.22.33.44 2855 a=rtcp:52546 IN IP4 11.22.33.44 2856 a=mid:a1 2857 a=msid:57017fee-b6c1-4162-929c-a25110252400 2858 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 2859 a=sendrecv 2860 a=rtpmap:96 opus/48000/2 2861 a=rtpmap:0 PCMU/8000 2862 a=rtpmap:8 PCMA/8000 2863 a=rtpmap:97 telephone-event/8000 2864 a=rtpmap:98 telephone-event/48000 2865 a=maxptime:120 2866 a=ice-ufrag:ATEn1v9DoTMB9J4r 2867 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 2868 a=ice-options:trickle 2869 a=fingerprint:sha-256 2870 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2871 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2872 a=setup:passive 2873 a=rtcp-mux 2874 a=rtcp-rsize 2875 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2876 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2877 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 2878 a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host 2879 a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx 2880 raddr 192.168.1.2 rport 51556 2881 a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay 2882 raddr 11.22.33.44 rport 52546 2883 a=end-of-candidates 2885 m=application 52546 UDP/DTLS/SCTP webrtc-datachannel 2886 c=IN IP4 11.22.33.44 2887 a=mid:d1 2888 a=fmtp:webrtc-datachannel max-message-size=65536 2889 a=sctp-port 5000 2890 a=ice-ufrag:ATEn1v9DoTMB9J4r 2891 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 2892 a=ice-options:trickle 2893 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2894 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2895 a=setup:passive 2896 a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host 2897 a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx 2898 raddr 192.168.1.2 rport 51556 2899 a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay 2900 raddr 11.22.33.44 rport 52546 2901 a=end-of-candidates 2902 m=video 52546 UDP/TLS/RTP/SAVPF 100 101 2903 c=IN IP4 11.22.33.44 2904 a=rtcp:52546 IN IP4 11.22.33.44 2905 a=mid:v1 2906 a=recvonly 2907 a=rtpmap:100 VP8/90000 2908 a=rtpmap:101 rtx/90000 2909 a=fmtp:101 apt=100 2910 a=ice-ufrag:ATEn1v9DoTMB9J4r 2911 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 2912 a=ice-options:trickle 2913 a=fingerprint:sha-256 2914 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2915 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2916 a=setup:passive 2917 a=rtcp-mux 2918 a=rtcp-rsize 2919 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2920 a=rtcp-fb:100 ccm fir 2921 a=rtcp-fb:100 nack 2922 a=rtcp-fb:100 nack pli 2923 a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host 2924 a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx 2925 raddr 192.168.1.2 rport 51556 2926 a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay 2927 raddr 11.22.33.44 rport 52546 2928 a=end-of-candidates 2930 m=video 52546 UDP/TLS/RTP/SAVPF 100 101 2931 c=IN IP4 11.22.33.44 2932 a=rtcp:52546 IN IP4 11.22.33.44 2933 a=mid:v2 2934 a=recvonly 2935 a=rtpmap:100 VP8/90000 2936 a=rtpmap:101 rtx/90000 2937 a=fmtp:101 apt=100 2938 a=ice-ufrag:ATEn1v9DoTMB9J4r 2939 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 2940 a=ice-options:trickle 2941 a=fingerprint:sha-256 2942 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2943 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2944 a=setup:passive 2945 a=rtcp-mux 2946 a=rtcp-rsize 2947 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 2948 a=rtcp-fb:100 ccm fir 2949 a=rtcp-fb:100 nack 2950 a=rtcp-fb:100 nack pli 2951 a=candidate:109270923 1 udp 2122194687 192.168.1.2 51556 typ host 2952 a=candidate:4036177503 1 udp 1685987071 11.22.33.44 52546 typ srflx 2953 raddr 192.168.1.2 rport 51556 2954 a=candidate:3671762466 1 udp 41819903 22.33.44.55 61405 typ relay 2955 raddr 11.22.33.44 rport 52546 2956 a=end-of-candidates 2958 8. Security Considerations 2960 The IETF has published separate documents 2961 [I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security] describing 2962 the security architecture for WebRTC as a whole. The remainder of 2963 this section describes security considerations for this document. 2965 While formally the JSEP interface is an API, it is better to think of 2966 it is an Internet protocol, with the JS being untrustworthy from the 2967 perspective of the browser. Thus, the threat model of [RFC3552] 2968 applies. In particular, JS can call the API in any order and with 2969 any inputs, including malicious ones. This is particularly relevant 2970 when we consider the SDP which is passed to setLocalDescription(). 2971 While correct API usage requires that the application pass in SDP 2972 which was derived from createOffer() or createAnswer() (perhaps 2973 suitably modified as described in Section 6, there is no guarantee 2974 that applications do so. The browser MUST be prepared for the JS to 2975 pass in bogus data instead. 2977 Conversely, the application programmer MUST recognize that the JS 2978 does not have complete control of browser behavior. One case that 2979 bears particular mention is that editing ICE candidates out of the 2980 SDP or suppressing trickled candidates does not have the expected 2981 behavior: implementations will still perform checks from those 2982 candidates even if they are not sent to the other side. Thus, for 2983 instance, it is not possible to prevent the remote peer from learning 2984 your public IP address by removing server reflexive candidates. 2985 Applications which wish to conceal their public IP address should 2986 instead configure the ICE agent to use only relay candidates. 2988 9. IANA Considerations 2990 This document requires no actions from IANA. 2992 10. Acknowledgements 2994 Significant text incorporated in the draft as well and review was 2995 provided by Harald Alvestrand and Suhas Nandakumar. Dan Burnett, 2996 Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton, 2997 Richard Ejzak, Adam Bergkvist and Matthew Kaufman all provided 2998 valuable feedback on this proposal. 3000 11. References 3002 11.1. Normative References 3004 [I-D.ietf-mmusic-msid] 3005 Alvestrand, H., "Cross Session Stream Identification in 3006 the Session Description Protocol", draft-ietf-mmusic- 3007 msid-01 (work in progress), August 2013. 3009 [I-D.ietf-mmusic-sctp-sdp] 3010 Loreto, S. and G. Camarillo, "Stream Control Transmission 3011 Protocol (SCTP)-Based Media Transport in the Session 3012 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 3013 (work in progress), June 2013. 3015 [I-D.ietf-mmusic-sdp-bundle-negotiation] 3016 Holmberg, C., Alvestrand, H., and C. Jennings, 3017 "Multiplexing Negotiation Using Session Description 3018 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 3019 bundle-negotiation-04 (work in progress), June 2013. 3021 [I-D.ietf-mmusic-sdp-mux-attributes] 3022 Nandakumar, S., "A Framework for SDP Attributes when 3023 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-01 3024 (work in progress), February 2014. 3026 [I-D.ietf-mmusic-trickle-ice] 3027 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 3028 Incremental Provisioning of Candidates for the Interactive 3029 Connectivity Establishment (ICE) Protocol", draft-ietf- 3030 mmusic-trickle-ice-00 (work in progress), March 2013. 3032 [I-D.ietf-rtcweb-audio] 3033 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 3034 Requirements", draft-ietf-rtcweb-audio-02 (work in 3035 progress), August 2013. 3037 [I-D.ietf-rtcweb-data-protocol] 3038 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 3039 Protocol", draft-ietf-rtcweb-data-protocol-04 (work in 3040 progress), February 2013. 3042 [I-D.ietf-rtcweb-fec] 3043 Uberti, J., "WebRTC Forward Error Correction 3044 Requirements", draft-ietf-rtcweb-fec-00 (work in 3045 progress), February 2015. 3047 [I-D.ietf-rtcweb-rtp-usage] 3048 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 3049 Communication (WebRTC): Media Transport and Use of RTP", 3050 draft-ietf-rtcweb-rtp-usage-09 (work in progress), 3051 September 2013. 3053 [I-D.ietf-rtcweb-security] 3054 Rescorla, E., "Security Considerations for WebRTC", draft- 3055 ietf-rtcweb-security-06 (work in progress), January 2014. 3057 [I-D.ietf-rtcweb-security-arch] 3058 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 3059 rtcweb-security-arch-09 (work in progress), February 2014. 3061 [I-D.ietf-rtcweb-video] 3062 Roach, A., "WebRTC Video Processing and Codec 3063 Requirements", draft-ietf-rtcweb-video-00 (work in 3064 progress), July 2014. 3066 [I-D.nandakumar-mmusic-proto-iana-registration] 3067 Nandakumar, S., "IANA registration of SDP 'proto' 3068 attribute for transporting RTP Media over TCP under 3069 various RTP profiles.", September 2014. 3071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3072 Requirement Levels", BCP 14, RFC 2119, March 1997. 3074 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3075 A., Peterson, J., Sparks, R., Handley, M., and E. 3076 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3077 June 2002. 3079 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 3080 with Session Description Protocol (SDP)", RFC 3264, June 3081 2002. 3083 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3084 Text on Security Considerations", BCP 72, RFC 3552, July 3085 2003. 3087 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 3088 in Session Description Protocol (SDP)", RFC 3605, October 3089 2003. 3091 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 3092 the Session Description Protocol (SDP)", RFC 4145, 3093 September 2005. 3095 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 3096 Description Protocol", RFC 4566, July 2006. 3098 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 3099 Transport Layer Security (TLS) Protocol in the Session 3100 Description Protocol (SDP)", RFC 4572, July 2006. 3102 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 3103 "Extended RTP Profile for Real-time Transport Control 3104 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 3105 2006. 3107 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 3108 Real-time Transport Control Protocol (RTCP)-Based Feedback 3109 (RTP/SAVPF)", RFC 5124, February 2008. 3111 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 3112 (ICE): A Protocol for Network Address Translator (NAT) 3113 Traversal for Offer/Answer Protocols", RFC 5245, April 3114 2010. 3116 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 3117 Header Extensions", RFC 5285, July 2008. 3119 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 3120 Control Packets on a Single Port", RFC 5761, April 2010. 3122 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 3123 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 3125 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3126 Security Version 1.2", RFC 6347, January 2012. 3128 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 3129 Real-time Transport Protocol (SRTP)", RFC 6904, April 3130 2013. 3132 [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, 3133 "Guidelines for Choosing RTP Control Protocol (RTCP) 3134 Canonical Names (CNAMEs)", RFC 7022, September 2013. 3136 11.2. Informative References 3138 [I-D.nandakumar-rtcweb-sdp] 3139 Nandakumar, S. and C. Jennings, "SDP for the WebRTC", 3140 draft-nandakumar-rtcweb-sdp-02 (work in progress), July 3141 2013. 3143 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 3144 Comfort Noise (CN)", RFC 3389, September 2002. 3146 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 3147 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3148 3556, July 2003. 3150 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 3151 Tone Generation in the Session Initiation Protocol (SIP)", 3152 RFC 3960, December 2004. 3154 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 3155 Description Protocol (SDP) Security Descriptions for Media 3156 Streams", RFC 4568, July 2006. 3158 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 3159 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 3160 July 2006. 3162 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 3163 Real-Time Transport Control Protocol (RTCP): Opportunities 3164 and Consequences", RFC 5506, April 2009. 3166 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 3167 Media Attributes in the Session Description Protocol 3168 (SDP)", RFC 5576, June 2009. 3170 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 3171 for Establishing a Secure Real-time Transport Protocol 3172 (SRTP) Security Context Using Datagram Transport Layer 3173 Security (DTLS)", RFC 5763, May 2010. 3175 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 3176 Security (DTLS) Extension to Establish Keys for the Secure 3177 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 3179 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 3180 the Session Description Protocol", RFC 5956, September 3181 2010. 3183 [W3C.WD-webrtc-20140617] 3184 Bergkvist, A., Burnett, D., Narayanan, A., and C. 3185 Jennings, "WebRTC 1.0: Real-time Communication Between 3186 Browsers", World Wide Web Consortium WD WD-webrtc- 3187 20140617, June 2014, 3188 . 3190 Appendix A. Change log 3192 Note: This section will be removed by RFC Editor before publication. 3194 Changes in draft-09:"> 3196 o Don't return null for {local,remote}Description after close(). 3198 o Changed TCP/TLS to UDP/DTLS in RTP profile names. 3200 o Separate out bundle and mux policy. 3202 o Added specific references to FEC mechanisms. 3204 o Added canTrickle mechanism. 3206 o Added section on subsequent answers and, answer options. 3208 o Added text defining set{Local,Remote}Description behavior. 3210 Changes in draft-08: 3212 o Added new example section and removed old examples in appendix. 3214 o Fixed field handling. 3216 o Added text describing a=rtcp attribute. 3218 o Reworked handling of OfferToReceiveAudio and OfferToReceiveVideo 3219 per discussion at IETF 90. 3221 o Reworked trickle ICE handling and its impact on m= and c= lines 3222 per discussion at interim. 3224 o Added max-bundle-and-rtcp-mux policy. 3226 o Added description of maxptime handling. 3228 o Updated ICE candidate pool default to 0. 3230 o Resolved open issues around AppID/receiver-ID. 3232 o Reworked and expanded how changes to the ICE configuration are 3233 handled. 3235 o Some reference updates. 3237 o Editorial clarification. 3239 Changes in draft-07: 3241 o Expanded discussion of VAD and Opus DTX. 3243 o Added a security considerations section. 3245 o Rewrote the section on modifying SDP to require implementations to 3246 clearly indicate whether any given modification is allowed. 3248 o Clarified impact of IceRestart on CreateOffer in local-offer 3249 state. 3251 o Guidance on whether attributes should be defined at the media 3252 level or the session level. 3254 o Renamed "default" bundle policy to "balanced". 3256 o Removed default ICE candidate pool size and clarify how it works. 3258 o Defined a canonical order for assignment of MSTs to m= lines. 3260 o Removed discussion of rehydration. 3262 o Added Eric Rescorla as a draft editor. 3264 o Cleaned up references. 3266 o Editorial cleanup 3268 Changes in draft-06: 3270 o Reworked handling of m= line recycling. 3272 o Added handling of BUNDLE and bundle-only. 3274 o Clarified handling of rollback. 3276 o Added text describing the ICE Candidate Pool and its behavior. 3278 o Allowed OfferToReceiveX to create multiple recvonly m= sections. 3280 Changes in draft-05: 3282 o Fixed several issues identified in the createOffer/Answer sections 3283 during document review. 3285 o Updated references. 3287 Changes in draft-04: 3289 o Filled in sections on createOffer and createAnswer. 3291 o Added SDP examples. 3293 o Fixed references. 3295 Changes in draft-03: 3297 o Added text describing relationship to W3C specification 3299 Changes in draft-02: 3301 o Converted from nroff 3303 o Removed comparisons to old approaches abandoned by the working 3304 group 3306 o Removed stuff that has moved to W3C specification 3308 o Align SDP handling with W3C draft 3310 o Clarified section on forking. 3312 Changes in draft-01: 3314 o Added diagrams for architecture and state machine. 3316 o Added sections on forking and rehydration. 3318 o Clarified meaning of "pranswer" and "answer". 3320 o Reworked how ICE restarts and media directions are controlled. 3322 o Added list of parameters that can be changed in a description. 3324 o Updated suggested API and examples to match latest thinking. 3326 o Suggested API and examples have been moved to an appendix. 3328 Changes in draft -00: 3330 o Migrated from draft-uberti-rtcweb-jsep-02. 3332 Authors' Addresses 3334 Justin Uberti 3335 Google 3336 747 6th Ave S 3337 Kirkland, WA 98033 3338 USA 3340 Email: justin@uberti.name 3342 Cullen Jennings 3343 Cisco 3344 170 West Tasman Drive 3345 San Jose, CA 95134 3346 USA 3348 Email: fluffy@iii.ca 3350 Eric Rescorla (editor) 3351 Mozilla 3352 331 Evelyn Ave 3353 Mountain View, CA 94041 3354 USA 3356 Email: ekr@rtfm.com