idnits 2.17.1 draft-ietf-rtcweb-jsep-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3696 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) == Unused Reference: 'RFC5124' is defined on line 1767, 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 (-11) exists of draft-ietf-rtcweb-audio-02 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-rtp-usage-09 == Outdated reference: A later version (-05) exists of draft-nandakumar-mmusic-sdp-mux-attributes-03 ** 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) == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-trickle-ice-00 == Outdated reference: A later version (-09) exists of draft-ietf-rtcweb-data-protocol-04 == Outdated reference: A later version (-08) exists of draft-nandakumar-rtcweb-sdp-02 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 2 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: August 17, 2014 Cisco 6 February 13, 2014 8 Javascript Session Establishment Protocol 9 draft-ietf-rtcweb-jsep-06 11 Abstract 13 This document describes the mechanisms for allowing a Javascript 14 application to control the signaling plane of a multimedia session 15 via the interface specified in the W3C RTCPeerConnection API, and 16 discusses how this relates to existing signaling protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 17, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. General Design of JSEP . . . . . . . . . . . . . . . . . 3 54 1.2. Other Approaches Considered . . . . . . . . . . . . . . . 5 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Semantics and Syntax . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Signaling Model . . . . . . . . . . . . . . . . . . . . . 6 58 3.2. Session Descriptions and State Machine . . . . . . . . . 7 59 3.3. Session Description Format . . . . . . . . . . . . . . . 10 60 3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.4.1. ICE Candidate Trickling . . . . . . . . . . . . . . . 10 62 3.4.1.1. ICE Candidate Format . . . . . . . . . . . . . . 11 63 3.4.2. ICE Candidate Pool . . . . . . . . . . . . . . . . . 11 64 3.5. Interactions With Forking . . . . . . . . . . . . . . . . 12 65 3.5.1. Sequential Forking . . . . . . . . . . . . . . . . . 12 66 3.5.2. Parallel Forking . . . . . . . . . . . . . . . . . . 13 67 3.6. Session Rehydration . . . . . . . . . . . . . . . . . . . 14 68 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.1.1. Constructor . . . . . . . . . . . . . . . . . . . . . 14 71 4.1.2. createOffer . . . . . . . . . . . . . . . . . . . . . 15 72 4.1.3. createAnswer . . . . . . . . . . . . . . . . . . . . 16 73 4.1.4. SessionDescriptionType . . . . . . . . . . . . . . . 17 74 4.1.4.1. Use of Provisional Answers . . . . . . . . . . . 18 75 4.1.4.2. Rollback . . . . . . . . . . . . . . . . . . . . 18 76 4.1.5. setLocalDescription . . . . . . . . . . . . . . . . . 19 77 4.1.6. setRemoteDescription . . . . . . . . . . . . . . . . 20 78 4.1.7. localDescription . . . . . . . . . . . . . . . . . . 20 79 4.1.8. remoteDescription . . . . . . . . . . . . . . . . . . 20 80 4.1.9. updateIce . . . . . . . . . . . . . . . . . . . . . . 20 81 4.1.10. addIceCandidate . . . . . . . . . . . . . . . . . . . 21 82 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 21 83 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 21 84 5.1.1. Implementation Requirements . . . . . . . . . . . . . 21 85 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 23 86 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 23 87 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 23 88 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 27 89 5.2.3. Constraints Handling . . . . . . . . . . . . . . . . 29 90 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 30 91 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 30 92 5.2.3.3. VoiceActivityDetection . . . . . . . . . . . . . 30 93 5.2.3.4. IceRestart . . . . . . . . . . . . . . . . . . . 30 94 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 31 95 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 31 96 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 35 97 5.3.3. Constraints Handling . . . . . . . . . . . . . . . . 35 99 5.4. Parsing an Offer . . . . . . . . . . . . . . . . . . . . 35 100 5.5. Parsing an Answer . . . . . . . . . . . . . . . . . . . . 35 101 5.6. Applying a Local Description . . . . . . . . . . . . . . 35 102 5.7. Applying a Remote Description . . . . . . . . . . . . . . 35 103 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 35 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 109 10.2. Informative References . . . . . . . . . . . . . . . . . 38 110 Appendix A. JSEP Implementation Examples . . . . . . . . . . . . 40 111 A.1. Example API Flows . . . . . . . . . . . . . . . . . . . . 40 112 A.1.1. Call using ROAP . . . . . . . . . . . . . . . . . . . 40 113 A.1.2. Call using XMPP . . . . . . . . . . . . . . . . . . . 41 114 A.1.3. Adding video to a call, using XMPP . . . . . . . . . 43 115 A.1.4. Simultaneous add of video streams, using XMPP . . . . 43 116 A.1.5. Call using SIP . . . . . . . . . . . . . . . . . . . 44 117 A.1.6. Handling early media (e.g. 1-800-GO FEDEX), using SIP 45 118 A.2. Example Session Descriptions . . . . . . . . . . . . . . 46 119 A.2.1. createOffer . . . . . . . . . . . . . . . . . . . . . 46 120 A.2.2. createAnswer . . . . . . . . . . . . . . . . . . . . 48 121 A.2.3. Call Flows . . . . . . . . . . . . . . . . . . . . . 50 122 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 50 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 125 1. Introduction 127 This document describes how the W3C WEBRTC RTCPeerConnection 128 interface[W3C.WD-webrtc-20111027] is used to control the setup, 129 management and teardown of a multimedia session. 131 1.1. General Design of JSEP 133 The thinking behind WebRTC call setup has been to fully specify and 134 control the media plane, but to leave the signaling plane up to the 135 application as much as possible. The rationale is that different 136 applications may prefer to use different protocols, such as the 137 existing SIP or Jingle call signaling protocols, or something custom 138 to the particular application, perhaps for a novel use case. In this 139 approach, the key information that needs to be exchanged is the 140 multimedia session description, which specifies the necessary 141 transport and media configuration information necessary to establish 142 the media plane. 144 The browser environment also has its own challenges that pose 145 problems for an embedded signaling state machine. One of these is 146 that the user may reload the web page at any time. If the browser is 147 fully in charge of the signaling state, this will result in the loss 148 of the call when this state is wiped by the reload. However, if the 149 state can be stored at the server, and pushed back down to the new 150 page, the call can be resumed with minimal interruption. 152 With these considerations in mind, this document describes the 153 Javascript Session Establishment Protocol (JSEP) that allows for full 154 control of the signaling state machine from Javascript. This 155 mechanism effectively removes the browser almost completely from the 156 core signaling flow; the only interface needed is a way for the 157 application to pass in the local and remote session descriptions 158 negotiated by whatever signaling mechanism is used, and a way to 159 interact with the ICE state machine. 161 In this document, the use of JSEP is described as if it always occurs 162 between two browsers. Note though in many cases it will actually be 163 between a browser and some kind of server, such as a gateway or MCU. 164 This distinction is invisible to the browser; it just follows the 165 instructions it is given via the API. 167 JSEP's handling of session descriptions is simple and 168 straightforward. Whenever an offer/answer exchange is needed, the 169 initiating side creates an offer by calling a createOffer() API. The 170 application optionally modifies that offer, and then uses it to set 171 up its local config via the setLocalDescription() API. The offer is 172 then sent off to the remote side over its preferred signaling 173 mechanism (e.g., WebSockets); upon receipt of that offer, the remote 174 party installs it using the setRemoteDescription() API. 176 When the call is accepted, the callee uses the createAnswer() API to 177 generate an appropriate answer, applies it using 178 setLocalDescription(), and sends the answer back to the initiator 179 over the signaling channel. When the offerer gets that answer, it 180 installs it using setRemoteDescription(), and initial setup is 181 complete. This process can be repeated for additional offer/answer 182 exchanges. 184 Regarding ICE [RFC5245], JSEP decouples the ICE state machine from 185 the overall signaling state machine, as the ICE state machine must 186 remain in the browser, because only the browser has the necessary 187 knowledge of candidates and other transport info. Performing this 188 separation also provides additional flexibility; in protocols that 189 decouple session descriptions from transport, such as Jingle, the 190 transport information can be sent separately; in protocols that 191 don't, such as SIP, the information can be used in the aggregated 192 form. Sending transport information separately can allow for faster 193 ICE and DTLS startup, since the necessary roundtrips can occur while 194 waiting for the remote side to accept the session. 196 Through its abstraction of signaling, the JSEP approach does require 197 the application to be aware of the signaling process. While the 198 application does not need to understand the contents of session 199 descriptions to set up a call, the application must call the right 200 APIs at the right times, convert the session descriptions and ICE 201 information into the defined messages of its chosen signaling 202 protocol, and perform the reverse conversion on the messages it 203 receives from the other side. 205 One way to mitigate this is to provide a Javascript library that 206 hides this complexity from the developer; said library would 207 implement a given signaling protocol along with its state machine and 208 serialization code, presenting a higher level call-oriented interface 209 to the application developer. For example, this library could easily 210 adapt the JSEP API into the API that was proposed for the ROAP 211 signaling protocol [I-D.jennings-rtcweb-signaling], which would 212 perform a ROAP call setup under the covers, interacting with the 213 application only when it needs a signaling message to be sent. In 214 the same fashion, one could also implement other popular signaling 215 protocols, including SIP or Jingle. This allow JSEP to provide 216 greater control for the experienced developer without forcing any 217 additional complexity on the novice developer. 219 1.2. Other Approaches Considered 221 One approach that was considered instead of JSEP was to include a 222 lightweight signaling protocol. Instead of providing session 223 descriptions to the API, the API would produce and consume messages 224 from this protocol. While providing a more high-level API, this put 225 more control of signaling within the browser, forcing the browser to 226 have to understand and handle concepts like signaling glare. In 227 addition, it prevented the application from driving the state machine 228 to a desired state, as is needed in the page reload case. 230 A second approach that was considered but not chosen was to decouple 231 the management of the media control objects from session 232 descriptions, instead offering APIs that would control each component 233 directly. This was rejected based on a feeling that requiring 234 exposure of this level of complexity to the application programmer 235 would not be beneficial; it would result in an API where even a 236 simple example would require a significant amount of code to 237 orchestrate all the needed interactions, as well as creating a large 238 API surface that needed to be agreed upon and documented. In 239 addition, these API points could be called in any order, resulting in 240 a more complex set of interactions with the media subsystem than the 241 JSEP approach, which specifies how session descriptions are to be 242 evaluated and applied. 244 One variation on JSEP that was considered was to keep the basic 245 session description-oriented API, but to move the mechanism for 246 generating offers and answers out of the browser. Instead of 247 providing createOffer/createAnswer methods within the browser, this 248 approach would instead expose a getCapabilities API which would 249 provide the application with the information it needed in order to 250 generate its own session descriptions. This increases the amount of 251 work that the application needs to do; it needs to know how to 252 generate session descriptions from capabilities, and especially how 253 to generate the correct answer from an arbitrary offer and the 254 supported capabilities. While this could certainly be addressed by 255 using a library like the one mentioned above, it basically forces the 256 use of said library even for a simple example. Providing createOffer 257 /createAnswer avoids this problem, but still allows applications to 258 generate their own offers/answers (to a large extent) if they choose, 259 using the description generated by createOffer as an indication of 260 the browser's capabilities. 262 2. Terminology 264 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 265 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 266 document are to be interpreted as described in [RFC2119]. 268 3. Semantics and Syntax 270 3.1. Signaling Model 272 JSEP does not specify a particular signaling model or state machine, 273 other than the generic need to exchange SDP media descriptions in the 274 fashion described by [RFC3264] (offer/answer) in order for both sides 275 of the session to know how to conduct the session. JSEP provides 276 mechanisms to create offers and answers, as well as to apply them to 277 a session. However, the browser is totally decoupled from the actual 278 mechanism by which these offers and answers are communicated to the 279 remote side, including addressing, retransmission, forking, and glare 280 handling. These issues are left entirely up to the application; the 281 application has complete control over which offers and answers get 282 handed to the browser, and when. 284 +-----------+ +-----------+ 285 | Web App |<--- App-Specific Signaling -->| Web App | 286 +-----------+ +-----------+ 287 ^ ^ 288 | SDP | SDP 289 V V 290 +-----------+ +-----------+ 291 | Browser |<----------- Media ------------>| Browser | 292 +-----------+ +-----------+ 294 Figure 1: JSEP Signaling Model 296 3.2. Session Descriptions and State Machine 298 In order to establish the media plane, the user agent needs specific 299 parameters to indicate what to transmit to the remote side, as well 300 as how to handle the media that is received. These parameters are 301 determined by the exchange of session descriptions in offers and 302 answers, and there are certain details to this process that must be 303 handled in the JSEP APIs. 305 Whether a session description applies to the local side or the remote 306 side affects the meaning of that description. For example, the list 307 of codecs sent to a remote party indicates what the local side is 308 willing to receive, which, when intersected with the set of codecs 309 the remote side supports, specifies what the remote side should send. 310 However, not all parameters follow this rule; for example, the SRTP 311 parameters [RFC4568] sent to a remote party indicate what the local 312 side will use to encrypt, and thereby what the remote party should 313 expect to receive; the remote party will have to accept these 314 parameters, with no option to choose a different value. 316 In addition, various RFCs put different conditions on the format of 317 offers versus answers. For example, a offer may propose multiple 318 SRTP configurations, but an answer may only contain a single SRTP 319 configuration. 321 Lastly, while the exact media parameters are only known only after a 322 offer and an answer have been exchanged, it is possible for the 323 offerer to receive media after they have sent an offer and before 324 they have received an answer. To properly process incoming media in 325 this case, the offerer's media handler must be aware of the details 326 of the offer before the answer arrives. 328 Therefore, in order to handle session descriptions properly, the user 329 agent needs: 331 1. To know if a session description pertains to the local or remote 332 side. 334 2. To know if a session description is an offer or an answer. 336 3. To allow the offer to be specified independently of the answer. 338 JSEP addresses this by adding both a setLocalDescription and a 339 setRemoteDescription method and having session description objects 340 contain a type field indicating the type of session description being 341 supplied. This satisfies the requirements listed above for both the 342 offerer, who first calls setLocalDescription(sdp [offer]) and then 343 later setRemoteDescription(sdp [answer]), as well as for the 344 answerer, who first calls setRemoteDescription(sdp [offer]) and then 345 later setLocalDescription(sdp [answer]). 347 JSEP also allows for an answer to be treated as provisional by the 348 application. Provisional answers provide a way for an answerer to 349 communicate initial session parameters back to the offerer, in order 350 to allow the session to begin, while allowing a final answer to be 351 specified later. This concept of a final answer is important to the 352 offer/answer model; when such an answer is received, any extra 353 resources allocated by the caller can be released, now that the exact 354 session configuration is known. These "resources" can include things 355 like extra ICE components, TURN candidates, or video decoders. 356 Provisional answers, on the other hand, do no such deallocation 357 results; as a result, multiple dissimilar provisional answers can be 358 received and applied during call setup. 360 In [RFC3264], the constraint at the signaling level is that only one 361 offer can be outstanding for a given session, but from the media 362 stack level, a new offer can be generated at any point. For example, 363 when using SIP for signaling, if one offer is sent, then cancelled 364 using a SIP CANCEL, another offer can be generated even though no 365 answer was received for the first offer. To support this, the JSEP 366 media layer can provide an offer whenever the Javascript application 367 needs one for the signaling. The answerer can send back zero or more 368 provisional answers, and finally end the offer-answer exchange by 369 sending a final answer. The state machine for this is as follows: 371 setRemote(OFFER) setLocal(PRANSWER) 372 /-----\ /-----\ 373 | | | | 374 v | v | 375 +---------------+ | +---------------+ | 376 | |----/ | |----/ 377 | | setLocal(PRANSWER) | | 378 | Remote-Offer |------------------- >| Local-Pranswer| 379 | | | | 380 | | | | 381 +---------------+ +---------------+ 382 ^ | | 383 | | setLocal(ANSWER) | 384 setRemote(OFFER) | | 385 | V setLocal(ANSWER) | 386 +---------------+ | 387 | | | 388 | | | 389 | Stable |<---------------------------+ 390 | | | 391 | | | 392 +---------------+ setRemote(ANSWER) | 393 ^ | | 394 | | setLocal(OFFER) | 395 setRemote(ANSWER) | | 396 | V | 397 +---------------+ +---------------+ 398 | | | | 399 | | setRemote(PRANSWER) | | 400 | Local-Offer |------------------- >|Remote-Pranswer| 401 | | | | 402 | |----\ | |----\ 403 +---------------+ | +---------------+ | 404 ^ | ^ | 405 | | | | 406 \-----/ \-----/ 407 setLocal(OFFER) setRemote(PRANSWER) 409 Figure 2: JSEP State Machine 411 Aside from these state transitions, there is no other difference 412 between the handling of provisional ("pranswer") and final ("answer") 413 answers. 415 3.3. Session Description Format 417 In the WebRTC specification, session descriptions are formatted as 418 SDP messages. While this format is not optimal for manipulation from 419 Javascript, it is widely accepted, and frequently updated with new 420 features. Any alternate encoding of session descriptions would have 421 to keep pace with the changes to SDP, at least until the time that 422 this new encoding eclipsed SDP in popularity. As a result, JSEP 423 currently uses SDP as the internal representation for its session 424 descriptions. 426 However, to simplify Javascript processing, and provide for future 427 flexibility, the SDP syntax is encapsulated within a 428 SessionDescription object, which can be constructed from SDP, and be 429 serialized out to SDP. If future specifications agree on a JSON 430 format for session descriptions, we could easily enable this object 431 to generate and consume that JSON. 433 Other methods may be added to SessionDescription in the future to 434 simplify handling of SessionDescriptions from Javascript. In the 435 meantime, Javascript libraries can be used to perform these 436 manipulations. 438 Note that most applications should be able to treat the 439 SessionDescriptions produced and consumed by these various API calls 440 as opaque blobs; that is, the application will not need to read or 441 change them. The W3C API will provide appropriate APIs to allow the 442 application to control various session parameters, which will provide 443 the necessary information to the browser about what sort of 444 SessionDescription to produce. 446 3.4. ICE 448 When a new ICE candidate is available, the ICE Agent will notify the 449 application via a callback; these candidates will automatically be 450 added to the local session description. When all candidates have 451 been gathered, the callback will also be invoked to signal that the 452 gathering process is complete. 454 3.4.1. ICE Candidate Trickling 456 Candidate trickling is a technique through which a caller may 457 incrementally provide candidates to the callee after the initial 458 offer has been dispatched; the semantics of "Trickle ICE" are defined 459 in [I-D.ietf-mmusic-trickle-ice]. This process allows the callee to 460 begin acting upon the call and setting up the ICE (and perhaps DTLS) 461 connections immediately, without having to wait for the caller to 462 gather all possible candidates. This results in faster call startup 463 in cases where gathering is not performed prior to initiating the 464 call. 466 JSEP supports optional candidate trickling by providing APIs that 467 provide control and feedback on the ICE candidate gathering process. 468 Applications that support candidate trickling can send the initial 469 offer immediately and send individual candidates when they get the 470 notified of a new candidate; applications that do not support this 471 feature can simply wait for the indication that gathering is 472 complete, and then create and send their offer, with all the 473 candidates, at this time. 475 Upon receipt of trickled candidates, the receiving application will 476 supply them to its ICE Agent. This triggers the ICE Agent to start 477 using the new remote candidates for connectivity checks. 479 3.4.1.1. ICE Candidate Format 481 As with session descriptions, the syntax of the IceCandidate object 482 provides some abstraction, but can be easily converted to and from 483 the SDP candidate lines. 485 The candidate lines are the only SDP information that is contained 486 within IceCandidate, as they represent the only information needed 487 that is not present in the initial offer (i.e. for trickle 488 candidates). This information is carried with the same syntax as the 489 "candidate-attribute" field defined for ICE. For example: 491 candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host 493 The IceCandidate object also contains fields to indicate which m= 494 line it should be associated with. The m line can be identified in 495 one of two ways; either by a m-line index, or a MID. The m-line 496 index is a zero-based index, referring to the Nth m-line in the SDP. 497 The MID uses the "media stream identification", as defined in 498 [RFC5888] , to identify the m-line. WebRTC implementations creating 499 an ICE Candidate object MUST populate both of these fields. 500 Implementations receiving an ICE Candidate object SHOULD use the MID 501 if they implement that functionality, or the m-line index, if not. 503 3.4.2. ICE Candidate Pool 505 JSEP applications typically inform the browser to begin ICE gathering 506 via the information supplied to setLocalDescription, as this is where 507 the app specifies the number of media streams to gather candidates 508 for. However, to accelerate cases where the browser knows the number 509 of media streams to use ahead of time, the application MAY ask the 510 browser to gather a pool of potential ICE candidates to help ensure 511 rapid media setup. When setLocalDescription is eventually called, 512 and the browser goes to gather the needed ICE candidates, it can 513 start by checking if any candidates are available in the pool. If 514 there are candidates in the pool, they can be handed to the 515 application immediately via the aforementioned candidate callback. 516 If the pool becomes depleted, either because a larger than expected 517 number of candidates is needed, or because the pool has not had 518 enough time to gather candidates, the remaining candidates are 519 gathered as usual. 521 3.5. Interactions With Forking 523 Some call signaling systems allow various types of forking where an 524 SDP Offer may be provided to more than one device. For example, SIP 525 [RFC3261] defines both a "Parallel Search" and "Sequential Search". 526 Although these are primarily signaling level issues that are outside 527 the scope of JSEP, they do have some impact on the configuration of 528 the media plane which is relevant. When forking happens at the 529 signaling layer, the Javascript application responsible for the 530 signaling needs to make the decisions about what media should be sent 531 or received at any point of time, as well as which remote endpoint it 532 should communicate with; JSEP is used to make sure the media engine 533 can make the RTP and media perform as required by the application. 534 The basic operations that the applications can have the media engine 535 do are: 537 Start exchanging media to a given remote peer, but keep all the 538 resources reserved in the offer. 540 Start exchanging media with a given remote peer, and free any 541 resources in the offer that are not being used. 543 3.5.1. Sequential Forking 545 Sequential forking involves a call being dispatched to multiple 546 remote callees, where each callee can accept the call, but only one 547 active session ever exists at a time; no mixing of received media is 548 performed. 550 JSEP handles sequential forking well, allowing the application to 551 easily control the policy for selecting the desired remote endpoint. 552 When an answer arrives from one of the callees, the application can 553 choose to apply it either as a provisional answer, leaving open the 554 possibility of using a different answer in the future, or apply it as 555 a final answer, ending the setup flow. 557 In a "first-one-wins" situation, the first answer will be applied as 558 a final answer, and the application will reject any subsequent 559 answers. In SIP parlance, this would be ACK + BYE. 561 In a "last-one-wins" situation, all answers would be applied as 562 provisional answers, and any previous call leg will be terminated. 563 At some point, the application will end the setup process, perhaps 564 with a timer; at this point, the application could reapply the 565 existing remote description as a final answer. 567 3.5.2. Parallel Forking 569 Parallel forking involves a call being dispatched to multiple remote 570 callees, where each callee can accept the call, and multiple 571 simultaneous active signaling sessions can be established as a 572 result. If multiple callees send media at the same time, the 573 possibilities for handling this are described in Section 3.1 of 574 [RFC3960]. Most SIP devices today only support exchanging media with 575 a single device at a time, and do not try to mix multiple early media 576 audio sources, as that could result in a confusing situation. For 577 example, consider having a European ringback tone mixed together with 578 the North American ringback tone - the resulting sound would not be 579 like either tone, and would confuse the user. If the signaling 580 application wishes to only exchange media with one of the remote 581 endpoints at a time, then from a media engine point of view, this is 582 exactly like the sequential forking case. 584 In the parallel forking case where the Javascript application wishes 585 to simultaneously exchange media with multiple peers, the flow is 586 slightly more complex, but the Javascript application can follow the 587 strategy that [RFC3960] describes using UPDATE. (It is worth noting 588 that use cases where this is the desired behavior are very unusual.) 589 The UPDATE approach allows the signaling to set up a separate media 590 flow for each peer that it wishes to exchange media with. In JSEP, 591 this offer used in the UPDATE would be formed by simply creating a 592 new PeerConnection and making sure that the same local media streams 593 have been added into this new PeerConnection. Then the new 594 PeerConnection object would produce a SDP offer that could be used by 595 the signaling to perform the UPDATE strategy discussed in [RFC3960]. 597 As a result of sharing the media streams, the application will end up 598 with N parallel PeerConnection sessions, each with a local and remote 599 description and their own local and remote addresses. The media flow 600 from these sessions can be managed by specifying SDP direction 601 attributes in the descriptions, or the application can choose to play 602 out the media from all sessions mixed together. Of course, if the 603 application wants to only keep a single session, it can simply 604 terminate the sessions that it no longer needs. 606 3.6. Session Rehydration 608 In the event that the local application state is reinitialized, 609 either due to a user reload of the page, or a decision within the 610 application to reload itself (perhaps to update to a new version), it 611 is possible to keep an existing session alive, via a process called 612 "rehydration". The explicit goal of rehydration is to carry out this 613 session resumption with no interaction with the remote side other 614 than normal call signaling messages. 616 With rehydration, the current signaling state is persisted somewhere 617 outside of the page, perhaps on the application server, or in browser 618 local storage. The page is then reloaded, the saved signaling state 619 is retrieved, and a new PeerConnection object is created for the 620 session. The previously obtained MediaStreams are re-acquired, and 621 are given the same IDs as the original session; this ensures the IDs 622 in use by the remote side continue to work. Next, a new offer is 623 generated by the new PeerConnection; this offer will have new ICE and 624 possibly new DTLS-SRTP certificate fingerprints (since the old ICE 625 and SRTP state has been lost). Finally, this offer is used to re- 626 initiate the session with the existing remote endpoint, who simply 627 sees the new offer as an in-call renegotiation, and replies with an 628 answer that can be supplied to setRemoteDescription. ICE processing 629 proceeds as usual, and as soon as connectivity is established, the 630 session will be back up and running again. 632 [OPEN ISSUE: EKR proposed an alternative rehydration approach where 633 the actual internal PeerConnection object in the browser was kept 634 alive for some time after the web page was killed and provided some 635 way for a new page to acquire the old PeerConnection object.] 637 4. Interface 639 This section details the basic operations that must be present to 640 implement JSEP functionality. The actual API exposed in the W3C API 641 may have somewhat different syntax, but should map easily to these 642 concepts. 644 4.1. Methods 646 4.1.1. Constructor 648 The PeerConnection constructor allows the application to specify 649 global parameters for the media session, such as the STUN/TURN 650 servers and credentials to use when gathering candidates. The size 651 of the ICE candidate pool can also be set, if desired; by default the 652 candidate pool size is zero. 654 In addition, the application can specify its preferred policy 655 regarding use of BUNDLE, the multiplexing mechanism defined in 656 [I-D.ietf-mmusic-sdp-bundle-negotiation]. By specifying a policy 657 from the list below, the application can control how aggressively it 658 will try to BUNDLE media streams together. The set of available 659 policies is as follows: 661 o "default": The application will BUNDLE all media streams of the 662 same type together. That is, if there are multiple audio and 663 multiple video MediaStreamTracks attached to a PeerConnection, all 664 but the first audio and video tracks will be marked as bundle- 665 only, and candidates will only be gathered for N media streams, 666 where N is the number of distinct media types. When talking to a 667 non-BUNDLE-aware endpoint, only the non-bundle-only streams will 668 be negotiated. This policy balances desire to multiplex with the 669 need to ensure basic audio and video still works in legacy cases. 671 o "max-bundle": The application will BUNDLE all of its media streams 672 on a single transport. All streams other than the first will be 673 marked as bundle-only. This policy aims to minimize candidate 674 gathering and maximize multiplexing, at the cost of less 675 compatibility with legacy endpoints. 677 o "max-compat": The application will offer BUNDLE, but mark none of 678 its streams as bundle-only. This policy will allow all streams to 679 be received by non-BUNDLE-aware endpoints, but require separate 680 candidates to be gathered for each media stream. 682 4.1.2. createOffer 684 The createOffer method generates a blob of SDP that contains a 685 [RFC3264] offer with the supported configurations for the session, 686 including descriptions of the local MediaStreams attached to this 687 PeerConnection, the codec/RTP/RTCP options supported by this 688 implementation, and any candidates that have been gathered by the ICE 689 Agent. A constraints parameter may be supplied to provide additional 690 control over the generated offer. This constraints parameter should 691 allow for the following manipulations to be performed: 693 o To indicate support for a media type even if no MediaStreamTracks 694 of that type have been added to the session (e.g., an audio call 695 that wants to receive video.) 697 o To trigger an ICE restart, for the purpose of reestablishing 698 connectivity. 700 In the initial offer, the generated SDP will contain all desired 701 functionality for the session (certain parts that are supported but 702 not desired by default may be omitted); for each SDP line, the 703 generation of the SDP will follow the process defined for generating 704 an initial offer from the document that specifies the given SDP line. 705 The exact handling of initial offer generation is detailed in 706 Section 5.2.1. below. 708 In the event createOffer is called after the session is established, 709 createOffer will generate an offer to modify the current session 710 based on any changes that have been made to the session, e.g. adding 711 or removing MediaStreams, or requesting an ICE restart. For each 712 existing stream, the generation of each SDP line must follow the 713 process defined for generating an updated offer from the document 714 that specifies the given SDP line. For each new stream, the 715 generation of the SDP must follow the process of generating an 716 initial offer, as mentioned above. If no changes have been made, or 717 for SDP lines that are unaffected by the requested changes, the offer 718 will only contain the parameters negotiated by the last offer-answer 719 exchange. The exact handling of subsequent offer generation is 720 detailed in Section 5.2.2. below. 722 Session descriptions generated by createOffer must be immediately 723 usable by setLocalDescription; if a system has limited resources 724 (e.g. a finite number of decoders), createOffer should return an 725 offer that reflects the current state of the system, so that 726 setLocalDescription will succeed when it attempts to acquire those 727 resources. Because this method may need to inspect the system state 728 to determine the currently available resources, it may be implemented 729 as an async operation. 731 Calling this method may do things such as generate new ICE 732 credentials, but does not result in candidate gathering, or cause 733 media to start or stop flowing. 735 4.1.3. createAnswer 737 The createAnswer method generates a blob of SDP that contains a 738 [RFC3264] SDP answer with the supported configuration for the session 739 that is compatible with the parameters supplied in the offer. Like 740 createOffer, the returned blob contains descriptions of the local 741 MediaStreams attached to this PeerConnection, the codec/RTP/RTCP 742 options negotiated for this session, and any candidates that have 743 been gathered by the ICE Agent. A constraints parameter may be 744 supplied to provide additional control over the generated answer. 746 As an answer, the generated SDP will contain a specific configuration 747 that specifies how the media plane should be established; for each 748 SDP line, the generation of the SDP must follow the process defined 749 for generating an answer from the document that specifies the given 750 SDP line. The exact handling of answer generation is detailed in 751 Section 5.3. below. 753 Session descriptions generated by createAnswer must be immediately 754 usable by setLocalDescription; like createOffer, the returned 755 description should reflect the current state of the system. Because 756 this method may need to inspect the system state to determine the 757 currently available resources, it may need to be implemented as an 758 async operation. 760 Calling this method may do things such as generate new ICE 761 credentials, but does not trigger candidate gathering or change media 762 state. 764 4.1.4. SessionDescriptionType 766 Session description objects (RTCSessionDescription) may be of type 767 "offer", "pranswer", and "answer". These types provide information 768 as to how the description parameter should be parsed, and how the 769 media state should be changed. 771 "offer" indicates that a description should be parsed as an offer; 772 said description may include many possible media configurations. A 773 description used as an "offer" may be applied anytime the 774 PeerConnection is in a stable state, or as an update to a previously 775 supplied but unanswered "offer". 777 "pranswer" indicates that a description should be parsed as an 778 answer, but not a final answer, and so should not result in the 779 freeing of allocated resources. It may result in the start of media 780 transmission, if the answer does not specify an inactive media 781 direction. A description used as a "pranswer" may be applied as a 782 response to an "offer", or an update to a previously sent "pranswer". 784 "answer" indicates that a description should be parsed as an answer, 785 the offer-answer exchange should be considered complete, and any 786 resources (decoders, candidates) that are no longer needed can be 787 released. A description used as an "answer" may be applied as a 788 response to a "offer", or an update to a previously sent "pranswer". 790 The only difference between a provisional and final answer is that 791 the final answer results in the freeing of any unused resources that 792 were allocated as a result of the offer. As such, the application 793 can use some discretion on whether an answer should be applied as 794 provisional or final, and can change the type of the session 795 description as needed. For example, in a serial forking scenario, an 796 application may receive multiple "final" answers, one from each 797 remote endpoint. The application could choose to accept the initial 798 answers as provisional answers, and only apply an answer as final 799 when it receives one that meets its criteria (e.g. a live user 800 instead of voicemail). 802 4.1.4.1. Use of Provisional Answers 804 Most web applications will not need to create answers using the 805 "pranswer" type. While it is good practice to send an immediate 806 response to an "offer", in order to warm up the session transport and 807 prevent media clipping, the preferred handling for a web application 808 would be to create and send an "inactive" final answer immediately 809 after receiving the offer. Later, when the called user actually 810 accepts the call, the application can create a new "sendrecv" offer 811 to update the previous offer/answer pair and start the media flow. 812 While this could also be done with an inactive "pranswer", followed 813 by a sendrecv "answer", the initial "pranswer" leaves the offer- 814 answer exchange open, which means the caller cannot send an updated 815 offer during this time. 817 As an example, consider a typical web application that will set up a 818 data channel, an audio channel, and a video channel. When an 819 endpoint receives an offer with these channels, it could send an 820 answer accepting the data channel for two-way data, and accepting the 821 audio and video tracks as inactive or receive-only. It could then 822 ask the user to accept the call, acquire the local media streams, and 823 send a new offer to the remote side moving the audio and video to be 824 two-way media. By the time the human has accepted the call and 825 triggered the new offer, it is likely that the ICE and DTLS 826 handshaking for all the channels will already be set up. 828 Of course, some applications may not be able to perform this double 829 offer-answer exchange, particularly ones that are attempting to 830 gateway to legacy signaling protocols. In these cases, "pranswer" 831 can still provide the application with a mechanism to warm up the 832 transport. 834 4.1.4.2. Rollback 836 In certain situations it may be desirable to "undo" a change made to 837 setLocalDescription or setRemoteDescription. Consider a case where a 838 call is ongoing, and one side wants to change some of the session 839 parameters; that side generates an updated offer and then calls 840 setLocalDescription. However, the remote side, either before or 841 after setRemoteDescription, decides it does not want to accept the 842 new parameters, and sends a reject message back to the offerer. Now, 843 the offerer, and possibly the answerer as well, need to return to a 844 stable state and the previous local/remote description. To support 845 this, we introduce the concept of "rollback". 847 A rollback discards any proposed changes to the session, returning 848 the state machine to the stable state, and setting the modified local 849 and/or remote description back to their previous values. Any 850 resources or candidates that were allocated by the abandoned local 851 description are discarded; any media that is received will be 852 processed according to the previous local and remote descriptions. 853 Rollback can only be used to cancel proposed changes; there is no 854 support for rolling back from a stable state to a previous stable 855 state. 857 A rollback is performed by supplying a session description of type 858 "rollback" with empty contents to either setLocalDescription or 859 setRemoteDescription, depending on which was most recently used (i.e. 860 if the new offer was supplied to setLocalDescription, the rollback 861 should be done using setLocalDescription as well). 863 4.1.5. setLocalDescription 865 The setLocalDescription method instructs the PeerConnection to apply 866 the supplied SDP blob as its local configuration. The type field 867 indicates whether the blob should be processed as an offer, 868 provisional answer, or final answer; offers and answers are checked 869 differently, using the various rules that exist for each SDP line. 871 This API changes the local media state; among other things, it sets 872 up local resources for receiving and decoding media. In order to 873 successfully handle scenarios where the application wants to offer to 874 change from one media format to a different, incompatible format, the 875 PeerConnection must be able to simultaneously support use of both the 876 old and new local descriptions (e.g. support codecs that exist in 877 both descriptions) until a final answer is received, at which point 878 the PeerConnection can fully adopt the new local description, or roll 879 back to the old description if the remote side denied the change. 881 This API indirectly controls the candidate gathering process. When a 882 local description is supplied, and the number of transports currently 883 in use does not match the number of transports needed by the local 884 description, the PeerConnection will create transports as needed and 885 begin gathering candidates for them. 887 If setRemoteDescription was previous called with an offer, and 888 setLocalDescription is called with an answer (provisional or final), 889 and the media directions are compatible, and media are available to 890 send, this will result in the starting of media transmission. 892 4.1.6. setRemoteDescription 894 The setRemoteDescription method instructs the PeerConnection to apply 895 the supplied SDP blob as the desired remote configuration. As in 896 setLocalDescription, the type field of the indicates how the blob 897 should be processed. 899 This API changes the local media state; among other things, it sets 900 up local resources for sending and encoding media. 902 If setRemoteDescription was previously called with an offer, and 903 setLocalDescription is called with an answer (provisional or final), 904 and the media directions are compatible, and media are available to 905 send, this will result in the starting of media transmission. 907 4.1.7. localDescription 909 The localDescription method returns a copy of the current local 910 configuration, i.e. what was most recently passed to 911 setLocalDescription, plus any local candidates that have been 912 generated by the ICE Agent. 914 TODO: Do we need to expose accessors for both the current and 915 proposed local description? 917 A null object will be returned if the local description has not yet 918 been established, or if the PeerConnection has been closed. 920 4.1.8. remoteDescription 922 The remoteDescription method returns a copy of the current remote 923 configuration, i.e. what was most recently passed to 924 setRemoteDescription, plus any remote candidates that have been 925 supplied via processIceMessage. 927 TODO: Do we need to expose accessors for both the current and 928 proposed remote description? 930 A null object will be returned if the remote description has not yet 931 been established, or if the PeerConnection has been closed. 933 4.1.9. updateIce 935 The updateIce method allows the configuration of the ICE Agent to be 936 changed during the session, primarily for changing which types of 937 local candidates are provided to the application and used for 938 connectivity checks. A callee may initially configure the ICE Agent 939 to use only relay candidates, to avoid leaking location information, 940 but update this configuration to use all candidates once the call is 941 accepted. 943 Regardless of the configuration, the gathering process collects all 944 available candidates, but excluded candidates will not be surfaced in 945 onicecandidate callback or used for connectivity checks. 947 This call may result in a change to the state of the ICE Agent, and 948 may result in a change to media state if it results in connectivity 949 being established. 951 4.1.10. addIceCandidate 953 The addIceCandidate method provides a remote candidate to the ICE 954 Agent, which, if parsed successfully, will be added to the remote 955 description according to the rules defined for Trickle ICE. 956 Connectivity checks will be sent to the new candidate. 958 This call will result in a change to the state of the ICE Agent, and 959 may result in a change to media state if it results in connectivity 960 being established. 962 5. SDP Interaction Procedures 964 This section describes the specific procedures to be followed when 965 creating and parsing SDP objects. 967 5.1. Requirements Overview 969 JSEP implementations must comply with the specifications listed below 970 that govern the creation and processing of offers and answers. 972 The first set of specifications is the "mandatory-to-implement" set. 973 All implementations must support these behaviors, but may not use all 974 of them if the remote side, which may not be a JSEP endpoint, does 975 not support them. 977 The second set of specifications is the "mandatory-to-use" set. The 978 local JSEP endpoint and any remote endpoint must indicate support for 979 these specifications in their session descriptions. 981 5.1.1. Implementation Requirements 983 This list of mandatory-to-implement specifications is derived from 984 the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. 986 R-1 [RFC4566] is the base SDP specification and MUST be 987 implemented. 989 R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF 990 RTP profile. 992 R-3 [RFC5245] MUST be implemented for signaling the ICE credentials 993 and candidate lines corresponding to each media stream. The 994 ICE implementation MUST be a Full implementation, not a Lite 995 implementation. 997 R-4 [RFC5763] MUST be implemented to signal DTLS certificate 998 fingerprints. 1000 R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying 1001 information. 1003 R-6 The [RFC5888] grouping framework MUST be implemented for 1004 signaling grouping information, and MUST be used to identify m= 1005 lines via the a=mid attribute. 1007 R-7 [I-D.ietf-mmusic-msid] MUST be supported, in order to signal 1008 associations between RTP objects and W3C MediaStreams and 1009 MediaStreamTracks in a standard way. 1011 R-8 The bundle mechanism in 1012 [I-D.ietf-mmusic-sdp-bundle-negotiation] MUST be supported to 1013 signal the ability to multiplex RTP streams on a single UDP 1014 port, in order to avoid excessive use of port number resources. 1016 R-9 The SDP attributes of "sendonly", "recvonly", "inactive", and 1017 "sendrecv" from [RFC4566] MUST be implemented to signal 1018 information about media direction. 1020 R-10 [RFC5576] MUST be implemented to signal RTP SSRC values. 1022 R-11 [RFC4585] MUST be implemented to signal RTCP based feedback. 1024 R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and 1025 RTCP. 1027 R-13 [RFC5506] MUST be implemented to signal reduced-size RTCP 1028 messages. 1030 R-14 [RFC3556] with bandwidth modifiers MAY be supported for 1031 specifying RTCP bandwidth as a fraction of the media bandwidth, 1032 RTCP fraction allocated to the senders and setting maximum 1033 media bit-rate boundaries. 1035 As required by [RFC4566], Section 5.13, JSEP implementations MUST 1036 ignore unknown attribute (a=) lines. 1038 5.1.2. Usage Requirements 1040 All session descriptions handled by JSEP endpoints, both local and 1041 remote, MUST indicate support for the following specifications. If 1042 any of these are absent, this omission MUST be treated as an error. 1044 R-1 Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP 1045 profile, as specified in [RFC5764], MUST be used. 1047 R-2 ICE, as specified in [RFC5245], MUST be used. Note that the 1048 remote endpoint MAY use a Lite implementation. 1050 R-3 DTLS-SRTP, as specified in [RFC5763], MUST be used. 1052 5.2. Constructing an Offer 1054 When createOffer is called, a new SDP description must be created 1055 that includes the functionality specified in 1056 [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are 1057 explained below. 1059 5.2.1. Initial Offers 1061 When createOffer is called for the first time, the result is known as 1062 the initial offer. 1064 The first step in generating an initial offer is to generate session- 1065 level attributes, as specified in [RFC4566], Section 5. 1066 Specifically: 1068 o The first SDP line MUST be "v=0", as specified in [RFC4566], 1069 Section 5.1 1071 o The second SDP line MUST be an "o=" line, as specified in 1072 [RFC4566], Section 5.2. The value of the field SHOULD 1073 be "-". The value of the field SHOULD be a 1074 cryptographically random number. To ensure uniqueness, this 1075 number SHOULD be at least 64 bits long. The value of the field SHOULD be zero. The value of the 1077 tuple SHOULD be set to a non- 1078 meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the 1079 local address in this field. As mentioned in [RFC4566], the 1080 entire o= line needs to be unique, but selecting a random number 1081 for is sufficient to accomplish this. 1083 o The third SDP line MUST be a "s=" line, as specified in [RFC4566], 1084 Section 5.3; to match the "o=" line, a single dash SHOULD be used 1085 as the session name, e.g. "s=-". 1087 o Session Information ("i="), URI ("u="), Email Address ("e="), 1088 Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and 1089 Time Zones ("z=") lines are not useful in this context and SHOULD 1090 NOT be included. 1092 o Encryption Keys ("k=") lines do not provide sufficient security 1093 and MUST NOT be included. 1095 o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; 1096 both and SHOULD be set to zero, e.g. "t=0 1097 0". 1099 o An "a=msid-semantic:WMS" line MUST be added, as specified in 1100 [I-D.ietf-mmusic-msid], Section 4. 1102 The next step is to generate m= sections for each MediaStreamTrack 1103 that has been added to the PeerConnection via the addStream method. 1104 (Note that this method takes a MediaStream, which can contain 1105 multiple MediaStreamTracks, and therefore multiple m= sections can be 1106 generated even if addStream is only called once.) When generating m= 1107 sections, the ordering is based on (1) the order in which the 1108 MediaStreams were added to the PeerConnection, and (2) the 1109 alphabetical ordering of the media type for the MediaStreamTrack. 1110 For example, if a MediaStream containing both an audio and a video 1111 MediaStreamTrack is added to a PeerConnection, the resultant m=audio 1112 section will precede the m=video section. 1114 Each m= section, provided it is not being bundled into another m= 1115 section, MUST generate a unique set of ICE credentials and gather its 1116 own unique set of ICE candidates. Otherwise, it MUST use the same 1117 ICE credentials and candidates that were used in the m= section that 1118 it is being bundled into. 1120 For DTLS, all m= sections MUST use the certificate for the identity 1121 that has been specified for the PeerConnection; as a result, they 1122 MUST all have the same [RFC4572]fingerprint value. 1124 Each m= section should be generated as specified in [RFC4566], 1125 Section 5.14. For the m= line itself, the following rules MUST be 1126 followed: 1128 o The port value is set to the port of the default ICE candidate for 1129 this m= section; if this m= section is not being bundled into 1130 another m= section, the port value MUST be unique. If no 1131 candidates have yet been gathered, and a 'null' port value is 1132 being used, as indicated in [I-D.ietf-mmusic-trickle-ice], 1133 Section 5.1., this port MUST still be unique. 1135 o To properly indicate use of DTLS, the field MUST be set to 1136 "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. 1138 Each m= section MUST include the following attribute lines: 1140 o An "a=mid" line, as specified in [RFC5888], Section 4. 1142 o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], 1143 Section 2. 1145 o [OPEN ISSUE: Use of AppID] 1147 o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1. 1149 o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as 1150 specified in [RFC4566], Section 6. For audio, the codecs 1151 specified in [I-D.ietf-rtcweb-audio], Section 3, MUST be be 1152 supported. 1154 o For each primary codec where RTP retransmission should be used, a 1155 corresponding "a=rtpmap" line indicating "rtx" with the clock rate 1156 of the primary codec and an "a=fmtp" line that references the 1157 payload type fo the primary codec, as specified in [RFC4588], 1158 Section 8.1. 1160 o For each supported FEC mechanism, a corresponding "a=rtpmap" line 1161 indicating the desired FEC codec. 1163 o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], 1164 Section 15.4. 1166 o An "a=ice-options" line, with the "trickle" option, as specified 1167 in [I-D.ietf-mmusic-trickle-ice], Section 4. 1169 o For each candidate that has been gathered during the most recent 1170 gathering phase, an "a=candidate" line, as specified in [RFC5245], 1171 Section 4.3., paragraph 3. 1173 o For the current default candidate, a "c=" line, as specific in 1174 [RFC5245], Section 4.3., paragraph 6. If no candidates have been 1175 gathered yet, the default candidate should be set to the 'null' 1176 value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1178 o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the 1179 algorithm used for the fingerprint MUST match that used in the 1180 certificate signature. 1182 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1183 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1184 The role value in the offer MUST be "actpass". 1186 o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1. 1188 o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. 1190 o For each supported RTP header extension, an "a=extmap" line, as 1191 specified in [RFC5285], Section 5. The list of header extensions 1192 that SHOULD/MUST be supported is specified in 1193 [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions 1194 that require encryption MUST be specified as indicated in 1195 [RFC6904], Section 4. 1197 o For each supported RTCP feedback mechanism, an "a=rtcp-fb" 1198 mechanism, as specified in [RFC4585], Section 4.2. The list of 1199 RTCP feedback mechanisms that SHOULD/MUST be supported is 1200 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. 1202 o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, 1203 indicating the SSRC to be used for sending media, along with the 1204 mandatory "cname" source attribute, as specified in Section 6.1, 1205 indicating the CNAME for the source. The CNAME must be generated 1206 in accordance with draft-rescorla-random-cname-00. [OPEN ISSUE: 1207 How are CNAMEs specified for MSTs? Are they randomly generated 1208 for each MediaStream? If so, can two MediaStreams be synced?] 1210 o If RTX is supported for this media type, another "a=ssrc" line 1211 with the RTX SSRC, and an "a=ssrc-group" line, as specified in 1212 [RFC5576], section 4.2, with semantics set to "FID" and including 1213 the primary and RTX SSRCs. 1215 o If FEC is supported for this media type, another "a=ssrc" line 1216 with the FEC SSRC, and an "a=ssrc-group" line, as specified in 1217 [RFC5576], section 4.2, with semantics set to "FEC" and including 1218 the primary and FEC SSRCs. 1220 o [OPEN ISSUE: Handling of a=imageattr] 1222 o If the BUNDLE policy for this PeerConnection is set to "max- 1223 bundle", and this is not the first m= section, or the BUNDLE 1224 policy is set to "default", and this is not the first m= section 1225 for this media type, an "a=bundle-only" line. 1227 Lastly, if a data channel has been created, a m= section MUST be 1228 generated for data. The field MUST be set to "application" 1229 and the field MUST be set to "DTLS/SCTP", as specified in 1231 [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to 1232 the SCTP port number, as specified in Section 4.1. 1234 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- 1235 passwd", "a=ice-options", "a=candidate", "a=fingerprint", and 1236 "a=setup" lines MUST be included as mentioned above, along with an 1237 "a=sctpmap" line referencing the SCTP port number and specifying the 1238 application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. 1239 [OPEN ISSUE: the -01 of this document is missing this information.] 1241 Once all m= sections have been generated, a session-level "a=group" 1242 attribute MUST be added as specified in [RFC5888]. This attribute 1243 MUST have semantics "BUNDLE", and MUST include the mid identifiers of 1244 each m= section. 1246 Attributes that are common between all m= sections MAY be moved to 1247 session-level, if explicitly defined to be valid at session-level. 1249 Attributes other than the ones specified above MAY be included, 1250 except for the following attributes which are specifically 1251 incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], 1252 and MUST NOT be included: 1254 o "a=crypto" 1256 o "a=key-mgmt" 1258 o "a=ice-lite" 1260 Note that when BUNDLE is used, any additional attributes that are 1261 added MUST follow the advice in 1262 [I-D.nandakumar-mmusic-sdp-mux-attributes] on how those attributes 1263 interact with BUNDLE. 1265 5.2.2. Subsequent Offers 1267 When createOffer is called a second (or later) time, or is called 1268 after a local description has already been installed, the processing 1269 is somewhat different than for an initial offer. 1271 If the initial offer was not applied using setLocalDescription, 1272 meaning the PeerConnection is still in the "stable" state, the steps 1273 for generating an initial offer should be followed, subject to the 1274 following restriction: 1276 o The fields of the "o=" line MUST stay the same except for the 1277 field, which MUST increment if the session 1278 description changes in any way, including the addition of ICE 1279 candidates. 1281 If the initial offer was applied using setLocalDescription, but an 1282 answer from the remote side has not yet been applied, meaning the 1283 PeerConnection is still in the "local-offer" state, an offer is 1284 generated by following the steps in the "stable" state above, along 1285 with these exceptions: 1287 o The "s=" and "t=" lines MUST stay the same. 1289 o Each "a=mid" line MUST stay the same. 1291 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. 1293 o For MediaStreamTracks that are still present, the "a=msid", 1294 "a=ssrc", and "a=ssrc-group" lines MUST stay the same. 1296 o If any MediaStreamTracks have been removed, either through the 1297 removeStream method or by removing them from an added MediaStream, 1298 their m= sections MUST be marked as recvonly by changing the value 1299 of the [RFC3264] directional attribute to "a=recvonly". The 1300 "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed from 1301 the associated m= sections. 1303 o If any MediaStreamTracks have been added, and there exist m= 1304 sections of the appropriate media type with no associated 1305 MediaStreamTracks (i.e. as described in the preceding paragraph), 1306 those m= sections MUST be recycled by adding the new 1307 MediaStreamTrack to the m= section. This is done by adding the 1308 necessary "a=msid", "a=ssrc", and "a=ssrc-group" lines to the 1309 recycled m= section, and removing the "a=recvonly" attribute. 1311 If the initial offer was applied using setLocalDescription, and an 1312 answer from the remote side has been applied using 1313 setRemoteDescription, meaning the PeerConnection is in the "remote- 1314 pranswer" or "stable" states, an offer is generated based on the 1315 negotiated session descriptions by following the steps mentioned for 1316 the "local-offer" state above, along with these exceptions: [OPEN 1317 ISSUE: should this be permitted in the remote-pranswer state?] 1319 o If a m= section exists in the current local description, but does 1320 not have an associated local MediaStreamTrack (possibly because 1321 said MediaStreamTrack was removed since the last exchange), a m= 1322 section MUST still be generated in the new offer, as indicated in 1323 [RFC3264], Section 8. The disposition of this section will depend 1324 on the state of the remote MediaStreamTrack associated with this 1325 m= section. If one exists, and it is still in the "live" state, 1326 the new m= section MUST be marked as "a=recvonly", with no 1327 "a=msid" or related attributes present. If no remote 1328 MediaStreamTrack exists, or it is in the "ended" state, the m= 1329 section MUST be marked as rejected, by setting the port to zero, 1330 as indicated in [RFC3264], Section 8.2. 1332 o If any MediaStreamTracks have been added, and there exist recvonly 1333 m= sections of the appropriate media type with no associated 1334 MediaStreamTracks, or rejected m= sections of any media type, 1335 those m= sections MUST be recycled, and the local 1336 MediaStreamTracks associated with these recycled m= sections. 1337 This includes any recvonly or rejected m= sections created by the 1338 preceding paragraph. 1340 In addition, for each non-recycled, non-rejected m= section in the 1341 new offer, the following adjustments are made based on the contents 1342 of the corresponding m= section in the current remote description: 1344 o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST 1345 only include codecs present in the remote description. 1347 o The RTP header extensions MUST only include those that are present 1348 in the remote description. 1350 o The RTCP feedback extensions MUST only include those that are 1351 present in the remote description. 1353 o The "a=rtcp-mux" line MUST only be added if present in the remote 1354 description. 1356 o The "a=rtcp-rsize" line MUST only be added if present in the 1357 remote description. 1359 The "a=group:BUNDLE" attribute MUST include the mid identifiers 1360 specified in the BUNDLE group in the most recent answer, minus any m= 1361 sections that have been marked as rejected, plus any newly added or 1362 re-enabled m= sections. In other words, the BUNDLE attribute must 1363 contain all m= sections that were previously bundled, as long as they 1364 are still alive, as well as any new m= sections. 1366 5.2.3. Constraints Handling 1368 The createOffer method takes as a parameter a MediaConstraints 1369 object. Special processing is performed when generating a SDP 1370 description if the following constraints are present. 1372 5.2.3.1. OfferToReceiveAudio 1374 If the "OfferToReceiveAudio" constraint is specified, with a value of 1375 "N", the offer MUST include N non-rejected m= sections with media 1376 type "audio", even if fewer than N audio MediaStreamTracks have been 1377 added to the PeerConnection. This allows the offerer to receive 1378 audio, including multiple independent streams, even when not sending 1379 it; accordingly, the directional attribute on the audio m= sections 1380 without associated MediaStreamTracks MUST be set to recvonly. If 1381 this constraint is specified in the case where at least N audio 1382 MediaStreamTracks have already been added to the PeerConnection, or N 1383 non-rejected m= sections with media type "audio" would otherwise be 1384 generated, it has no effect. For backwards compatibility, a value of 1385 "true" is interpreted as equivalent to N=1. 1387 5.2.3.2. OfferToReceiveVideo 1389 If the "OfferToReceiveVideo" constraint is specified, with a value of 1390 "N", the offer MUST include N non-rejected m= sections with media 1391 type "video", even if fewer than N video MediaStreamTracks have been 1392 added to the PeerConnection. This allows the offerer to receive 1393 video, including multiple independent streams, even when not sending 1394 it; accordingly, the directional attribute on the video m= sections 1395 without associated MediaStreamTracks MUST be set to recvonly. If 1396 this constraint is specified in the case where at least N video 1397 MediaStreamTracks have already been added to the PeerConnection, or N 1398 non-rejected m= sections with media type "video" would otherwise be 1399 generated, it has no effect. For backwards compatibility, a value of 1400 "true" is interpreted as equivalent to N=1. 1402 5.2.3.3. VoiceActivityDetection 1404 If the "VoiceActivityDetection" constraint is specified, with a value 1405 of "true", the offer MUST indicate support for silence suppression by 1406 including comfort noise ("CN") codecs for each supported clock rate, 1407 as specified in [RFC3389], Section 5.1. 1409 5.2.3.4. IceRestart 1411 If the "IceRestart" constraint is specified, with a value of "true", 1412 the offer MUST indicate an ICE restart by generating new ICE ufrag 1413 and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If 1414 this constraint is specified on an initial offer, it has no effect 1415 (since a new ICE ufrag and pwd are already generated). 1417 5.3. Generating an Answer 1419 When createAnswer is called, a new SDP description must be created 1420 that is compatible with the supplied remote description as well as 1421 the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact 1422 details of this process are explained below. 1424 5.3.1. Initial Answers 1426 When createAnswer is called for the first time after a remote 1427 description has been provided, the result is known as the initial 1428 answer. If no remote description has been installed, an answer 1429 cannot be generated, and an error MUST be returned. 1431 Note that the remote description SDP may not have been created by a 1432 JSEP endpoint and may not conform to all the requirements listed in 1433 Section 5.2. For many cases, this is not a problem. However, if any 1434 mandatory SDP attributes are missing, or functionality listed as 1435 mandatory-to-use above is not present, this MUST be treated as an 1436 error, and MUST cause the affected m= sections to be marked as 1437 rejected. 1439 The first step in generating an initial answer is to generate 1440 session-level attributes. The process here is identical to that 1441 indicated in the Initial Offers section above. 1443 The next step is to generate m= sections for each m= section that is 1444 present in the remote offer, as specified in [RFC3264], Section 6. 1445 For the purposes of this discussion, any session-level attributes in 1446 the offer that are also valid as media-level attributes SHALL be 1447 considered to be present in each m= section. 1449 For each offered m= section of a given media type, if there is a 1450 local MediaStreamTrack of the specified type which has been added to 1451 the PeerConnection via addStream and not yet associated with a m= 1452 section, and the specific m= section is either sendrecv or recvonly, 1453 the MediaStreamTrack is associated with the m= section at this time. 1454 If there are more m= sections of a certain type than 1455 MediaStreamTracks, some m= sections will not have an associated 1456 MediaStreamTrack. If there are more MediaStreamTracks of a certain 1457 type than compatible m= sections, only the first N MediaStreamTracks 1458 will be able to be associated in the constructed answer. The 1459 remainder will need to be associated in a subsequent offer. 1461 For each offered m= section, if the associated remote 1462 MediaStreamTrack has been stopped, and is therefore in state "ended", 1463 and no local MediaStreamTrack has been associated, the corresponding 1464 m= section in the answer MUST be marked as rejected by setting the 1465 port in the m= line to zero, as indicated in [RFC3264], Section 6., 1466 and further processing for this m= section can be skipped. 1468 Provided that is not the case, each m= section in the answer should 1469 then generated as specified in [RFC3264], Section 6.1. Because use 1470 of DTLS is mandatory, the field MUST be set to "UDP/TLS/RTP/ 1471 SAVPF". If the offer supports BUNDLE, all m= sections to be BUNDLEd 1472 must use the same ICE credentials and candidates; all m= sections not 1473 being BUNDLEd must use unique ICE credentials and candidates. Each 1474 m= section MUST include the following: 1476 o If present in the offer, an "a=mid" line, as specified in 1477 [RFC5888], Section 9.1. The "mid" value MUST match that specified 1478 in the offer. 1480 o If a local MediaStreamTrack has been associated, an "a=msid" line, 1481 as specified in [I-D.ietf-mmusic-msid], Section 2. 1483 o [OPEN ISSUE: Use of AppID] 1485 o Depending on the directionality of the offer, the disposition of 1486 any associated remote MediaStreamTrack, and the presence of an 1487 associated local MediaStreamTrack, the appropriate directionality 1488 attribute, as specified in [RFC3264], Section 6.1. If the offer 1489 was sendrecv, and the remote MediaStreamTrack is still "live", and 1490 there a local MediaStreamTrack has been associated, the 1491 directionality MUST be set as sendrecv. If the offer was 1492 sendonly, and the remote MediaStreamTrack is still "live", the 1493 directionality MUST be set as recvonly. If the offer was 1494 recvonly, and a local MediaStreamTrack has been associated, the 1495 directionality MUST be set as sendonly. If the offer was 1496 inactive, the directionality MUST be set as inactive. 1498 o For each supported codec that is present in the offer, "a=rtpmap" 1499 and "a=fmtp" lines, as specified in [RFC4566], Section 6, and 1500 [RFC3264], Section 6.1. For audio, the codecs specified in 1501 [I-D.ietf-rtcweb-audio], Section 3, MUST be be supported. Note 1502 that for simplicity, the answerer MAY use different payload types 1503 for codecs than the offerer, as it is not prohibited by 1504 Section 6.1. 1506 o If "rtx" is present in the offer, for each primary codec where RTP 1507 retransmission should be used, a corresponding "a=rtpmap" line 1508 indicating "rtx" with the clock rate of the primary codec and an 1509 "a=fmtp" line that references the payload type fo the primary 1510 codec, as specified in [RFC4588], Section 8.1. 1512 o For each supported FEC mechanism that is present in the offer, a 1513 corresponding "a=rtpmap" line indicating the desired FEC codec. 1515 o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], 1516 Section 15.4. 1518 o If the "trickle" ICE option is present in the offer, an "a=ice- 1519 options" line, with the "trickle" option, as specified in 1520 [I-D.ietf-mmusic-trickle-ice], Section 4. 1522 o For each candidate that has been gathered during the most recent 1523 gathering phase, an "a=candidate" line, as specified in [RFC5245], 1524 Section 4.3., paragraph 3. 1526 o For the current default candidate, a "c=" line, as specific in 1527 [RFC5245], Section 4.3., paragraph 6. If no candidates have been 1528 gathered yet, the default candidate should be set to the 'null' 1529 value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1531 o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the 1532 algorithm used for the fingerprint MUST match that used in the 1533 certificate signature. 1535 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1536 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1537 The role value in the answer MUST be "active" or "passive"; the 1538 "active" role is RECOMMENDED. 1540 o If present in the offer, an "a=rtcp-mux" line, as specified in 1541 [RFC5761], Section 5.1.1. 1543 o If present in the offer, an "a=rtcp-rsize" line, as specified in 1544 [RFC5506], Section 5. 1546 o For each supported RTP header extension that is present in the 1547 offer, an "a=extmap" line, as specified in [RFC5285], Section 5. 1548 The list of header extensions that SHOULD/MUST be supported is 1549 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header 1550 extensions that require encryption MUST be specified as indicated 1551 in [RFC6904], Section 4. 1553 o For each supported RTCP feedback mechanism that is present in the 1554 offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], 1555 Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ 1556 MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], 1557 Section 5.1. 1559 o If a local MediaStreamTrack has been associated, an "a=ssrc" line, 1560 as specified in [RFC5576], Section 4.1, indicating the SSRC to be 1561 used for sending media. 1563 o If a local MediaStreamTrack has been associated, and RTX has been 1564 negotiated for this m= section, another "a=ssrc" line with the RTX 1565 SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], 1566 section 4.2, with semantics set to "FID" and including the primary 1567 and RTX SSRCs. 1569 o If a local MediaStreamTrack has been associated, and FEC has been 1570 negotiated for this m= section, another "a=ssrc" line with the FEC 1571 SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], 1572 section 4.2, with semantics set to "FEC" and including the primary 1573 and FEC SSRCs. 1575 o [OPEN ISSUE: Handling of a=imageattr] 1577 If a data channel m= section has been offered, a m= section MUST also 1578 be generated for data. The field MUST be set to 1579 "application" and the field MUST be set to "DTLS/SCTP", as 1580 specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value 1581 MUST be set to the SCTP port number, as specified in Section 4.1. 1583 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- 1584 passwd", "a=ice-options", "a=candidate", "a=fingerprint", and 1585 "a=setup" lines MUST be included as mentioned above, along with an 1586 "a=sctpmap" line referencing the SCTP port number and specifying the 1587 application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. 1588 [OPEN ISSUE: the -01 of this document is missing this information.] 1590 If "a=group" attributes with semantics of "BUNDLE" are offered, 1591 corresponding session-level "a=group" attributes MUST be added as 1592 specified in [RFC5888]. These attributes MUST have semantics 1593 "BUNDLE", and MUST include the all mid identifiers from the offered 1594 BUNDLE groups that have not been rejected. Note that regardless of 1595 the presence of "a=bundle-only" in the offer, no m= sections in the 1596 answer should have an "a=bundle-only" line. 1598 Attributes that are common between all m= sections MAY be moved to 1599 session-level, if explicitly defined to be valid at session-level. 1601 The attributes prohibited in the creation of offers are also 1602 prohibited in the creation of answers. 1604 5.3.2. Subsequent Answers 1606 5.3.3. Constraints Handling 1608 5.4. Parsing an Offer 1610 5.5. Parsing an Answer 1612 5.6. Applying a Local Description 1614 5.7. Applying a Remote Description 1616 6. Configurable SDP Parameters 1618 Note: This section is still very early and is likely to significantly 1619 change as we get a better understanding of a) the use cases for this 1620 b) the implications at the protocol level c) feedback from 1621 implementors on what they can do. 1623 The following elements of the SDP media description MUST NOT be 1624 changed between the createOffer and the setLocalDescription, since 1625 they reflect transport attributes that are solely under browser 1626 control, and the browser MUST NOT honor an attempt to change them: 1628 o The number, type and port number of m-lines. 1630 o The generated ICE credentials (a=ice-ufrag and a=ice-pwd). 1632 o The set of ICE candidates and their parameters (a=candidate). 1634 The following modifications, if done by the browser to a description 1635 between createOffer/createAnswer and the setLocalDescription, MUST be 1636 honored by the browser: 1638 o Remove or reorder codecs (m=) 1640 The following parameters may be controlled by constraints passed into 1641 createOffer/createAnswer. As an open issue, these changes may also 1642 be be performed by manipulating the SDP returned from createOffer/ 1643 createAnswer, as indicated above, as long as the capabilities of the 1644 endpoint are not exceeded (e.g. asking for a resolution greater than 1645 what the endpoint can encode): 1647 o disable BUNDLE (a=group) 1649 o disable RTCP mux (a=rtcp-mux) 1651 o change send resolution or frame rate 1652 o change desired recv resolution or frame rate 1654 o change maximum total bandwidth (b=) [OPEN ISSUE: need to clarify 1655 if this is CT or AS - see section 5.8 of [RFC4566]] 1657 o remove desired AVPF mechanisms (a=rtcp-fb) 1659 o remove RTP header extensions (a=extmap) 1661 o change media send/recv state (a=sendonly/recvonly/inactive) 1663 For example, an application could implement call hold by adding an 1664 a=inactive attribute to its local description, and then applying and 1665 signaling that description. 1667 The application can also modify the SDP to reduce the capabilities in 1668 the offer it sends to the far side in any way the application sees 1669 fit, as long as it is a valid SDP offer and specifies a subset of 1670 what the browser is expecting to do. 1672 As always, the application is solely responsible for what it sends to 1673 the other party, and all incoming SDP will be processed by the 1674 browser to the extent of its capabilities. It is an error to assume 1675 that all SDP is well-formed; however, one should be able to assume 1676 that any implementation of this specification will be able to 1677 process, as a remote offer or answer, unmodified SDP coming from any 1678 other implementation of this specification. 1680 7. Security Considerations 1682 The intent of the WebRTC protocol suite is to provide an environment 1683 that is securable by default: all media is encrypted, keys are 1684 exchanged in a secure fashion, and the Javascript API includes 1685 functions that can be used to verify the identity of communication 1686 partners. 1688 8. IANA Considerations 1690 This document requires no actions from IANA. 1692 9. Acknowledgements 1694 Significant text incorporated in the draft as well and review was 1695 provided by Harald Alvestrand and Suhas Nandakumar. Dan Burnett, 1696 Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton, 1697 Richard Ejzak, and Adam Bergkvist all provided valuable feedback on 1698 this proposal. Matthew Kaufman provided the observation that keeping 1699 state out of the browser allows a call to continue even if the page 1700 is reloaded. 1702 10. References 1704 10.1. Normative References 1706 [I-D.ietf-mmusic-msid] 1707 Alvestrand, H., "Cross Session Stream Identification in 1708 the Session Description Protocol", draft-ietf-mmusic- 1709 msid-01 (work in progress), August 2013. 1711 [I-D.ietf-mmusic-sctp-sdp] 1712 Loreto, S. and G. Camarillo, "Stream Control Transmission 1713 Protocol (SCTP)-Based Media Transport in the Session 1714 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 1715 (work in progress), June 2013. 1717 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1718 Holmberg, C., Alvestrand, H., and C. Jennings, 1719 "Multiplexing Negotiation Using Session Description 1720 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 1721 bundle-negotiation-04 (work in progress), June 2013. 1723 [I-D.ietf-rtcweb-audio] 1724 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 1725 Requirements", draft-ietf-rtcweb-audio-02 (work in 1726 progress), August 2013. 1728 [I-D.ietf-rtcweb-rtp-usage] 1729 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1730 Communication (WebRTC): Media Transport and Use of RTP", 1731 draft-ietf-rtcweb-rtp-usage-09 (work in progress), 1732 September 2013. 1734 [I-D.nandakumar-mmusic-sdp-mux-attributes] 1735 Nandakumar, S., "A Framework for SDP Attributes when 1736 Multiplexing", draft-nandakumar-mmusic-sdp-mux- 1737 attributes-03 (work in progress), July 2013. 1739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1740 Requirement Levels", BCP 14, RFC 2119, March 1997. 1742 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1743 A., Peterson, J., Sparks, R., Handley, M., and E. 1744 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1745 June 2002. 1747 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1748 with Session Description Protocol (SDP)", RFC 3264, June 1749 2002. 1751 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1752 the Session Description Protocol (SDP)", RFC 4145, 1753 September 2005. 1755 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1756 Description Protocol", RFC 4566, July 2006. 1758 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1759 Transport Layer Security (TLS) Protocol in the Session 1760 Description Protocol (SDP)", RFC 4572, July 2006. 1762 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1763 "Extended RTP Profile for Real-time Transport Control 1764 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1765 2006. 1767 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1768 Real-time Transport Control Protocol (RTCP)-Based Feedback 1769 (RTP/SAVPF)", RFC 5124, February 2008. 1771 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1772 (ICE): A Protocol for Network Address Translator (NAT) 1773 Traversal for Offer/Answer Protocols", RFC 5245, April 1774 2010. 1776 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1777 Header Extensions", RFC 5285, July 2008. 1779 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1780 Control Packets on a Single Port", RFC 5761, April 2010. 1782 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1783 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1785 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1786 Real-time Transport Protocol (SRTP)", RFC 6904, April 1787 2013. 1789 10.2. Informative References 1791 [I-D.ietf-mmusic-trickle-ice] 1792 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1793 Incremental Provisioning of Candidates for the Interactive 1794 Connectivity Establishment (ICE) Protocol", draft-ietf- 1795 mmusic-trickle-ice-00 (work in progress), March 2013. 1797 [I-D.ietf-rtcweb-data-protocol] 1798 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1799 Protocol", draft-ietf-rtcweb-data-protocol-04 (work in 1800 progress), February 2013. 1802 [I-D.jennings-rtcweb-signaling] 1803 Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/ 1804 Answer Protocol (ROAP)", draft-jennings-rtcweb- 1805 signaling-01 (work in progress), October 2011. 1807 [I-D.nandakumar-rtcweb-sdp] 1808 Nandakumar, S. and C. Jennings, "SDP for the WebRTC", 1809 draft-nandakumar-rtcweb-sdp-02 (work in progress), July 1810 2013. 1812 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 1813 Comfort Noise (CN)", RFC 3389, September 2002. 1815 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1816 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 1817 3556, July 2003. 1819 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1820 Tone Generation in the Session Initiation Protocol (SIP)", 1821 RFC 3960, December 2004. 1823 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1824 Description Protocol (SDP) Security Descriptions for Media 1825 Streams", RFC 4568, July 2006. 1827 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1828 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1829 July 2006. 1831 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1832 Real-Time Transport Control Protocol (RTCP): Opportunities 1833 and Consequences", RFC 5506, April 2009. 1835 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1836 Media Attributes in the Session Description Protocol 1837 (SDP)", RFC 5576, June 2009. 1839 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1840 for Establishing a Secure Real-time Transport Protocol 1841 (SRTP) Security Context Using Datagram Transport Layer 1842 Security (DTLS)", RFC 5763, May 2010. 1844 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1845 Security (DTLS) Extension to Establish Keys for the Secure 1846 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1848 [W3C.WD-webrtc-20111027] 1849 Bergkvist, A., Burnett, D., Narayanan, A., and C. 1850 Jennings, "WebRTC 1.0: Real-time Communication Between 1851 Browsers", World Wide Web Consortium WD WD- 1852 webrtc-20111027, October 2011, 1853 . 1855 Appendix A. JSEP Implementation Examples 1857 A.1. Example API Flows 1859 Below are several sample flows for the new PeerConnection and library 1860 APIs, demonstrating when the various APIs are called in different 1861 situations and with various transport protocols. For clarity and 1862 simplicity, the createOffer/createAnswer calls are assumed to be 1863 synchronous in these examples, whereas the actual APIs are async. 1865 A.1.1. Call using ROAP 1867 This example demonstrates a ROAP call, without the use of trickle 1868 candidates. 1870 // Call is initiated toward Answerer 1871 OffererJS->OffererUA: pc = new PeerConnection(); 1872 OffererJS->OffererUA: pc.addStream(localStream, null); 1873 OffererUA->OffererJS: iceCallback(candidate); 1874 OffererJS->OffererUA: offer = pc.createOffer(null); 1875 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1876 OffererJS->AnswererJS: {"type":"OFFER", "sdp":offer } 1878 // OFFER arrives at Answerer 1879 AnswererJS->AnswererUA: pc = new PeerConnection(); 1880 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", msg.sdp); 1881 AnswererUA->AnswererJS: onaddstream(remoteStream); 1882 AnswererUA->OffererUA: iceCallback(candidate); 1884 // Answerer accepts call 1885 AnswererJS->AnswererUA: pc.addStream(localStream, null); 1886 AnswererJS->AnswererUA: answer = pc.createAnswer(msg.sdp, null); 1887 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1888 AnswererJS->OffererJS: {"type":"ANSWER","sdp":answer } 1890 // ANSWER arrives at Offerer 1891 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1892 OffererUA->OffererJS: onaddstream(remoteStream); 1894 // ICE Completes (at Answerer) 1895 AnswererUA->OffererUA: Media 1897 // ICE Completes (at Offerer) 1898 OffererJS->AnswererJS: {"type":"OK" } 1899 OffererUA->AnswererUA: Media 1901 A.1.2. Call using XMPP 1903 This example demonstrates an XMPP call, making use of trickle 1904 candidates. 1906 // Call is initiated toward Answerer 1907 OffererJS->OffererUA: pc = new PeerConnection(); 1908 OffererJS->OffererUA: pc.addStream(localStream, null); 1909 OffererJS->OffererUA: offer = pc.createOffer(null); 1910 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1911 OffererJS: xmpp = createSessionInitiate(offer); 1912 OffererJS->AnswererJS: 1914 OffererJS->OffererUA: pc.startIce(); 1915 OffererUA->OffererJS: onicecandidate(cand); 1916 OffererJS: createTransportInfo(cand); 1917 OffererJS->AnswererJS: 1919 // session-initiate arrives at Answerer 1920 AnswererJS->AnswererUA: pc = new PeerConnection(); 1921 AnswererJS: offer = parseSessionInitiate(xmpp); 1922 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer); 1923 AnswererUA->AnswererJS: onaddstream(remoteStream); 1925 // transport-infos arrive at Answerer 1926 AnswererJS->AnswererUA: candidate = parseTransportInfo(xmpp); 1927 AnswererJS->AnswererUA: pc.addIceCandidate(candidate); 1928 AnswererUA->AnswererJS: onicecandidate(cand) 1929 AnswererJS: createTransportInfo(cand); 1930 AnswererJS->OffererJS: 1932 // transport-infos arrive at Offerer 1933 OffererJS->OffererUA: candidates = parseTransportInfo(xmpp); 1934 OffererJS->OffererUA: pc.addIceCandidate(candidates); 1936 // Answerer accepts call 1937 AnswererJS->AnswererUA: pc.addStream(localStream, null); 1938 AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null); 1939 AnswererJS: xmpp = createSessionAccept(answer); 1940 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1941 AnswererJS->OffererJS: 1943 // session-accept arrives at Offerer 1944 OffererJS: answer = parseSessionAccept(xmpp); 1945 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1946 OffererUA->OffererJS: onaddstream(remoteStream); 1948 // ICE Completes (at Answerer) 1949 AnswererUA->OffererUA: Media 1951 // ICE Completes (at Offerer) 1952 OffererUA->AnswererUA: Media 1954 A.1.3. Adding video to a call, using XMPP 1956 This example demonstrates an XMPP call, where the XMPP content-add 1957 mechanism is used to add video media to an existing session. For 1958 simplicity, candidate exchange is not shown. 1960 Note that the offerer for the change to the session may be different 1961 than the original call offerer. 1963 // Offerer adds video stream 1964 OffererJS->OffererUA: pc.addStream(videoStream) 1965 OffererJS->OffererUA: offer = pc.createOffer(null); 1966 OffererJS: xmpp = createContentAdd(offer); 1967 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1968 OffererJS->AnswererJS: 1970 // content-add arrives at Answerer 1971 AnswererJS: offer = parseContentAdd(xmpp); 1972 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer); 1973 AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null); 1974 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1975 AnswererJS: xmpp = createContentAccept(answer); 1976 AnswererJS->OffererJS: 1978 // content-accept arrives at Offerer 1979 OffererJS: answer = parseContentAccept(xmpp); 1980 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1982 A.1.4. Simultaneous add of video streams, using XMPP 1984 This example demonstrates an XMPP call, where new video sources are 1985 added at the same time to a call that already has video; since adding 1986 these sources only affects one side of the call, there is no 1987 conflict. The XMPP description-info mechanism is used to indicate 1988 the new sources to the remote side. 1990 // Offerer and "Answerer" add video streams at the same time 1991 OffererJS->OffererUA: pc.addStream(offererVideoStream2) 1992 OffererJS->OffererUA: offer = pc.createOffer(null); 1993 OffererJS: xmpp = createDescriptionInfo(offer); 1994 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1995 OffererJS->AnswererJS: 1997 AnswererJS->AnswererUA: pc.addStream(answererVideoStream2) 1998 AnswererJS->AnswererUA: offer = pc.createOffer(null); 1999 AnswererJS: xmpp = createDescriptionInfo(offer); 2000 AnswererJS->AnswererUA: pc.setLocalDescription("offer", offer); 2001 AnswererJS->OffererJS: 2003 // description-info arrives at "Answerer", and is acked 2004 AnswererJS: offer = parseDescriptionInfo(xmpp); 2005 AnswererJS->OffererJS: // ack 2007 // description-info arrives at Offerer, and is acked 2008 OffererJS: offer = parseDescriptionInfo(xmpp); 2009 OffererJS->AnswererJS: // ack 2011 // ack arrives at Offerer; remote offer is used as an answer 2012 OffererJS->OffererUA: pc.setRemoteDescription("answer", offer); 2014 // ack arrives at "Answerer"; remote offer is used as an answer 2015 AnswererJS->AnswererUA: pc.setRemoteDescription("answer", offer); 2017 A.1.5. Call using SIP 2019 This example demonstrates a simple SIP call (e.g. where the client 2020 talks to a SIP proxy over WebSockets). 2022 // Call is initiated toward Answerer 2023 OffererJS->OffererUA: pc = new PeerConnection(); 2024 OffererJS->OffererUA: pc.addStream(localStream, null); 2025 OffererUA->OffererJS: onicecandidate(candidate); 2026 OffererJS->OffererUA: offer = pc.createOffer(null); 2027 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 2028 OffererJS: sip = createInvite(offer); 2029 OffererJS->AnswererJS: SIP INVITE w/ SDP 2031 // INVITE arrives at Answerer 2032 AnswererJS->AnswererUA: pc = new PeerConnection(); 2033 AnswererJS: offer = parseInvite(sip); 2034 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer); 2035 AnswererUA->AnswererJS: onaddstream(remoteStream); 2036 AnswererUA->OffererUA: onicecandidate(candidate); 2038 // Answerer accepts call 2039 AnswererJS->AnswererUA: pc.addStream(localStream, null); 2040 AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null); 2041 AnswererJS: sip = createResponse(200, answer); 2042 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 2043 AnswererJS->OffererJS: 200 OK w/ SDP 2045 // 200 OK arrives at Offerer 2046 OffererJS: answer = parseResponse(sip); 2047 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 2048 OffererUA->OffererJS: onaddstream(remoteStream); 2049 OffererJS->AnswererJS: ACK 2051 // ICE Completes (at Answerer) 2052 AnswererUA->OffererUA: Media 2054 // ICE Completes (at Offerer) 2055 OffererUA->AnswererUA: Media 2057 A.1.6. Handling early media (e.g. 1-800-GO FEDEX), using SIP 2059 This example demonstrates how early media could be handled; for 2060 simplicity, only the offerer side of the call is shown. 2062 // Call is initiated toward Answerer 2063 OffererJS->OffererUA: pc = new PeerConnection(); 2064 OffererJS->OffererUA: pc.addStream(localStream, null); 2065 OffererUA->OffererJS: onicecandidate(candidate); 2066 OffererJS->OffererUA: offer = pc.createOffer(null); 2067 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 2068 OffererJS: sip = createInvite(offer); 2069 OffererJS->AnswererJS: SIP INVITE w/ SDP 2071 // 180 Ringing is received by offerer, w/ SDP 2072 OffererJS: answer = parseResponse(sip); 2073 OffererJS->OffererUA: pc.setRemoteDescription("pranswer", answer); 2074 OffererUA->OffererJS: onaddstream(remoteStream); 2076 // ICE Completes (at Offerer) 2077 OffererUA->AnswererUA: Media 2079 // 200 OK arrives at Offerer 2080 OffererJS: answer = parseResponse(sip); 2081 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 2082 OffererJS->AnswererJS: ACK 2084 A.2. Example Session Descriptions 2086 A.2.1. createOffer 2088 This SDP shows a typical initial offer, created by createOffer for a 2089 PeerConnection with a single audio MediaStreamTrack, a single video 2090 MediaStreamTrack, and a single data channel. Host candidates have 2091 also already been gathered. Note some lines have been broken into 2092 two lines for formatting reasons. 2094 v=0 2095 o=- 4962303333179871722 1 IN IP4 0.0.0.0 2096 s=- 2097 t=0 0 2098 a=msid-semantic:WMS 2099 a=group:BUNDLE audio video data 2100 m=audio 56500 UDP/TLS/RTP/SAVPF 111 0 8 126 2101 c=IN IP4 192.0.2.1 2102 a=rtcp:56501 IN IP4 192.0.2.1 2103 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500 2104 typ host generation 0 2105 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501 2106 typ host generation 0 2107 a=ice-ufrag:ETEn1v9DoTMB9J4r 2108 a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl 2109 a=ice-options:trickle 2110 a=mid:audio 2111 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2112 a=sendrecv 2113 a=rtcp-mux 2114 a=rtcp-rsize 2115 a=fingerprint:sha-256 2116 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2117 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2118 a=setup:actpass 2119 a=rtpmap:111 opus/48000/2 2120 a=fmtp:111 minptime=10 2121 a=rtpmap:0 PCMU/8000 2122 a=rtpmap:8 PCMA/8000 2123 a=rtpmap:126 telephone-event/8000 2124 a=maxptime:60 2125 a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7 2126 a=msid:47017fee-b6c1-4162-929c-a25110252400 2127 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 2128 m=video 56502 UDP/TLS/RTP/SAVPF 100 115 116 117 2129 c=IN IP4 192.0.2.1 2130 a=rtcp:56503 IN IP4 192.0.2.1 2131 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502 2132 typ host generation 0 2133 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503 2134 typ host generation 0 2135 a=ice-ufrag:BGKkWnG5GmiUpdIV 2136 a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf 2137 a=ice-options:trickle 2138 a=mid:video 2139 a=extmap:2 urn:ietf:params:rtp-hdrext:toffset 2140 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 2141 a=sendrecv 2142 a=rtcp-mux 2143 a=rtcp-rsize 2144 a=fingerprint:sha-256 2145 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2146 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2147 a=setup:actpass 2148 a=rtpmap:100 VP8/90000 2149 a=rtcp-fb:100 ccm fir 2150 a=rtcp-fb:100 nack 2151 a=rtcp-fb:100 goog-remb 2152 a=rtpmap:115 rtx/90000 2153 a=fmtp:115 apt=100 2154 a=rtpmap:116 red/90000 2155 a=rtpmap:117 ulpfec/90000 2156 a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7 2157 a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7 2158 a=ssrc:1366781085 cname:EocUG1f0fcg/yvY7 2159 a=ssrc-group:FID 1366781083 1366781084 2160 a=ssrc-group:FEC 1366781083 1366781085 2161 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 2162 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 2163 m=application 56504 DTLS/SCTP 5000 2164 c=IN IP4 192.0.2.1 2165 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56504 2166 typ host generation 0 2167 a=ice-ufrag:VD5v2BnbZm3mgP3d 2168 a=ice-pwd:+Jlkuox+VVIUDqxcfIDuTZMH 2169 a=ice-options:trickle 2170 a=mid:data 2171 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2172 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2173 a=setup:actpass 2174 a=sctpmap:5000 webrtc-datachannel 16 2176 A.2.2. createAnswer 2178 This SDP shows a typical initial answer to the above offer, created 2179 by createAnswer for a PeerConnection with a single audio 2180 MediaStreamTrack, a single video MediaStreamTrack, and a single data 2181 channel. Host candidates have also already been gathered. Note some 2182 lines have been broken into two lines for formatting reasons. 2184 v=0 2185 o=- 6729291447651054566 1 IN IP4 0.0.0.0 2186 s=- 2187 t=0 0 2188 a=msid-semantic:WMS 2189 a=group:BUNDLE audio video data 2190 m=audio 20000 UDP/TLS/RTP/SAVPF 111 0 8 126 2191 c=IN IP4 192.0.2.2 2192 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2193 typ host generation 0 2194 a=ice-ufrag:6sFvz2gdLkEwjZEr 2195 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2196 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2197 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2198 a=setup:active 2199 a=mid:audio 2200 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2201 a=sendrecv 2202 a=rtcp-mux 2203 a=rtpmap:111 opus/48000/2 2204 a=fmtp:111 minptime=10 2205 a=rtpmap:0 PCMU/8000 2206 a=rtpmap:8 PCMA/8000 2207 a=rtpmap:126 telephone-event/8000 2208 a=maxptime:60 2209 a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5 2210 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2211 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 2212 m=video 20000 UDP/TLS/RTP/SAVPF 100 115 116 117 2213 c=IN IP4 192.0.2.2 2214 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2215 typ host generation 0 2216 a=ice-ufrag:6sFvz2gdLkEwjZEr 2217 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2218 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2219 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2220 a=setup:active 2221 a=mid:video 2222 a=extmap:2 urn:ietf:params:rtp-hdrext:toffset 2223 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 2224 a=sendrecv 2225 a=rtcp-mux 2226 a=rtpmap:100 VP8/90000 2227 a=rtcp-fb:100 ccm fir 2228 a=rtcp-fb:100 nack 2229 a=rtcp-fb:100 goog-remb 2230 a=rtpmap:115 rtx/90000 2231 a=fmtp:115 apt=100 2232 a=rtpmap:116 red/90000 2233 a=rtpmap:117 ulpfec/90000 2234 a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5 2235 a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5 2236 a=ssrc:3229706347 cname:Q/NWs1ao1HmN4Xa5 2237 a=ssrc-group:FID 3229706345 3229706346 2238 a=ssrc-group:FEC 3229706345 3229706347 2239 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2240 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0 2241 m=application 20000 DTLS/SCTP 5000 2242 c=IN IP4 192.0.2.2 2243 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2244 typ host generation 0 2245 a=ice-ufrag:6sFvz2gdLkEwjZEr 2246 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2247 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2248 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2249 a=setup:active 2250 a=mid:data 2251 a=sctpmap:5000 webrtc-datachannel 16 2253 A.2.3. Call Flows 2255 Example SDP for WebRTC call flows can be found in 2256 [I-D.nandakumar-rtcweb-sdp]. [TODO: should these call flows be 2257 merged into this section?] 2259 Appendix B. Change log 2261 Changes in draft-06: 2263 o Reworked handling of m= line recycling. 2265 o Added handling of BUNDLE and bundle-only. 2267 o Clarified handling of rollback. 2269 o Added text describing the ICE Candidate Pool and its behavior. 2271 o Allowed OfferToReceiveX to create multiple recvonly m= sections. 2273 Changes in draft-05: 2275 o Fixed several issues identified in the createOffer/Answer sections 2276 during document review. 2278 o Updated references. 2280 Changes in draft-04: 2282 o Filled in sections on createOffer and createAnswer. 2284 o Added SDP examples. 2286 o Fixed references. 2288 Changes in draft-03: 2290 o Added text describing relationship to W3C specification 2292 Changes in draft-02: 2294 o Converted from nroff 2296 o Removed comparisons to old approaches abandoned by the working 2297 group 2299 o Removed stuff that has moved to W3C specification 2300 o Align SDP handling with W3C draft 2302 o Clarified section on forking. 2304 Changes in draft-01: 2306 o Added diagrams for architecture and state machine. 2308 o Added sections on forking and rehydration. 2310 o Clarified meaning of "pranswer" and "answer". 2312 o Reworked how ICE restarts and media directions are controlled. 2314 o Added list of parameters that can be changed in a description. 2316 o Updated suggested API and examples to match latest thinking. 2318 o Suggested API and examples have been moved to an appendix. 2320 Changes in draft -00: 2322 o Migrated from draft-uberti-rtcweb-jsep-02. 2324 Authors' Addresses 2326 Justin Uberti 2327 Google 2328 747 6th Ave S 2329 Kirkland, WA 98033 2330 USA 2332 Email: justin@uberti.name 2334 Cullen Jennings 2335 Cisco 2336 170 West Tasman Drive 2337 San Jose, CA 95134 2338 USA 2340 Email: fluffy@iii.ca