idnits 2.17.1 draft-ietf-rtcweb-jsep-05.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 (October 22, 2013) is 3838 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 1662, 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: April 25, 2014 Cisco 6 October 22, 2013 8 Javascript Session Establishment Protocol 9 draft-ietf-rtcweb-jsep-05 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 April 25, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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 . . . . . . . . . . . . . . . 9 60 3.4. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3.4.1. ICE Candidate Trickling . . . . . . . . . . . . . . . 10 62 3.4.1.1. ICE Candidate Format . . . . . . . . . . . . . . 10 63 3.5. Interactions With Forking . . . . . . . . . . . . . . . . 11 64 3.5.1. Sequential Forking . . . . . . . . . . . . . . . . . 11 65 3.5.2. Parallel Forking . . . . . . . . . . . . . . . . . . 12 66 3.6. Session Rehydration . . . . . . . . . . . . . . . . . . . 13 67 4. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 4.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.1.1. createOffer . . . . . . . . . . . . . . . . . . . . . 14 70 4.1.2. createAnswer . . . . . . . . . . . . . . . . . . . . 15 71 4.1.3. SessionDescriptionType . . . . . . . . . . . . . . . 16 72 4.1.3.1. Use of Provisional Answers . . . . . . . . . . . 16 73 4.1.3.2. Rollback . . . . . . . . . . . . . . . . . . . . 17 74 4.1.4. setLocalDescription . . . . . . . . . . . . . . . . . 18 75 4.1.5. setRemoteDescription . . . . . . . . . . . . . . . . 18 76 4.1.6. localDescription . . . . . . . . . . . . . . . . . . 19 77 4.1.7. remoteDescription . . . . . . . . . . . . . . . . . . 19 78 4.1.8. updateIce . . . . . . . . . . . . . . . . . . . . . . 19 79 4.1.9. addIceCandidate . . . . . . . . . . . . . . . . . . . 19 80 5. SDP Interaction Procedures . . . . . . . . . . . . . . . . . 20 81 5.1. Requirements Overview . . . . . . . . . . . . . . . . . . 20 82 5.1.1. Implementation Requirements . . . . . . . . . . . . . 20 83 5.1.2. Usage Requirements . . . . . . . . . . . . . . . . . 21 84 5.2. Constructing an Offer . . . . . . . . . . . . . . . . . . 22 85 5.2.1. Initial Offers . . . . . . . . . . . . . . . . . . . 22 86 5.2.2. Subsequent Offers . . . . . . . . . . . . . . . . . . 26 87 5.2.3. Constraints Handling . . . . . . . . . . . . . . . . 28 88 5.2.3.1. OfferToReceiveAudio . . . . . . . . . . . . . . . 28 89 5.2.3.2. OfferToReceiveVideo . . . . . . . . . . . . . . . 28 90 5.2.3.3. VoiceActivityDetection . . . . . . . . . . . . . 28 91 5.2.3.4. IceRestart . . . . . . . . . . . . . . . . . . . 29 92 5.3. Generating an Answer . . . . . . . . . . . . . . . . . . 29 93 5.3.1. Initial Answers . . . . . . . . . . . . . . . . . . . 29 94 5.3.2. Subsequent Answers . . . . . . . . . . . . . . . . . 33 95 5.3.3. Constraints Handling . . . . . . . . . . . . . . . . 33 96 5.4. Parsing an Offer . . . . . . . . . . . . . . . . . . . . 33 97 5.5. Parsing an Answer . . . . . . . . . . . . . . . . . . . . 33 98 5.6. Applying a Local Description . . . . . . . . . . . . . . 33 99 5.7. Applying a Remote Description . . . . . . . . . . . . . . 33 100 6. Configurable SDP Parameters . . . . . . . . . . . . . . . . . 33 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 35 106 10.2. Informative References . . . . . . . . . . . . . . . . . 37 107 Appendix A. JSEP Implementation Examples . . . . . . . . . . . . 38 108 A.1. Example API Flows . . . . . . . . . . . . . . . . . . . . 38 109 A.1.1. Call using ROAP . . . . . . . . . . . . . . . . . . . 38 110 A.1.2. Call using XMPP . . . . . . . . . . . . . . . . . . . 39 111 A.1.3. Adding video to a call, using XMPP . . . . . . . . . 40 112 A.1.4. Simultaneous add of video streams, using XMPP . . . . 41 113 A.1.5. Call using SIP . . . . . . . . . . . . . . . . . . . 41 114 A.1.6. Handling early media (e.g. 1-800-GO FEDEX), using SIP 42 115 A.2. Example Session Descriptions . . . . . . . . . . . . . . 43 116 A.2.1. createOffer . . . . . . . . . . . . . . . . . . . . . 43 117 A.2.2. createAnswer . . . . . . . . . . . . . . . . . . . . 45 118 A.2.3. Call Flows . . . . . . . . . . . . . . . . . . . . . 46 119 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 46 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 122 1. Introduction 124 This document describes how the W3C WEBRTC RTCPeerConnection 125 interface[W3C.WD-webrtc-20111027] is used to control the setup, 126 management and teardown of a multimedia session. 128 1.1. General Design of JSEP 130 The thinking behind WebRTC call setup has been to fully specify and 131 control the media plane, but to leave the signaling plane up to the 132 application as much as possible. The rationale is that different 133 applications may prefer to use different protocols, such as the 134 existing SIP or Jingle call signaling protocols, or something custom 135 to the particular application, perhaps for a novel use case. In this 136 approach, the key information that needs to be exchanged is the 137 multimedia session description, which specifies the necessary 138 transport and media configuration information necessary to establish 139 the media plane. 141 The browser environment also has its own challenges that pose 142 problems for an embedded signaling state machine. One of these is 143 that the user may reload the web page at any time. If the browser is 144 fully in charge of the signaling state, this will result in the loss 145 of the call when this state is wiped by the reload. However, if the 146 state can be stored at the server, and pushed back down to the new 147 page, the call can be resumed with minimal interruption. 149 With these considerations in mind, this document describes the 150 Javascript Session Establishment Protocol (JSEP) that allows for full 151 control of the signaling state machine from Javascript. This 152 mechanism effectively removes the browser almost completely from the 153 core signaling flow; the only interface needed is a way for the 154 application to pass in the local and remote session descriptions 155 negotiated by whatever signaling mechanism is used, and a way to 156 interact with the ICE state machine. 158 In this document, the use of JSEP is described as if it always occurs 159 between two browsers. Note though in many cases it will actually be 160 between a browser and some kind of server, such as a gateway or MCU. 161 This distinction is invisible to the browser; it just follows the 162 instructions it is given via the API. 164 JSEP's handling of session descriptions is simple and 165 straightforward. Whenever an offer/answer exchange is needed, the 166 initiating side creates an offer by calling a createOffer() API. The 167 application optionally modifies that offer, and then uses it to set 168 up its local config via the setLocalDescription() API. The offer is 169 then sent off to the remote side over its preferred signaling 170 mechanism (e.g., WebSockets); upon receipt of that offer, the remote 171 party installs it using the setRemoteDescription() API. 173 When the call is accepted, the callee uses the createAnswer() API to 174 generate an appropriate answer, applies it using 175 setLocalDescription(), and sends the answer back to the initiator 176 over the signaling channel. When the offerer gets that answer, it 177 installs it using setRemoteDescription(), and initial setup is 178 complete. This process can be repeated for additional offer/answer 179 exchanges. 181 Regarding ICE [RFC5245], JSEP decouples the ICE state machine from 182 the overall signaling state machine, as the ICE state machine must 183 remain in the browser, because only the browser has the necessary 184 knowledge of candidates and other transport info. Performing this 185 separation also provides additional flexibility; in protocols that 186 decouple session descriptions from transport, such as Jingle, the 187 transport information can be sent separately; in protocols that 188 don't, such as SIP, the information can be used in the aggregated 189 form. Sending transport information separately can allow for faster 190 ICE and DTLS startup, since the necessary roundtrips can occur while 191 waiting for the remote side to accept the session. 193 Through its abstraction of signaling, the JSEP approach does require 194 the application to be aware of the signaling process. While the 195 application does not need to understand the contents of session 196 descriptions to set up a call, the application must call the right 197 APIs at the right times, convert the session descriptions and ICE 198 information into the defined messages of its chosen signaling 199 protocol, and perform the reverse conversion on the messages it 200 receives from the other side. 202 One way to mitigate this is to provide a Javascript library that 203 hides this complexity from the developer; said library would 204 implement a given signaling protocol along with its state machine and 205 serialization code, presenting a higher level call-oriented interface 206 to the application developer. For example, this library could easily 207 adapt the JSEP API into the API that was proposed for the ROAP 208 signaling protocol [I-D.jennings-rtcweb-signaling], which would 209 perform a ROAP call setup under the covers, interacting with the 210 application only when it needs a signaling message to be sent. In 211 the same fashion, one could also implement other popular signaling 212 protocols, including SIP or Jingle. This allow JSEP to provide 213 greater control for the experienced developer without forcing any 214 additional complexity on the novice developer. 216 1.2. Other Approaches Considered 218 One approach that was considered instead of JSEP was to include a 219 lightweight signaling protocol. Instead of providing session 220 descriptions to the API, the API would produce and consume messages 221 from this protocol. While providing a more high-level API, this put 222 more control of signaling within the browser, forcing the browser to 223 have to understand and handle concepts like signaling glare. In 224 addition, it prevented the application from driving the state machine 225 to a desired state, as is needed in the page reload case. 227 A second approach that was considered but not chosen was to decouple 228 the management of the media control objects from session 229 descriptions, instead offering APIs that would control each component 230 directly. This was rejected based on a feeling that requiring 231 exposure of this level of complexity to the application programmer 232 would not be beneficial; it would result in an API where even a 233 simple example would require a significant amount of code to 234 orchestrate all the needed interactions, as well as creating a large 235 API surface that needed to be agreed upon and documented. In 236 addition, these API points could be called in any order, resulting in 237 a more complex set of interactions with the media subsystem than the 238 JSEP approach, which specifies how session descriptions are to be 239 evaluated and applied. 241 One variation on JSEP that was considered was to keep the basic 242 session description-oriented API, but to move the mechanism for 243 generating offers and answers out of the browser. Instead of 244 providing createOffer/createAnswer methods within the browser, this 245 approach would instead expose a getCapabilities API which would 246 provide the application with the information it needed in order to 247 generate its own session descriptions. This increases the amount of 248 work that the application needs to do; it needs to know how to 249 generate session descriptions from capabilities, and especially how 250 to generate the correct answer from an arbitrary offer and the 251 supported capabilities. While this could certainly be addressed by 252 using a library like the one mentioned above, it basically forces the 253 use of said library even for a simple example. Providing createOffer 254 /createAnswer avoids this problem, but still allows applications to 255 generate their own offers/answers (to a large extent) if they choose, 256 using the description generated by createOffer as an indication of 257 the browser's capabilities. 259 2. Terminology 261 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 262 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 263 document are to be interpreted as described in [RFC2119]. 265 3. Semantics and Syntax 267 3.1. Signaling Model 269 JSEP does not specify a particular signaling model or state machine, 270 other than the generic need to exchange SDP media descriptions in the 271 fashion described by [RFC3264] (offer/answer) in order for both sides 272 of the session to know how to conduct the session. JSEP provides 273 mechanisms to create offers and answers, as well as to apply them to 274 a session. However, the browser is totally decoupled from the actual 275 mechanism by which these offers and answers are communicated to the 276 remote side, including addressing, retransmission, forking, and glare 277 handling. These issues are left entirely up to the application; the 278 application has complete control over which offers and answers get 279 handed to the browser, and when. 281 +-----------+ +-----------+ 282 | Web App |<--- App-Specific Signaling -->| Web App | 283 +-----------+ +-----------+ 284 ^ ^ 285 | SDP | SDP 286 V V 287 +-----------+ +-----------+ 288 | Browser |<----------- Media ------------>| Browser | 289 +-----------+ +-----------+ 291 Figure 1: JSEP Signaling Model 293 3.2. Session Descriptions and State Machine 295 In order to establish the media plane, the user agent needs specific 296 parameters to indicate what to transmit to the remote side, as well 297 as how to handle the media that is received. These parameters are 298 determined by the exchange of session descriptions in offers and 299 answers, and there are certain details to this process that must be 300 handled in the JSEP APIs. 302 Whether a session description applies to the local side or the remote 303 side affects the meaning of that description. For example, the list 304 of codecs sent to a remote party indicates what the local side is 305 willing to receive, which, when intersected with the set of codecs 306 the remote side supports, specifies what the remote side should send. 307 However, not all parameters follow this rule; for example, the SRTP 308 parameters [RFC4568] sent to a remote party indicate what the local 309 side will use to encrypt, and thereby what the remote party should 310 expect to receive; the remote party will have to accept these 311 parameters, with no option to choose a different value. 313 In addition, various RFCs put different conditions on the format of 314 offers versus answers. For example, a offer may propose multiple 315 SRTP configurations, but an answer may only contain a single SRTP 316 configuration. 318 Lastly, while the exact media parameters are only known only after a 319 offer and an answer have been exchanged, it is possible for the 320 offerer to receive media after they have sent an offer and before 321 they have received an answer. To properly process incoming media in 322 this case, the offerer's media handler must be aware of the details 323 of the offer before the answer arrives. 325 Therefore, in order to handle session descriptions properly, the user 326 agent needs: 328 1. To know if a session description pertains to the local or remote 329 side. 331 2. To know if a session description is an offer or an answer. 333 3. To allow the offer to be specified independently of the answer. 335 JSEP addresses this by adding both a setLocalDescription and a 336 setRemoteDescription method and having session description objects 337 contain a type field indicating the type of session description being 338 supplied. This satisfies the requirements listed above for both the 339 offerer, who first calls setLocalDescription(sdp [offer]) and then 340 later setRemoteDescription(sdp [answer]), as well as for the 341 answerer, who first calls setRemoteDescription(sdp [offer]) and then 342 later setLocalDescription(sdp [answer]). 344 JSEP also allows for an answer to be treated as provisional by the 345 application. Provisional answers provide a way for an answerer to 346 communicate initial session parameters back to the offerer, in order 347 to allow the session to begin, while allowing a final answer to be 348 specified later. This concept of a final answer is important to the 349 offer/answer model; when such an answer is received, any extra 350 resources allocated by the caller can be released, now that the exact 351 session configuration is known. These "resources" can include things 352 like extra ICE components, TURN candidates, or video decoders. 353 Provisional answers, on the other hand, do no such deallocation 354 results; as a result, multiple dissimilar provisional answers can be 355 received and applied during call setup. 357 In [RFC3264], the constraint at the signaling level is that only one 358 offer can be outstanding for a given session, but from the media 359 stack level, a new offer can be generated at any point. For example, 360 when using SIP for signaling, if one offer is sent, then cancelled 361 using a SIP CANCEL, another offer can be generated even though no 362 answer was received for the first offer. To support this, the JSEP 363 media layer can provide an offer whenever the Javascript application 364 needs one for the signaling. The answerer can send back zero or more 365 provisional answers, and finally end the offer-answer exchange by 366 sending a final answer. The state machine for this is as follows: 368 setRemote(OFFER) setLocal(PRANSWER) 369 /-----\ /-----\ 370 | | | | 371 v | v | 372 +---------------+ | +---------------+ | 373 | |----/ | |----/ 374 | | setLocal(PRANSWER) | | 375 | Remote-Offer |------------------- >| Local-Pranswer| 376 | | | | 377 | | | | 378 +---------------+ +---------------+ 379 ^ | | 380 | | setLocal(ANSWER) | 381 setRemote(OFFER) | | 382 | V setLocal(ANSWER) | 383 +---------------+ | 384 | | | 385 | | | 386 | Stable |<---------------------------+ 387 | | | 388 | | | 389 +---------------+ setRemote(ANSWER) | 390 ^ | | 391 | | setLocal(OFFER) | 392 setRemote(ANSWER) | | 393 | V | 394 +---------------+ +---------------+ 395 | | | | 396 | | setRemote(PRANSWER) | | 397 | Local-Offer |------------------- >|Remote-Pranswer| 398 | | | | 399 | |----\ | |----\ 400 +---------------+ | +---------------+ | 401 ^ | ^ | 402 | | | | 403 \-----/ \-----/ 404 setLocal(OFFER) setRemote(PRANSWER) 406 Figure 2: JSEP State Machine 408 Aside from these state transitions, there is no other difference 409 between the handling of provisional ("pranswer") and final ("answer") 410 answers. 412 3.3. Session Description Format 414 In the WebRTC specification, session descriptions are formatted as 415 SDP messages. While this format is not optimal for manipulation from 416 Javascript, it is widely accepted, and frequently updated with new 417 features. Any alternate encoding of session descriptions would have 418 to keep pace with the changes to SDP, at least until the time that 419 this new encoding eclipsed SDP in popularity. As a result, JSEP 420 currently uses SDP as the internal representation for its session 421 descriptions. 423 However, to simplify Javascript processing, and provide for future 424 flexibility, the SDP syntax is encapsulated within a 425 SessionDescription object, which can be constructed from SDP, and be 426 serialized out to SDP. If future specifications agree on a JSON 427 format for session descriptions, we could easily enable this object 428 to generate and consume that JSON. 430 Other methods may be added to SessionDescription in the future to 431 simplify handling of SessionDescriptions from Javascript. In the 432 meantime, Javascript libraries can be used to perform these 433 manipulations. 435 Note that most applications should be able to treat the 436 SessionDescriptions produced and consumed by these various API calls 437 as opaque blobs; that is, the application will not need to read or 438 change them. The W3C API will provide appropriate APIs to allow the 439 application to control various session parameters, which will provide 440 the necessary information to the browser about what sort of 441 SessionDescription to produce. 443 3.4. ICE 445 When a new ICE candidate is available, the ICE Agent will notify the 446 application via a callback; these candidates will automatically be 447 added to the local session description. When all candidates have 448 been gathered, the callback will also be invoked to signal that the 449 gathering process is complete. 451 3.4.1. ICE Candidate Trickling 453 Candidate trickling is a technique through which a caller may 454 incrementally provide candidates to the callee after the initial 455 offer has been dispatched; the semantics of "Trickle ICE" are defined 456 in [I-D.ietf-mmusic-trickle-ice]. This process allows the callee to 457 begin acting upon the call and setting up the ICE (and perhaps DTLS) 458 connections immediately, without having to wait for the caller to 459 gather all possible candidates. This results in faster call startup 460 in cases where gathering is not performed prior to initiating the 461 call. 463 JSEP supports optional candidate trickling by providing APIs that 464 provide control and feedback on the ICE candidate gathering process. 465 Applications that support candidate trickling can send the initial 466 offer immediately and send individual candidates when they get the 467 notified of a new candidate; applications that do not support this 468 feature can simply wait for the indication that gathering is 469 complete, and then create and send their offer, with all the 470 candidates, at this time. 472 Upon receipt of trickled candidates, the receiving application will 473 supply them to its ICE Agent. This triggers the ICE Agent to start 474 using the new remote candidates for connectivity checks. 476 3.4.1.1. ICE Candidate Format 477 As with session descriptions, the syntax of the IceCandidate object 478 provides some abstraction, but can be easily converted to and from 479 the SDP candidate lines. 481 The candidate lines are the only SDP information that is contained 482 within IceCandidate, as they represent the only information needed 483 that is not present in the initial offer (i.e. for trickle 484 candidates). This information is carried with the same syntax as the 485 "candidate-attribute" field defined for ICE. For example: 487 candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host 489 The IceCandidate object also contains fields to indicate which m= 490 line it should be associated with. The m line can be identified in 491 one of two ways; either by a m-line index, or a MID. The m-line 492 index is a zero-based index, referring to the Nth m-line in the SDP. 493 The MID uses the "media stream identification", as defined in 494 [RFC5888] , to identify the m-line. WebRTC implementations creating 495 an ICE Candidate object MUST populate both of these fields. 496 Implementations receiving an ICE Candidate object SHOULD use the MID 497 if they implement that functionality, or the m-line index, if not. 499 3.5. Interactions With Forking 501 Some call signaling systems allow various types of forking where an 502 SDP Offer may be provided to more than one device. For example, SIP 503 [RFC3261] defines both a "Parallel Search" and "Sequential Search". 504 Although these are primarily signaling level issues that are outside 505 the scope of JSEP, they do have some impact on the configuration of 506 the media plane which is relevant. When forking happens at the 507 signaling layer, the Javascript application responsible for the 508 signaling needs to make the decisions about what media should be sent 509 or received at any point of time, as well as which remote endpoint it 510 should communicate with; JSEP is used to make sure the media engine 511 can make the RTP and media perform as required by the application. 512 The basic operations that the applications can have the media engine 513 do are: 515 Start exchanging media to a given remote peer, but keep all the 516 resources reserved in the offer. 518 Start exchanging media with a given remote peer, and free any 519 resources in the offer that are not being used. 521 3.5.1. Sequential Forking 522 Sequential forking involves a call being dispatched to multiple 523 remote callees, where each callee can accept the call, but only one 524 active session ever exists at a time; no mixing of received media is 525 performed. 527 JSEP handles sequential forking well, allowing the application to 528 easily control the policy for selecting the desired remote endpoint. 529 When an answer arrives from one of the callees, the application can 530 choose to apply it either as a provisional answer, leaving open the 531 possibility of using a different answer in the future, or apply it as 532 a final answer, ending the setup flow. 534 In a "first-one-wins" situation, the first answer will be applied as 535 a final answer, and the application will reject any subsequent 536 answers. In SIP parlance, this would be ACK + BYE. 538 In a "last-one-wins" situation, all answers would be applied as 539 provisional answers, and any previous call leg will be terminated. 540 At some point, the application will end the setup process, perhaps 541 with a timer; at this point, the application could reapply the 542 existing remote description as a final answer. 544 3.5.2. Parallel Forking 546 Parallel forking involves a call being dispatched to multiple remote 547 callees, where each callee can accept the call, and multiple 548 simultaneous active signaling sessions can be established as a 549 result. If multiple callees send media at the same time, the 550 possibilities for handling this are described in Section 3.1 of 551 [RFC3960]. Most SIP devices today only support exchanging media with 552 a single device at a time, and do not try to mix multiple early media 553 audio sources, as that could result in a confusing situation. For 554 example, consider having a European ringback tone mixed together with 555 the North American ringback tone - the resulting sound would not be 556 like either tone, and would confuse the user. If the signaling 557 application wishes to only exchange media with one of the remote 558 endpoints at a time, then from a media engine point of view, this is 559 exactly like the sequential forking case. 561 In the parallel forking case where the Javascript application wishes 562 to simultaneously exchange media with multiple peers, the flow is 563 slightly more complex, but the Javascript application can follow the 564 strategy that [RFC3960] describes using UPDATE. (It is worth noting 565 that use cases where this is the desired behavior are very unusual.) 566 The UPDATE approach allows the signaling to set up a separate media 567 flow for each peer that it wishes to exchange media with. In JSEP, 568 this offer used in the UPDATE would be formed by simply creating a 569 new PeerConnection and making sure that the same local media streams 570 have been added into this new PeerConnection. Then the new 571 PeerConnection object would produce a SDP offer that could be used by 572 the signaling to perform the UPDATE strategy discussed in [RFC3960]. 574 As a result of sharing the media streams, the application will end up 575 with N parallel PeerConnection sessions, each with a local and remote 576 description and their own local and remote addresses. The media flow 577 from these sessions can be managed by specifying SDP direction 578 attributes in the descriptions, or the application can choose to play 579 out the media from all sessions mixed together. Of course, if the 580 application wants to only keep a single session, it can simply 581 terminate the sessions that it no longer needs. 583 3.6. Session Rehydration 585 In the event that the local application state is reinitialized, 586 either due to a user reload of the page, or a decision within the 587 application to reload itself (perhaps to update to a new version), it 588 is possible to keep an existing session alive, via a process called 589 "rehydration". The explicit goal of rehydration is to carry out this 590 session resumption with no interaction with the remote side other 591 than normal call signaling messages. 593 With rehydration, the current signaling state is persisted somewhere 594 outside of the page, perhaps on the application server, or in browser 595 local storage. The page is then reloaded, the saved signaling state 596 is retrieved, and a new PeerConnection object is created for the 597 session. The previously obtained MediaStreams are re-acquired, and 598 are given the same IDs as the original session; this ensures the IDs 599 in use by the remote side continue to work. Next, a new offer is 600 generated by the new PeerConnection; this offer will have new ICE and 601 possibly new DTLS-SRTP certificate fingerprints (since the old ICE 602 and SRTP state has been lost). Finally, this offer is used to re- 603 initiate the session with the existing remote endpoint, who simply 604 sees the new offer as an in-call renegotiation, and replies with an 605 answer that can be supplied to setRemoteDescription. ICE processing 606 proceeds as usual, and as soon as connectivity is established, the 607 session will be back up and running again. 609 [OPEN ISSUE: EKR proposed an alternative rehydration approach where 610 the actual internal PeerConnection object in the browser was kept 611 alive for some time after the web page was killed and provided some 612 way for a new page to acquire the old PeerConnection object.] 614 4. Interface 616 This section details the basic operations that must be present to 617 implement JSEP functionality. The actual API exposed in the W3C API 618 may have somewhat different syntax, but should map easily to these 619 concepts. 621 4.1. Methods 623 4.1.1. createOffer 625 The createOffer method generates a blob of SDP that contains a 626 [RFC3264] offer with the supported configurations for the session, 627 including descriptions of the local MediaStreams attached to this 628 PeerConnection, the codec/RTP/RTCP options supported by this 629 implementation, and any candidates that have been gathered by the ICE 630 Agent. A constraints parameters may be supplied to provide 631 additional control over the generated offer. This constraints 632 parameter should allow for the following manipulations to be 633 performed: 635 o To indicate support for a media type even if no MediaStreamTracks 636 of that type have been added to the session (e.g., an audio call 637 that wants to receive video.) 639 o To trigger an ICE restart, for the purpose of reestablishing 640 connectivity. 642 o For re-offer cases, to request an offer that contains the full set 643 of supported capabilities, as opposed to just the currently 644 negotiated parameters. 646 In the initial offer, the generated SDP will contain all desired 647 functionality for the session (certain parts that are supported but 648 not desired by default may be omitted); for each SDP line, the 649 generation of the SDP will follow the process defined for generating 650 an initial offer from the document that specifies the given SDP line. 651 The exact handling of initial offer generation is detailed in 652 Section 5.2.1. below. 654 In the event createOffer is called after the session is established, 655 createOffer will generate an offer to modify the current session 656 based on any changes that have been made to the session, e.g. adding 657 or removing MediaStreams, or requesting an ICE restart. For each 658 existing stream, the generation of each SDP line must follow the 659 process defined for generating an updated offer from the document 660 that specifies the given SDP line. For each new stream, the 661 generation of the SDP must follow the process of generating an 662 initial offer, as mentioned above. If no changes have been made, or 663 for SDP lines that are unaffected by the requested changes, the offer 664 will only contain the parameters negotiated by the last offer-answer 665 exchange. The exact handling of subsequent offer generation is 666 detailed in Section 5.2.2. below. 668 Session descriptions generated by createOffer must be immediately 669 usable by setLocalDescription; if a system has limited resources 670 (e.g. a finite number of decoders), createOffer should return an 671 offer that reflects the current state of the system, so that 672 setLocalDescription will succeed when it attempts to acquire those 673 resources. Because this method may need to inspect the system state 674 to determine the currently available resources, it may be implemented 675 as an async operation. 677 Calling this method may do things such as generate new ICE 678 credentials, but does not result in candidate gathering, or cause 679 media to start or stop flowing. 681 4.1.2. createAnswer 683 The createAnswer method generates a blob of SDP that contains a 684 [RFC3264] SDP answer with the supported configuration for the session 685 that is compatible with the parameters supplied in the offer. Like 686 createOffer, the returned blob contains descriptions of the local 687 MediaStreams attached to this PeerConnection, the codec/RTP/RTCP 688 options negotiated for this session, and any candidates that have 689 been gathered by the ICE Agent. A constraints parameter may be 690 supplied to provide additional control over the generated answer. 692 As an answer, the generated SDP will contain a specific configuration 693 that specifies how the media plane should be established; for each 694 SDP line, the generation of the SDP must follow the process defined 695 for generating an answer from the document that specifies the given 696 SDP line. The exact handling of answer generation is detailed in 697 Section 5.3. below. 699 Session descriptions generated by createAnswer must be immediately 700 usable by setLocalDescription; like createOffer, the returned 701 description should reflect the current state of the system. Because 702 this method may need to inspect the system state to determine the 703 currently available resources, it may need to be implemented as an 704 async operation. 706 Calling this method may do things such as generate new ICE 707 credentials, but does not trigger candidate gathering or change media 708 state. 710 4.1.3. SessionDescriptionType 712 Session description objects (RTCSessionDescription) may be of type 713 "offer", "pranswer", and "answer". These types provide information 714 as to how the description parameter should be parsed, and how the 715 media state should be changed. 717 "offer" indicates that a description should be parsed as an offer; 718 said description may include many possible media configurations. A 719 description used as an "offer" may be applied anytime the 720 PeerConnection is in a stable state, or as an update to a previously 721 supplied but unanswered "offer". 723 "pranswer" indicates that a description should be parsed as an 724 answer, but not a final answer, and so should not result in the 725 freeing of allocated resources. It may result in the start of media 726 transmission, if the answer does not specify an inactive media 727 direction. A description used as a "pranswer" may be applied as a 728 response to an "offer", or an update to a previously sent "answer". 730 "answer" indicates that a description should be parsed as an answer, 731 the offer-answer exchange should be considered complete, and any 732 resources (decoders, candidates) that are no longer needed can be 733 released. A description used as an "answer" may be applied as a 734 response to a "offer", or an update to a previously sent "pranswer". 736 The only difference between a provisional and final answer is that 737 the final answer results in the freeing of any unused resources that 738 were allocated as a result of the offer. As such, the application 739 can use some discretion on whether an answer should be applied as 740 provisional or final, and can change the type of the session 741 description as needed. For example, in a serial forking scenario, an 742 application may receive multiple "final" answers, one from each 743 remote endpoint. The application could choose to accept the initial 744 answers as provisional answers, and only apply an answer as final 745 when it receives one that meets its criteria (e.g. a live user 746 instead of voicemail). 748 4.1.3.1. Use of Provisional Answers 749 Most web applications will not need to create answers using the 750 "pranswer" type. The preferred handling for a web application would 751 be to create and send an "inactive" answer more or less immediately 752 after receiving the offer, instead of waiting for a human user to 753 physically answer the call. Later, when the human input is received, 754 the application can create a new "sendrecv" offer to update the 755 previous offer/answer pair and start the media flow. This approach 756 is preferred because it minimizes the amount of time that the offer- 757 answer exchange is left open, in addition to avoiding media clipping 758 by ensuring the transport is ready to go by the time the call is 759 physically answered. However, some applications may not be able to 760 do this, particularly ones that are attempting to gateway to other 761 signaling protocols. In these cases, "pranswer" can still allow the 762 application to warm up the transport. 764 Consider a typical web application that will set up a data channel, 765 an audio channel, and a video channel. When an endpoint receives an 766 offer with these channels, it could send an answer accepting the data 767 channel for two-way data, and accepting the audio and video tracks as 768 inactive or receive-only. It could then ask the user to accept the 769 call, acquire the local media streams, and send a new offer to the 770 remote side moving the audio and video to be two-way media. By the 771 time the human has accepted the call and sent the new offer, it is 772 likely that the ICE and DTLS handshaking for all the channels will 773 already be set up. 775 4.1.3.2. Rollback 777 In certain situations it may be desirable to "undo" a change made to 778 setLocalDescription or setRemoteDescription. Consider a case where a 779 call is ongoing, and one side wants to change some of the session 780 parameters; that side generates an updated offer and then calls 781 setLocalDescription. However, the remote side, either before or 782 after setRemoteDescription, decides it does not want to accept the 783 new parameters, and sends a reject message back to the offerer. Now, 784 the offerer, and possibly the answerer as well, need to return to a 785 stable state and the previous local/remote description. To support 786 this, we introduce the concept of "rollback". 788 A rollback returns the state machine to its previous state, and the 789 local or remote description to its previous value. Any resources or 790 candidates that were allocated by the new local description are 791 discarded; any media that is received will be processed according to 792 the previous session description. 794 A rollback is performed by supplying a session description of type 795 "rollback" to either setLocalDescription or setRemoteDescription, 796 depending on which needs to be rolled back (i.e. if the new offer was 797 supplied to setLocalDescription, the rollback should be done on 798 setLocalDescription as well.) 800 4.1.4. setLocalDescription 802 The setLocalDescription method instructs the PeerConnection to apply 803 the supplied SDP blob as its local configuration. The type field 804 indicates whether the blob should be processed as an offer, 805 provisional answer, or final answer; offers and answers are checked 806 differently, using the various rules that exist for each SDP line. 808 This API changes the local media state; among other things, it sets 809 up local resources for receiving and decoding media. In order to 810 successfully handle scenarios where the application wants to offer to 811 change from one media format to a different, incompatible format, the 812 PeerConnection must be able to simultaneously support use of both the 813 old and new local descriptions (e.g. support codecs that exist in 814 both descriptions) until a final answer is received, at which point 815 the PeerConnection can fully adopt the new local description, or roll 816 back to the old description if the remote side denied the change. 818 This API indirectly controls the candidate gathering process. When a 819 local description is supplied, and the number of transports currently 820 in use does not match the number of transports needed by the local 821 description, the PeerConnection will create transports as needed and 822 begin gathering candidates for them. 824 If setRemoteDescription was previous called with an offer, and 825 setLocalDescription is called with an answer (provisional or final), 826 and the media directions are compatible, and media are available to 827 send, this will result in the starting of media transmission. 829 4.1.5. setRemoteDescription 831 The setRemoteDescription method instructs the PeerConnection to apply 832 the supplied SDP blob as the desired remote configuration. As in 833 setLocalDescription, the type field of the indicates how the blob 834 should be processed. 836 This API changes the local media state; among other things, it sets 837 up local resources for sending and encoding media. 839 If setRemoteDescription was previously called with an offer, and 840 setLocalDescription is called with an answer (provisional or final), 841 and the media directions are compatible, and media are available to 842 send, this will result in the starting of media transmission. 844 4.1.6. localDescription 846 The localDescription method returns a copy of the current local 847 configuration, i.e. what was most recently passed to 848 setLocalDescription, plus any local candidates that have been 849 generated by the ICE Agent. 851 TODO: Do we need to expose accessors for both the current and 852 proposed local description? 854 A null object will be returned if the local description has not yet 855 been established, or if the PeerConnection has been closed. 857 4.1.7. remoteDescription 859 The remoteDescription method returns a copy of the current remote 860 configuration, i.e. what was most recently passed to 861 setRemoteDescription, plus any remote candidates that have been 862 supplied via processIceMessage. 864 TODO: Do we need to expose accessors for both the current and 865 proposed remote description? 867 A null object will be returned if the remote description has not yet 868 been established, or if the PeerConnection has been closed. 870 4.1.8. updateIce 872 The updateIce method allows the configuration of the ICE Agent to be 873 changed during the session, primarily for changing which types of 874 local candidates are provided to the application and used for 875 connectivity checks. A callee may initially configure the ICE Agent 876 to use only relay candidates, to avoid leaking location information, 877 but update this configuration to use all candidates once the call is 878 accepted. 880 Regardless of the configuration, the gathering process collects all 881 available candidates, but excluded candidates will not be surfaced in 882 onicecandidate callback or used for connectivity checks. 884 This call may result in a change to the state of the ICE Agent, and 885 may result in a change to media state if it results in connectivity 886 being established. 888 4.1.9. addIceCandidate 890 The addIceCandidate method provides a remote candidate to the ICE 891 Agent, which, if parsed successfully, will be added to the remote 892 description according to the rules defined for Trickle ICE. 893 Connectivity checks will be sent to the new candidate. 895 This call will result in a change to the state of the ICE Agent, and 896 may result in a change to media state if it results in connectivity 897 being established. 899 5. SDP Interaction Procedures 901 This section describes the specific procedures to be followed when 902 creating and parsing SDP objects. 904 5.1. Requirements Overview 906 JSEP implementations must comply with the specifications listed below 907 that govern the creation and processing of offers and answers. 909 The first set of specifications is the "mandatory-to-implement" set. 910 All implementations must support these behaviors, but may not use all 911 of them if the remote side, which may not be a JSEP endpoint, does 912 not support them. 914 The second set of specifications is the "mandatory-to-use" set. The 915 local JSEP endpoint and any remote endpoint must indicate support for 916 these specifications in their session descriptions. 918 5.1.1. Implementation Requirements 920 This list of mandatory-to-implement specifications is derived from 921 the requirements outlined in [I-D.ietf-rtcweb-rtp-usage]. 923 R-1 [RFC4566] is the base SDP specification and MUST be 924 implemented. 926 R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF 927 RTP profile. 929 R-3 [RFC5245] MUST be implemented for signaling the ICE credentials 930 and candidate lines corresponding to each media stream. The ICE 931 implementation MUST be a Full implementation, not a Lite 932 implementation. 934 R-4 [RFC5763] MUST be implemented to signal DTLS certificate 935 fingerprints. 937 R-5 [RFC4568] MUST NOT be implemented to signal SDES SRTP keying 938 information. 940 R-6 The [RFC5888] grouping framework MUST be implemented for 941 signaling grouping information, and MUST be used to identify m= 942 lines via the a=mid attribute. 944 R-7 [I-D.ietf-mmusic-msid] MUST be supported, in order to signal 945 associations between RTP objects and W3C MediaStreams and 946 MediaStreamTracks in a standard way. 948 R-8 The bundle mechanism in 949 [I-D.ietf-mmusic-sdp-bundle-negotiation] MUST be supported to 950 signal the ability to multiplex RTP streams on a single UDP port, 951 in order to avoid excessive use of port number resources. 953 R-9 The SDP attributes of "sendonly", "recvonly", "inactive", and 954 "sendrecv" from [RFC4566] MUST be implemented to signal 955 information about media direction. 957 R-10 [RFC5576] MUST be implemented to signal RTP SSRC values. 959 R-11 [RFC4585] MUST be implemented to signal RTCP based feedback. 961 R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and 962 RTCP. 964 R-13 [RFC5506] MUST be implemented to signal reduced-size RTCP 965 messages. 967 R-14 [RFC3556] with bandwidth modifiers MAY be supported for 968 specifying RTCP bandwidth as a fraction of the media bandwidth, 969 RTCP fraction allocated to the senders and setting maximum media 970 bit-rate boundaries. 972 As required by [RFC4566], Section 5.13, JSEP implementations MUST 973 ignore unknown attribute (a=) lines. 975 5.1.2. Usage Requirements 977 All session descriptions handled by JSEP endpoints, both local and 978 remote, MUST indicate support for the following specifications. If 979 any of these are absent, this omission MUST be treated as an error. 981 R-1 Either the UDP/TLS/RTP/SAVP or the UDP/TLS/RTP/SAVPF RTP 982 profile, as specified in [RFC5764], MUST be used. 984 R-2 ICE, as specified in [RFC5245], MUST be used. Note that the 985 remote endpoint MAY use a Lite implementation. 987 R-3 DTLS-SRTP, as specified in [RFC5763], MUST be used. 989 5.2. Constructing an Offer 991 When createOffer is called, a new SDP description must be created 992 that includes the functionality specified in 993 [I-D.ietf-rtcweb-rtp-usage]. The exact details of this process are 994 explained below. 996 5.2.1. Initial Offers 998 When createOffer is called for the first time, the result is known as 999 the initial offer. 1001 The first step in generating an initial offer is to generate session- 1002 level attributes, as specified in [RFC4566], Section 5. 1003 Specifically: 1005 o The first SDP line MUST be "v=0", as specified in [RFC4566], 1006 Section 5.1 1008 o The second SDP line MUST be an "o=" line, as specified in 1009 [RFC4566], Section 5.2. The value of the field SHOULD 1010 be "-". The value of the field SHOULD be a 1011 cryptographically random number. To ensure uniqueness, this 1012 number SHOULD be at least 64 bits long. The value of the field SHOULD be zero. The value of the 1014 tuple SHOULD be set to a non- 1015 meaningful address, such as IN IP4 0.0.0.0, to prevent leaking the 1016 local address in this field. As mentioned in [RFC4566], the 1017 entire o= line needs to be unique, but selecting a random number 1018 for is sufficient to accomplish this. 1020 o The third SDP line MUST be a "s=" line, as specified in [RFC4566], 1021 Section 5.3; to match the "o=" line, a single dash SHOULD be used 1022 as the session name, e.g. "s=-". 1024 o Session Information ("i="), URI ("u="), Email Address ("e="), 1025 Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and 1026 Time Zones ("z=") lines are not useful in this context and SHOULD 1027 NOT be included. 1029 o Encryption Keys ("k=") lines do not provide sufficient security 1030 and MUST NOT be included. 1032 o A "t=" line MUST be added, as specified in [RFC4566], Section 5.9; 1033 both and SHOULD be set to zero, e.g. "t=0 1034 0". 1036 o An "a=msid-semantic:WMS" line MUST be added, as specified in 1037 [I-D.ietf-mmusic-msid], Section 4. 1039 The next step is to generate m= sections for each MediaStreamTrack 1040 that has been added to the PeerConnection via the addStream method. 1041 (Note that this method takes a MediaStream, which can contain 1042 multiple MediaStreamTracks, and therefore multiple m= sections can be 1043 generated even if addStream is only called once.) When generating m= 1044 sections, the ordering is based on (1) the order in which the 1045 MediaStreams were added to the PeerConnection, and (2) the 1046 alphabetical ordering of the media type for the MediaStreamTrack. 1047 For example, if a MediaStream containing both an audio and a video 1048 MediaStreamTrack is added to a PeerConnection, the resultant m=audio 1049 section will precede the m=video section. 1051 Each m= section, provided it is not being bundled into another m= 1052 section, MUST generate a unique set of ICE credentials and gather its 1053 own unique set of ICE candidates. Otherwise, it MUST use the same 1054 ICE credentials and candidates that were used in the m= section that 1055 it is being bundled into. 1057 For DTLS, all m= sections MUST use the certificate for the identity 1058 that has been specified for the PeerConnection; as a result, they 1059 MUST all have the same [RFC4572]fingerprint value. 1061 Each m= section should be generated as specified in [RFC4566], 1062 Section 5.14. For the m= line itself, the following rules MUST be 1063 followed: 1065 o The port value is set to the port of the default ICE candidate for 1066 this m= section; if this m= section is not being bundled into 1067 another m= section, the port value MUST be unique. If no 1068 candidates have yet been gathered, and a 'null' port value is 1069 being used, as indicated in [I-D.ietf-mmusic-trickle-ice], 1070 Section 5.1., this port MUST still be unique. 1072 o To properly indicate use of DTLS, the field MUST be set to 1073 "UDP/TLS/RTP/SAVPF", as specified in [RFC5764], Section 8. 1075 Each m= section MUST include the following attribute lines: 1077 o An "a=mid" line, as specified in [RFC5888], Section 4. 1079 o An "a=msid" line, as specified in [I-D.ietf-mmusic-msid], 1080 Section 2. 1082 o [OPEN ISSUE: Use of App Token versus stream-correlator ] 1083 o An "a=sendrecv" line, as specified in [RFC3264], Section 5.1. 1085 o For each supported codec, "a=rtpmap" and "a=fmtp" lines, as 1086 specified in [RFC4566], Section 6. For audio, the codecs 1087 specified in [I-D.ietf-rtcweb-audio], Section 3, MUST be be 1088 supported. 1090 o For each primary codec where RTP retransmission should be used, a 1091 corresponding "a=rtpmap" line indicating "rtx" with the clock rate 1092 of the primary codec and an "a=fmtp" line that references the 1093 payload type fo the primary codec, as specified in [RFC4588], 1094 Section 8.1. 1096 o For each supported FEC mechanism, a corresponding "a=rtpmap" line 1097 indicating the desired FEC codec. 1099 o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], 1100 Section 15.4. 1102 o An "a=ice-options" line, with the "trickle" option, as specified 1103 in [I-D.ietf-mmusic-trickle-ice], Section 4. 1105 o For each candidate that has been gathered during the most recent 1106 gathering phase, an "a=candidate" line, as specified in [RFC5245], 1107 Section 4.3., paragraph 3. 1109 o For the current default candidate, a "c=" line, as specific in 1110 [RFC5245], Section 4.3., paragraph 6. If no candidates have been 1111 gathered yet, the default candidate should be set to the 'null' 1112 value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1114 o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the 1115 algorithm used for the fingerprint MUST match that used in the 1116 certificate signature. 1118 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1119 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1120 The role value in the offer MUST be "actpass". 1122 o An "a=rtcp-mux" line, as specified in [RFC5761], Section 5.1.1. 1124 o An "a=rtcp-rsize" line, as specified in [RFC5506], Section 5. 1126 o For each supported RTP header extension, an "a=extmap" line, as 1127 specified in [RFC5285], Section 5. The list of header extensions 1128 that SHOULD/MUST be supported is specified in 1129 [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header extensions 1130 that require encryption MUST be specified as indicated in 1131 [RFC6904], Section 4. 1133 o For each supported RTCP feedback mechanism, an "a=rtcp-fb" 1134 mechanism, as specified in [RFC4585], Section 4.2. The list of 1135 RTCP feedback mechanisms that SHOULD/MUST be supported is 1136 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.1. 1138 o An "a=ssrc" line, as specified in [RFC5576], Section 4.1, 1139 indicating the SSRC to be used for sending media, along with the 1140 mandatory "cname" source attribute, as specified in Section 6.1, 1141 indicating the CNAME for the source. The CNAME must be generated 1142 in accordance with draft-rescorla-random-cname-00. [OPEN ISSUE: 1143 How are CNAMEs specified for MSTs? Are they randomly generated 1144 for each MediaStream? If so, can two MediaStreams be synced?] 1146 o If RTX is supported for this media type, another "a=ssrc" line 1147 with the RTX SSRC, and an "a=ssrc-group" line, as specified in 1148 [RFC5576], section 4.2, with semantics set to "FID" and including 1149 the primary and RTX SSRCs. 1151 o If FEC is supported for this media type, another "a=ssrc" line 1152 with the FEC SSRC, and an "a=ssrc-group" line, as specified in 1153 [RFC5576], section 4.2, with semantics set to "FEC" and including 1154 the primary and FEC SSRCs. 1156 o [OPEN ISSUE: Handling of a=imageattr] 1158 o [TODO: bundle-only] 1160 Lastly, if a data channel has been created, a m= section MUST be 1161 generated for data. The field MUST be set to "application" 1162 and the field MUST be set to "DTLS/SCTP", as specified in 1163 [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set to 1164 the SCTP port number, as specified in Section 4.1. 1166 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- 1167 passwd", "a=ice-options", "a=candidate", "a=fingerprint", and 1168 "a=setup" lines MUST be included as mentioned above, along with an 1169 "a=sctpmap" line referencing the SCTP port number and specifying the 1170 application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. 1171 [OPEN ISSUE: the -00 of this document is missing this information.] 1172 Once all m= sections have been generated, a session-level "a=group" 1173 attribute MUST be added as specified in [RFC5888]. This attribute 1174 MUST have semantics "BUNDLE", and identify the m= sections to be 1175 bundled. [OPEN ISSUE: Need to determine exactly how this decision is 1176 made.] 1178 Attributes that are common between all m= sections MAY be moved to 1179 session-level, if desired. 1181 Attributes other than the ones specified above MAY be included, 1182 except for the following attributes which are specifically 1183 incompatible with the requirements of [I-D.ietf-rtcweb-rtp-usage], 1184 and MUST NOT be included: 1186 o "a=crypto" 1188 o "a=key-mgmt" 1190 o "a=ice-lite" 1192 Note that when BUNDLE is used, any additional attributes that are 1193 added MUST follow the advice in 1194 [I-D.nandakumar-mmusic-sdp-mux-attributes] on how those attributes 1195 interact with BUNDLE. 1197 5.2.2. Subsequent Offers 1199 When createOffer is called a second (or later) time, or is called 1200 after a local description has already been installed, the processing 1201 is somewhat different than for an initial offer. 1203 If the initial offer was not applied using setLocalDescription, 1204 meaning the PeerConnection is still in the "stable" state, the steps 1205 for generating an initial offer should be followed, subject to the 1206 following restriction: 1208 o The fields of the "o=" line MUST stay the same except for the 1209 field, which MUST increment if the session 1210 description changes in any way, including the addition of ICE 1211 candidates. 1213 If the initial offer was applied using setLocalDescription, but an 1214 answer from the remote side has not yet been applied, meaning the 1215 PeerConnection is still in the "local-offer" state, an offer is 1216 generated by following the steps in the "stable" state above, along 1217 with these exceptions: 1219 o The "s=" and "t=" lines MUST stay the same. 1221 o Each "a=mid" line MUST stay the same. 1223 o Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. 1225 o For MediaStreamTracks that are still present, the "a=msid", 1226 "a=ssrc", and "a=ssrc-group" lines MUST stay the same. 1228 o If any MediaStreamTracks have been removed, either through the 1229 removeStream method or by removing them from an added MediaStream, 1230 their m= sections MUST be marked as recvonly by changing the value 1231 of the [RFC3264] directional attribute to "a=recvonly". The 1232 "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST be removed from 1233 the associated m= sections. 1235 If the initial offer was applied using setLocalDescription, and an 1236 answer from the remote side has been applied using 1237 setRemoteDescription, meaning the PeerConnection is in the "remote- 1238 pranswer" or "stable" states, an offer is generated based on the 1239 negotiated session descriptions by following the steps mentioned for 1240 the "local-offer" state above, along with these exceptions: [OPEN 1241 ISSUE: should this be permitted in the remote-pranswer state?] 1243 o If a m= section was rejected, i.e. has had its port set to zero in 1244 either the local or remote description, it MUST remain rejected 1245 and have a zero port in the new offer, as indicated in RFC3264, 1246 Section 5.1. 1248 o If a m= section exists in the current local description, but has 1249 its state set to inactive or recvonly, and a new MediaStreamTrack 1250 is added, the previously existing m= section MUST be recycled 1251 instead of creating a new m= section. [OPEN ISSUE: Nail down 1252 exactly what this means. Should the codecs remain the same? 1253 (No.) Should ICE restart? (No.) Can the "a=mid" attribute be 1254 changed? (Yes?)] 1256 o If a m= section exists in the current local description, but does 1257 not have an associated MediaStreamTrack (i.e. it is inactive or 1258 recvonly), a corresponding m= section MUST be generated in the new 1259 offer, but without "a=msid", "a=ssrc", or "a=ssrc-group" 1260 attributes, and the appropriate directional attribute must be 1261 specified. 1263 In addition, for each previously existing, non-rejected m= section in 1264 the new offer, the following adjustments are made based on the 1265 contents of the corresponding m= section in the current remote 1266 description: 1268 o The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST 1269 only include codecs present in the remote description. 1271 o The RTP header extensions MUST only include those that are present 1272 in the remote description. 1274 o The RTCP feedback extensions MUST only include those that are 1275 present in the remote description. 1277 o The "a=rtcp-mux" line MUST only be added if present in the remote 1278 description. 1280 o The "a=rtcp-rsize" line MUST only be added if present in the 1281 remote description. 1283 5.2.3. Constraints Handling 1285 The createOffer method takes as a parameter a MediaConstraints 1286 object. Special processing is performed when generating a SDP 1287 description if the following constraints are present. 1289 5.2.3.1. OfferToReceiveAudio 1291 If the "OfferToReceiveAudio" constraint is specified, with a value of 1292 "true", the offer MUST include a non-rejected m= section with media 1293 type "audio", even if no audio MediaStreamTrack has been added to the 1294 PeerConnection. This allows the offerer to receive audio even when 1295 not sending it; accordingly, the directional attribute on the audio 1296 m= section MUST be set to recvonly. If this constraint is specified 1297 when an audio MediaStreamTrack has already been added to the 1298 PeerConnection, or a non-rejected m= section with media type "audio" 1299 previously existed, it has no effect. 1301 5.2.3.2. OfferToReceiveVideo 1303 If the "OfferToReceiveAudio" constraint is specified, with a value of 1304 "true", the offer MUST include a m= section with media type "video", 1305 even if no video MediaStreamTrack has been added to the 1306 PeerConnection. This allows the offerer to receive video even when 1307 not sending it; accordingly, the directional attribute on the video 1308 m= section MUST be set to recvonly. If this constraint is specified 1309 when an video MediaStreamTrack has already been added to the 1310 PeerConnection, or a non-rejected m= section with media type "video" 1311 previously existed, it has no effect. 1313 5.2.3.3. VoiceActivityDetection 1314 If the "VoiceActivityDetection" constraint is specified, with a value 1315 of "true", the offer MUST indicate support for silence suppression by 1316 including comfort noise ("CN") codecs for each supported clock rate, 1317 as specified in [RFC3389], Section 5.1. 1319 5.2.3.4. IceRestart 1321 If the "IceRestart" constraint is specified, with a value of "true", 1322 the offer MUST indicate an ICE restart by generating new ICE ufrag 1323 and pwd attributes, as specified in RFC5245, Section 9.1.1.1. If 1324 this constraint is specified on an initial offer, it has no effect 1325 (since a new ICE ufrag and pwd are already generated). 1327 5.3. Generating an Answer 1329 When createAnswer is called, a new SDP description must be created 1330 that is compatible with the supplied remote description as well as 1331 the requirements specified in [I-D.ietf-rtcweb-rtp-usage]. The exact 1332 details of this process are explained below. 1334 5.3.1. Initial Answers 1336 When createAnswer is called for the first time after a remote 1337 description has been provided, the result is known as the initial 1338 answer. If no remote description has been installed, an answer 1339 cannot be generated, and an error MUST be returned. 1341 Note that the remote description SDP may not have been created by a 1342 JSEP endpoint and may not conform to all the requirements listed in 1343 Section 5.2. For many cases, this is not a problem. However, if any 1344 mandatory SDP attributes are missing, or functionality listed as 1345 mandatory-to-use above is not present, this MUST be treated as an 1346 error, and MUST cause the affected m= sections to be marked as 1347 rejected. 1349 The first step in generating an initial answer is to generate 1350 session-level attributes. The process here is identical to that 1351 indicated in the Initial Offers section above. 1353 The next step is to generate m= sections for each m= section that is 1354 present in the remote offer, as specified in [RFC3264], Section 6. 1355 For the purposes of this discussion, any session-level attributes in 1356 the offer that are also valid as media-level attributes SHALL be 1357 considered to be present in each m= section. 1359 If any of the offered m= sections have been rejected, by stopping the 1360 associated remote MediaStreamTrack, the corresponding m= section in 1361 the answer MUST be marked as rejected by setting the port in the m= 1362 line to zero, as indicated in [RFC3264], Section 6., and processing 1363 continues with the next m= section. 1365 For each non-rejected m= section of a given media type, if there is a 1366 local MediaStreamTrack of the specified type which has been added to 1367 the PeerConnection via addStream and not yet associated with a m= 1368 section, the MediaStreamTrack is associated with the m= section at 1369 this time. If there are more m= sections of a certain type than 1370 MediaStreamTracks, some m= sections will not have an associated 1371 MediaStreamTrack. If there are more MediaStreamTracks of a certain 1372 type than m= sections, only the first N MediaStreamTracks will be 1373 able to be associated in the constructed answer. The remainder will 1374 need to be associated in a subsequent offer. 1376 Each m= section should then generated as specified in [RFC3264], 1377 Section 6.1. Because use of DTLS is mandatory, the field 1378 MUST be set to "UDP/TLS/RTP/SAVPF". If the offer supports BUNDLE, 1379 all m= sections to be BUNDLEd must use the same ICE credentials and 1380 candidates; all m= sections not being BUNDLEd must use unique ICE 1381 credentials and candidates. Each m= section MUST include the 1382 following: 1384 o If present in the offer, an "a=mid" line, as specified in 1385 [RFC5888], Section 9.1. The "mid" value MUST match that specified 1386 in the offer. 1388 o If a local MediaStreamTrack has been associated, an "a=msid" line, 1389 as specified in [I-D.ietf-mmusic-msid], Section 2. 1391 o [OPEN ISSUE: Use of App Token versus stream-correlator ] 1393 o If a local MediaStreamTrack has been associated, an "a=sendrecv" 1394 line, as specified in [RFC3264], Section 6.1. If no local 1395 MediaStreamTrack has been associated, an "a=recvonly" line. 1396 [TODO: handle non-sendrecv offered m= sections] 1398 o For each supported codec that is present in the offer, "a=rtpmap" 1399 and "a=fmtp" lines, as specified in [RFC4566], Section 6, and 1400 [RFC3264], Section 6.1. For audio, the codecs specified in 1401 [I-D.ietf-rtcweb-audio], Section 3, MUST be be supported. Note 1402 that for simplicity, the answerer MAY use different payload types 1403 for codecs than the offerer, as it is not prohibited by 1404 Section 6.1. 1406 o If "rtx" is present in the offer, for each primary codec where RTP 1407 retransmission should be used, a corresponding "a=rtpmap" line 1408 indicating "rtx" with the clock rate of the primary codec and an 1409 "a=fmtp" line that references the payload type fo the primary 1410 codec, as specified in [RFC4588], Section 8.1. 1412 o For each supported FEC mechanism that is present in the offer, a 1413 corresponding "a=rtpmap" line indicating the desired FEC codec. 1415 o "a=ice-ufrag" and "a=ice-passwd" lines, as specified in [RFC5245], 1416 Section 15.4. 1418 o If the "trickle" ICE option is present in the offer, an "a=ice- 1419 options" line, with the "trickle" option, as specified in 1420 [I-D.ietf-mmusic-trickle-ice], Section 4. 1422 o For each candidate that has been gathered during the most recent 1423 gathering phase, an "a=candidate" line, as specified in [RFC5245], 1424 Section 4.3., paragraph 3. 1426 o For the current default candidate, a "c=" line, as specific in 1427 [RFC5245], Section 4.3., paragraph 6. If no candidates have been 1428 gathered yet, the default candidate should be set to the 'null' 1429 value defined in [I-D.ietf-mmusic-trickle-ice], Section 5.1. 1431 o An "a=fingerprint" line, as specified in [RFC4572], Section 5; the 1432 algorithm used for the fingerprint MUST match that used in the 1433 certificate signature. 1435 o An "a=setup" line, as specified in [RFC4145], Section 4, and 1436 clarified for use in DTLS-SRTP scenarios in [RFC5763], Section 5. 1437 The role value in the answer MUST be "active" or "passive"; the 1438 "active" role is RECOMMENDED. 1440 o If present in the offer, an "a=rtcp-mux" line, as specified in 1441 [RFC5761], Section 5.1.1. 1443 o If present in the offer, an "a=rtcp-rsize" line, as specified in 1444 [RFC5506], Section 5. 1446 o For each supported RTP header extension that is present in the 1447 offer, an "a=extmap" line, as specified in [RFC5285], Section 5. 1448 The list of header extensions that SHOULD/MUST be supported is 1449 specified in [I-D.ietf-rtcweb-rtp-usage], Section 5.2. Any header 1450 extensions that require encryption MUST be specified as indicated 1451 in [RFC6904], Section 4. 1453 o For each supported RTCP feedback mechanism that is present in the 1454 offer, an "a=rtcp-fb" mechanism, as specified in [RFC4585], 1455 Section 4.2. The list of RTCP feedback mechanisms that SHOULD/ 1456 MUST be supported is specified in [I-D.ietf-rtcweb-rtp-usage], 1457 Section 5.1. 1459 o If a local MediaStreamTrack has been associated, an "a=ssrc" line, 1460 as specified in [RFC5576], Section 4.1, indicating the SSRC to be 1461 used for sending media. 1463 o If a local MediaStreamTrack has been associated, and RTX has been 1464 negotiated for this m= section, another "a=ssrc" line with the RTX 1465 SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], 1466 section 4.2, with semantics set to "FID" and including the primary 1467 and RTX SSRCs. 1469 o If a local MediaStreamTrack has been associated, and FEC has been 1470 negotiated for this m= section, another "a=ssrc" line with the FEC 1471 SSRC, and an "a=ssrc-group" line, as specified in [RFC5576], 1472 section 4.2, with semantics set to "FEC" and including the primary 1473 and FEC SSRCs. 1475 o [OPEN ISSUE: Handling of a=imageattr] 1477 o [TODO: bundle-only] 1479 If a data channel m= section has been offered, a m= section MUST also 1480 be generated for data. The field MUST be set to 1481 "application" and the field MUST be set to "DTLS/SCTP", as 1482 specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value 1483 MUST be set to the SCTP port number, as specified in Section 4.1. 1485 Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice- 1486 passwd", "a=ice-options", "a=candidate", "a=fingerprint", and 1487 "a=setup" lines MUST be included as mentioned above, along with an 1488 "a=sctpmap" line referencing the SCTP port number and specifying the 1489 application protocol indicated in [I-D.ietf-rtcweb-data-protocol]. 1490 [OPEN ISSUE: the -00 of this document is missing this information.] 1492 [TODO: processing of BUNDLE group] 1494 Attributes that are common between all m= sections MAY be moved to 1495 session-level, if desired. 1497 The attributes prohibited in the creation of offers are also 1498 prohibited in the creation of answers. 1500 5.3.2. Subsequent Answers 1502 5.3.3. Constraints Handling 1504 5.4. Parsing an Offer 1506 5.5. Parsing an Answer 1508 5.6. Applying a Local Description 1510 5.7. Applying a Remote Description 1512 6. Configurable SDP Parameters 1514 Note: This section is still very early and is likely to significantly 1515 change as we get a better understanding of a) the use cases for this 1516 b) the implications at the protocol level c) feedback from 1517 implementors on what they can do. 1519 The following elements of the SDP media description MUST NOT be 1520 changed between the createOffer and the setLocalDescription, since 1521 they reflect transport attributes that are solely under browser 1522 control, and the browser MUST NOT honor an attempt to change them: 1524 o The number, type and port number of m-lines. 1526 o The generated ICE credentials (a=ice-ufrag and a=ice-pwd). 1528 o The set of ICE candidates and their parameters (a=candidate). 1530 The following modifications, if done by the browser to a description 1531 between createOffer/createAnswer and the setLocalDescription, MUST be 1532 honored by the browser: 1534 o Remove or reorder codecs (m=) 1536 The following parameters may be controlled by constraints passed into 1537 createOffer/createAnswer. As an open issue, these changes may also 1538 be be performed by manipulating the SDP returned from createOffer/ 1539 createAnswer, as indicated above, as long as the capabilities of the 1540 endpoint are not exceeded (e.g. asking for a resolution greater than 1541 what the endpoint can encode): 1543 o disable BUNDLE (a=group) 1545 o disable RTCP mux (a=rtcp-mux) 1547 o change send resolution or frame rate 1548 o change desired recv resolution or frame rate 1550 o change maximum total bandwidth (b=) [OPEN ISSUE: need to clarify 1551 if this is CT or AS - see section 5.8 of [RFC4566]] 1553 o remove desired AVPF mechanisms (a=rtcp-fb) 1555 o remove RTP header extensions (a=extmap) 1557 o change media send/recv state (a=sendonly/recvonly/inactive) 1559 For example, an application could implement call hold by adding an 1560 a=inactive attribute to its local description, and then applying and 1561 signaling that description. 1563 The application can also modify the SDP to reduce the capabilities in 1564 the offer it sends to the far side in any way the application sees 1565 fit, as long as it is a valid SDP offer and specifies a subset of 1566 what the browser is expecting to do. 1568 As always, the application is solely responsible for what it sends to 1569 the other party, and all incoming SDP will be processed by the 1570 browser to the extent of its capabilities. It is an error to assume 1571 that all SDP is well-formed; however, one should be able to assume 1572 that any implementation of this specification will be able to 1573 process, as a remote offer or answer, unmodified SDP coming from any 1574 other implementation of this specification. 1576 7. Security Considerations 1578 The intent of the WebRTC protocol suite is to provide an environment 1579 that is securable by default: all media is encrypted, keys are 1580 exchanged in a secure fashion, and the Javascript API includes 1581 functions that can be used to verify the identity of communication 1582 partners. 1584 8. IANA Considerations 1586 This document requires no actions from IANA. 1588 9. Acknowledgements 1589 Significant text incorporated in the draft as well and review was 1590 provided by Harald Alvestrand and Suhas Nandakumar. Dan Burnett, 1591 Neil Stratford, Eric Rescorla, Anant Narayanan, Andrew Hutton, 1592 Richard Ejzak, and Adam Bergkvist all provided valuable feedback on 1593 this proposal. Matthew Kaufman provided the observation that keeping 1594 state out of the browser allows a call to continue even if the page 1595 is reloaded. 1597 10. References 1599 10.1. Normative References 1601 [I-D.ietf-mmusic-msid] 1602 Alvestrand, H., "Cross Session Stream Identification in 1603 the Session Description Protocol", draft-ietf-mmusic- 1604 msid-01 (work in progress), August 2013. 1606 [I-D.ietf-mmusic-sctp-sdp] 1607 Loreto, S. and G. Camarillo, "Stream Control Transmission 1608 Protocol (SCTP)-Based Media Transport in the Session 1609 Description Protocol (SDP)", draft-ietf-mmusic-sctp-sdp-04 1610 (work in progress), June 2013. 1612 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1613 Holmberg, C., Alvestrand, H., and C. Jennings, 1614 "Multiplexing Negotiation Using Session Description 1615 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 1616 bundle-negotiation-04 (work in progress), June 2013. 1618 [I-D.ietf-rtcweb-audio] 1619 Valin, J. and C. Bran, "WebRTC Audio Codec and Processing 1620 Requirements", draft-ietf-rtcweb-audio-02 (work in 1621 progress), August 2013. 1623 [I-D.ietf-rtcweb-rtp-usage] 1624 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 1625 Communication (WebRTC): Media Transport and Use of RTP", 1626 draft-ietf-rtcweb-rtp-usage-09 (work in progress), 1627 September 2013. 1629 [I-D.nandakumar-mmusic-sdp-mux-attributes] 1630 Nandakumar, S., "A Framework for SDP Attributes when 1631 Multiplexing", draft-nandakumar-mmusic-sdp-mux- 1632 attributes-03 (work in progress), July 2013. 1634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1635 Requirement Levels", BCP 14, RFC 2119, March 1997. 1637 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1638 A., Peterson, J., Sparks, R., Handley, M., and E. 1639 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1640 June 2002. 1642 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1643 with Session Description Protocol (SDP)", RFC 3264, June 1644 2002. 1646 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 1647 the Session Description Protocol (SDP)", RFC 4145, 1648 September 2005. 1650 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1651 Description Protocol", RFC 4566, July 2006. 1653 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 1654 Transport Layer Security (TLS) Protocol in the Session 1655 Description Protocol (SDP)", RFC 4572, July 2006. 1657 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1658 "Extended RTP Profile for Real-time Transport Control 1659 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1660 2006. 1662 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1663 Real-time Transport Control Protocol (RTCP)-Based Feedback 1664 (RTP/SAVPF)", RFC 5124, February 2008. 1666 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 1667 (ICE): A Protocol for Network Address Translator (NAT) 1668 Traversal for Offer/Answer Protocols", RFC 5245, April 1669 2010. 1671 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1672 Header Extensions", RFC 5285, July 2008. 1674 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1675 Control Packets on a Single Port", RFC 5761, April 2010. 1677 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 1678 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 1680 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 1681 Real-time Transport Protocol (SRTP)", RFC 6904, April 1682 2013. 1684 10.2. Informative References 1686 [I-D.ietf-mmusic-trickle-ice] 1687 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 1688 Incremental Provisioning of Candidates for the Interactive 1689 Connectivity Establishment (ICE) Protocol", draft-ietf- 1690 mmusic-trickle-ice-00 (work in progress), March 2013. 1692 [I-D.ietf-rtcweb-data-protocol] 1693 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 1694 Protocol", draft-ietf-rtcweb-data-protocol-04 (work in 1695 progress), February 2013. 1697 [I-D.jennings-rtcweb-signaling] 1698 Jennings, C., Rosenberg, J., and R. Jesup, "RTCWeb Offer/ 1699 Answer Protocol (ROAP)", draft-jennings-rtcweb- 1700 signaling-01 (work in progress), October 2011. 1702 [I-D.nandakumar-rtcweb-sdp] 1703 Nandakumar, S. and C. Jennings, "SDP for the WebRTC", 1704 draft-nandakumar-rtcweb-sdp-02 (work in progress), July 1705 2013. 1707 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 1708 Comfort Noise (CN)", RFC 3389, September 2002. 1710 [RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth 1711 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 1712 3556, July 2003. 1714 [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing 1715 Tone Generation in the Session Initiation Protocol (SIP)", 1716 RFC 3960, December 2004. 1718 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1719 Description Protocol (SDP) Security Descriptions for Media 1720 Streams", RFC 4568, July 2006. 1722 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1723 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1724 July 2006. 1726 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1727 Real-Time Transport Control Protocol (RTCP): Opportunities 1728 and Consequences", RFC 5506, April 2009. 1730 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1731 Media Attributes in the Session Description Protocol 1732 (SDP)", RFC 5576, June 2009. 1734 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1735 for Establishing a Secure Real-time Transport Protocol 1736 (SRTP) Security Context Using Datagram Transport Layer 1737 Security (DTLS)", RFC 5763, May 2010. 1739 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1740 Security (DTLS) Extension to Establish Keys for the Secure 1741 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 1743 [W3C.WD-webrtc-20111027] 1744 Bergkvist, A., Burnett, D., Narayanan, A., and C. 1745 Jennings, "WebRTC 1.0: Real-time Communication Between 1746 Browsers", World Wide Web Consortium WD WD- 1747 webrtc-20111027, October 2011, 1748 . 1750 Appendix A. JSEP Implementation Examples 1752 A.1. Example API Flows 1754 Below are several sample flows for the new PeerConnection and library 1755 APIs, demonstrating when the various APIs are called in different 1756 situations and with various transport protocols. For clarity and 1757 simplicity, the createOffer/createAnswer calls are assumed to be 1758 synchronous in these examples, whereas the actual APIs are async. 1760 A.1.1. Call using ROAP 1762 This example demonstrates a ROAP call, without the use of trickle 1763 candidates. 1765 // Call is initiated toward Answerer 1766 OffererJS->OffererUA: pc = new PeerConnection(); 1767 OffererJS->OffererUA: pc.addStream(localStream, null); 1768 OffererUA->OffererJS: iceCallback(candidate); 1769 OffererJS->OffererUA: offer = pc.createOffer(null); 1770 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1771 OffererJS->AnswererJS: {"type":"OFFER", "sdp":offer } 1773 // OFFER arrives at Answerer 1774 AnswererJS->AnswererUA: pc = new PeerConnection(); 1775 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", msg.sdp); 1776 AnswererUA->AnswererJS: onaddstream(remoteStream); 1777 AnswererUA->OffererUA: iceCallback(candidate); 1778 // Answerer accepts call 1779 AnswererJS->AnswererUA: pc.addStream(localStream, null); 1780 AnswererJS->AnswererUA: answer = pc.createAnswer(msg.sdp, null); 1781 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1782 AnswererJS->OffererJS: {"type":"ANSWER","sdp":answer } 1784 // ANSWER arrives at Offerer 1785 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1786 OffererUA->OffererJS: onaddstream(remoteStream); 1788 // ICE Completes (at Answerer) 1789 AnswererUA->OffererUA: Media 1791 // ICE Completes (at Offerer) 1792 OffererJS->AnswererJS: {"type":"OK" } 1793 OffererUA->AnswererUA: Media 1795 A.1.2. Call using XMPP 1797 This example demonstrates an XMPP call, making use of trickle 1798 candidates. 1800 // Call is initiated toward Answerer 1801 OffererJS->OffererUA: pc = new PeerConnection(); 1802 OffererJS->OffererUA: pc.addStream(localStream, null); 1803 OffererJS->OffererUA: offer = pc.createOffer(null); 1804 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1805 OffererJS: xmpp = createSessionInitiate(offer); 1806 OffererJS->AnswererJS: 1808 OffererJS->OffererUA: pc.startIce(); 1809 OffererUA->OffererJS: onicecandidate(cand); 1810 OffererJS: createTransportInfo(cand); 1811 OffererJS->AnswererJS: 1813 // session-initiate arrives at Answerer 1814 AnswererJS->AnswererUA: pc = new PeerConnection(); 1815 AnswererJS: offer = parseSessionInitiate(xmpp); 1816 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer); 1817 AnswererUA->AnswererJS: onaddstream(remoteStream); 1819 // transport-infos arrive at Answerer 1820 AnswererJS->AnswererUA: candidate = parseTransportInfo(xmpp); 1821 AnswererJS->AnswererUA: pc.addIceCandidate(candidate); 1822 AnswererUA->AnswererJS: onicecandidate(cand) 1823 AnswererJS: createTransportInfo(cand); 1824 AnswererJS->OffererJS: 1825 // transport-infos arrive at Offerer 1826 OffererJS->OffererUA: candidates = parseTransportInfo(xmpp); 1827 OffererJS->OffererUA: pc.addIceCandidate(candidates); 1829 // Answerer accepts call 1830 AnswererJS->AnswererUA: pc.addStream(localStream, null); 1831 AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null); 1832 AnswererJS: xmpp = createSessionAccept(answer); 1833 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1834 AnswererJS->OffererJS: 1836 // session-accept arrives at Offerer 1837 OffererJS: answer = parseSessionAccept(xmpp); 1838 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1839 OffererUA->OffererJS: onaddstream(remoteStream); 1841 // ICE Completes (at Answerer) 1842 AnswererUA->OffererUA: Media 1844 // ICE Completes (at Offerer) 1845 OffererUA->AnswererUA: Media 1847 A.1.3. Adding video to a call, using XMPP 1849 This example demonstrates an XMPP call, where the XMPP content-add 1850 mechanism is used to add video media to an existing session. For 1851 simplicity, candidate exchange is not shown. 1853 Note that the offerer for the change to the session may be different 1854 than the original call offerer. 1856 // Offerer adds video stream 1857 OffererJS->OffererUA: pc.addStream(videoStream) 1858 OffererJS->OffererUA: offer = pc.createOffer(null); 1859 OffererJS: xmpp = createContentAdd(offer); 1860 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1861 OffererJS->AnswererJS: 1863 // content-add arrives at Answerer 1864 AnswererJS: offer = parseContentAdd(xmpp); 1865 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer); 1866 AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null); 1867 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1868 AnswererJS: xmpp = createContentAccept(answer); 1869 AnswererJS->OffererJS: 1871 // content-accept arrives at Offerer 1872 OffererJS: answer = parseContentAccept(xmpp); 1873 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1875 A.1.4. Simultaneous add of video streams, using XMPP 1877 This example demonstrates an XMPP call, where new video sources are 1878 added at the same time to a call that already has video; since adding 1879 these sources only affects one side of the call, there is no 1880 conflict. The XMPP description-info mechanism is used to indicate 1881 the new sources to the remote side. 1883 // Offerer and "Answerer" add video streams at the same time 1884 OffererJS->OffererUA: pc.addStream(offererVideoStream2) 1885 OffererJS->OffererUA: offer = pc.createOffer(null); 1886 OffererJS: xmpp = createDescriptionInfo(offer); 1887 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1888 OffererJS->AnswererJS: 1890 AnswererJS->AnswererUA: pc.addStream(answererVideoStream2) 1891 AnswererJS->AnswererUA: offer = pc.createOffer(null); 1892 AnswererJS: xmpp = createDescriptionInfo(offer); 1893 AnswererJS->AnswererUA: pc.setLocalDescription("offer", offer); 1894 AnswererJS->OffererJS: 1896 // description-info arrives at "Answerer", and is acked 1897 AnswererJS: offer = parseDescriptionInfo(xmpp); 1898 AnswererJS->OffererJS: // ack 1900 // description-info arrives at Offerer, and is acked 1901 OffererJS: offer = parseDescriptionInfo(xmpp); 1902 OffererJS->AnswererJS: // ack 1904 // ack arrives at Offerer; remote offer is used as an answer 1905 OffererJS->OffererUA: pc.setRemoteDescription("answer", offer); 1907 // ack arrives at "Answerer"; remote offer is used as an answer 1908 AnswererJS->AnswererUA: pc.setRemoteDescription("answer", offer); 1910 A.1.5. Call using SIP 1912 This example demonstrates a simple SIP call (e.g. where the client 1913 talks to a SIP proxy over WebSockets). 1915 // Call is initiated toward Answerer 1916 OffererJS->OffererUA: pc = new PeerConnection(); 1917 OffererJS->OffererUA: pc.addStream(localStream, null); 1918 OffererUA->OffererJS: onicecandidate(candidate); 1919 OffererJS->OffererUA: offer = pc.createOffer(null); 1920 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1921 OffererJS: sip = createInvite(offer); 1922 OffererJS->AnswererJS: SIP INVITE w/ SDP 1924 // INVITE arrives at Answerer 1925 AnswererJS->AnswererUA: pc = new PeerConnection(); 1926 AnswererJS: offer = parseInvite(sip); 1927 AnswererJS->AnswererUA: pc.setRemoteDescription("offer", offer); 1928 AnswererUA->AnswererJS: onaddstream(remoteStream); 1929 AnswererUA->OffererUA: onicecandidate(candidate); 1931 // Answerer accepts call 1932 AnswererJS->AnswererUA: pc.addStream(localStream, null); 1933 AnswererJS->AnswererUA: answer = pc.createAnswer(offer, null); 1934 AnswererJS: sip = createResponse(200, answer); 1935 AnswererJS->AnswererUA: pc.setLocalDescription("answer", answer); 1936 AnswererJS->OffererJS: 200 OK w/ SDP 1938 // 200 OK arrives at Offerer 1939 OffererJS: answer = parseResponse(sip); 1940 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1941 OffererUA->OffererJS: onaddstream(remoteStream); 1942 OffererJS->AnswererJS: ACK 1944 // ICE Completes (at Answerer) 1945 AnswererUA->OffererUA: Media 1947 // ICE Completes (at Offerer) 1948 OffererUA->AnswererUA: Media 1950 A.1.6. Handling early media (e.g. 1-800-GO FEDEX), using SIP 1952 This example demonstrates how early media could be handled; for 1953 simplicity, only the offerer side of the call is shown. 1955 // Call is initiated toward Answerer 1956 OffererJS->OffererUA: pc = new PeerConnection(); 1957 OffererJS->OffererUA: pc.addStream(localStream, null); 1958 OffererUA->OffererJS: onicecandidate(candidate); 1959 OffererJS->OffererUA: offer = pc.createOffer(null); 1960 OffererJS->OffererUA: pc.setLocalDescription("offer", offer); 1961 OffererJS: sip = createInvite(offer); 1962 OffererJS->AnswererJS: SIP INVITE w/ SDP 1964 // 180 Ringing is received by offerer, w/ SDP 1965 OffererJS: answer = parseResponse(sip); 1966 OffererJS->OffererUA: pc.setRemoteDescription("pranswer", answer); 1967 OffererUA->OffererJS: onaddstream(remoteStream); 1969 // ICE Completes (at Offerer) 1970 OffererUA->AnswererUA: Media 1972 // 200 OK arrives at Offerer 1973 OffererJS: answer = parseResponse(sip); 1974 OffererJS->OffererUA: pc.setRemoteDescription("answer", answer); 1975 OffererJS->AnswererJS: ACK 1977 A.2. Example Session Descriptions 1979 A.2.1. createOffer 1981 This SDP shows a typical initial offer, created by createOffer for a 1982 PeerConnection with a single audio MediaStreamTrack, a single video 1983 MediaStreamTrack, and a single data channel. Host candidates have 1984 also already been gathered. Note some lines have been broken into 1985 two lines for formatting reasons. 1987 v=0 1988 o=- 4962303333179871722 1 IN IP4 0.0.0.0 1989 s=- 1990 t=0 0 1991 a=msid-semantic:WMS 1992 a=group:BUNDLE audio video data 1993 m=audio 56500 UDP/TLS/RTP/SAVPF 111 0 8 126 1994 c=IN IP4 192.0.2.1 1995 a=rtcp:56501 IN IP4 192.0.2.1 1996 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56500 1997 typ host generation 0 1998 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56501 1999 typ host generation 0 2000 a=ice-ufrag:ETEn1v9DoTMB9J4r 2001 a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl 2002 a=ice-options:trickle 2003 a=mid:audio 2004 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2005 a=sendrecv 2006 a=rtcp-mux 2007 a=rtcp-rsize 2008 a=fingerprint:sha-256 2009 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2010 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2011 a=setup:actpass 2012 a=rtpmap:111 opus/48000/2 2013 a=fmtp:111 minptime=10 2014 a=rtpmap:0 PCMU/8000 2015 a=rtpmap:8 PCMA/8000 2016 a=rtpmap:126 telephone-event/8000 2017 a=maxptime:60 2018 a=ssrc:1732846380 cname:EocUG1f0fcg/yvY7 2019 a=msid:47017fee-b6c1-4162-929c-a25110252400 2020 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 2021 m=video 56502 UDP/TLS/RTP/SAVPF 100 115 116 117 2022 c=IN IP4 192.0.2.1 2023 a=rtcp:56503 IN IP4 192.0.2.1 2024 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56502 2025 typ host generation 0 2026 a=candidate:3348148302 2 udp 2113937151 192.0.2.1 56503 2027 typ host generation 0 2028 a=ice-ufrag:BGKkWnG5GmiUpdIV 2029 a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf 2030 a=ice-options:trickle 2031 a=mid:video 2032 a=extmap:2 urn:ietf:params:rtp-hdrext:toffset 2033 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 2034 a=sendrecv 2035 a=rtcp-mux 2036 a=rtcp-rsize 2037 a=fingerprint:sha-256 2038 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2039 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2040 a=setup:actpass 2041 a=rtpmap:100 VP8/90000 2042 a=rtcp-fb:100 ccm fir 2043 a=rtcp-fb:100 nack 2044 a=rtcp-fb:100 goog-remb 2045 a=rtpmap:115 rtx/90000 2046 a=fmtp:115 apt=100 2047 a=rtpmap:116 red/90000 2048 a=rtpmap:117 ulpfec/90000 2049 a=ssrc:1366781083 cname:EocUG1f0fcg/yvY7 2050 a=ssrc:1366781084 cname:EocUG1f0fcg/yvY7 2051 a=ssrc:1366781085 cname:EocUG1f0fcg/yvY7 2052 a=ssrc-group:FID 1366781083 1366781084 2053 a=ssrc-group:FEC 1366781083 1366781085 2054 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 2055 f30bdb4a-5db8-49b5-bcdc-e0c9a23172e0 2056 m=application 56504 DTLS/SCTP 5000 2057 c=IN IP4 192.0.2.1 2058 a=candidate:3348148302 1 udp 2113937151 192.0.2.1 56504 2059 typ host generation 0 2061 a=ice-ufrag:VD5v2BnbZm3mgP3d 2062 a=ice-pwd:+Jlkuox+VVIUDqxcfIDuTZMH 2063 a=ice-options:trickle 2064 a=mid:data 2065 a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 2066 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 2067 a=setup:actpass 2068 a=sctpmap:5000 webrtc-datachannel 16 2070 A.2.2. createAnswer 2072 This SDP shows a typical initial answer to the above offer, created 2073 by createAnswer for a PeerConnection with a single audio 2074 MediaStreamTrack, a single video MediaStreamTrack, and a single data 2075 channel. Host candidates have also already been gathered. Note some 2076 lines have been broken into two lines for formatting reasons. 2078 v=0 2079 o=- 6729291447651054566 1 IN IP4 0.0.0.0 2080 s=- 2081 t=0 0 2082 a=msid-semantic:WMS 2083 a=group:BUNDLE audio video data 2084 m=audio 20000 UDP/TLS/RTP/SAVPF 111 0 8 126 2085 c=IN IP4 192.0.2.2 2086 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2087 typ host generation 0 2088 a=ice-ufrag:6sFvz2gdLkEwjZEr 2089 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2090 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2091 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2092 a=setup:active 2093 a=mid:audio 2094 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 2095 a=sendrecv 2096 a=rtcp-mux 2097 a=rtpmap:111 opus/48000/2 2098 a=fmtp:111 minptime=10 2099 a=rtpmap:0 PCMU/8000 2100 a=rtpmap:8 PCMA/8000 2101 a=rtpmap:126 telephone-event/8000 2102 a=maxptime:60 2103 a=ssrc:3429951804 cname:Q/NWs1ao1HmN4Xa5 2104 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2105 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1a0 2106 m=video 20000 UDP/TLS/RTP/SAVPF 100 115 116 117 2107 c=IN IP4 192.0.2.2 2108 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2109 typ host generation 0 2110 a=ice-ufrag:6sFvz2gdLkEwjZEr 2111 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2112 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2113 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2114 a=setup:active 2115 a=mid:video 2116 a=extmap:2 urn:ietf:params:rtp-hdrext:toffset 2117 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 2118 a=sendrecv 2119 a=rtcp-mux 2120 a=rtpmap:100 VP8/90000 2121 a=rtcp-fb:100 ccm fir 2122 a=rtcp-fb:100 nack 2123 a=rtcp-fb:100 goog-remb 2124 a=rtpmap:115 rtx/90000 2125 a=fmtp:115 apt=100 2126 a=rtpmap:116 red/90000 2127 a=rtpmap:117 ulpfec/90000 2128 a=ssrc:3229706345 cname:Q/NWs1ao1HmN4Xa5 2129 a=ssrc:3229706346 cname:Q/NWs1ao1HmN4Xa5 2130 a=ssrc:3229706347 cname:Q/NWs1ao1HmN4Xa5 2131 a=ssrc-group:FID 3229706345 3229706346 2132 a=ssrc-group:FEC 3229706345 3229706347 2133 a=msid:PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1 2134 PI39StLS8W7ZbQl1sJsWUXkr3Zf12fJUvzQ1v0 2135 m=application 20000 DTLS/SCTP 5000 2136 c=IN IP4 192.0.2.2 2137 a=candidate:2299743422 1 udp 2113937151 192.0.2.2 20000 2138 typ host generation 0 2139 a=ice-ufrag:6sFvz2gdLkEwjZEr 2140 a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2 2141 a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35 2142 :DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08 2143 a=setup:active 2144 a=mid:data 2145 a=sctpmap:5000 webrtc-datachannel 16 2147 A.2.3. Call Flows 2149 Example SDP for WebRTC call flows can be found in 2150 [I-D.nandakumar-rtcweb-sdp]. [TODO: should these call flows be 2151 merged into this section?] 2153 Appendix B. Change log 2154 Changes in draft-05: 2156 o Fixed several issues identified in the createOffer/Answer sections 2157 during document review. 2159 o Updated references. 2161 Changes in draft-04: 2163 o Filled in sections on createOffer and createAnswer. 2165 o Added SDP examples. 2167 o Fixed references. 2169 Changes in draft-03: 2171 o Added text describing relationship to W3C specification 2173 Changes in draft-02: 2175 o Converted from nroff 2177 o Removed comparisons to old approaches abandoned by the working 2178 group 2180 o Removed stuff that has moved to W3C specification 2182 o Align SDP handling with W3C draft 2184 o Clarified section on forking. 2186 Changes in draft-01: 2188 o Added diagrams for architecture and state machine. 2190 o Added sections on forking and rehydration. 2192 o Clarified meaning of "pranswer" and "answer". 2194 o Reworked how ICE restarts and media directions are controlled. 2196 o Added list of parameters that can be changed in a description. 2198 o Updated suggested API and examples to match latest thinking. 2200 o Suggested API and examples have been moved to an appendix. 2202 Changes in draft -00: 2204 o Migrated from draft-uberti-rtcweb-jsep-02. 2206 Authors' Addresses 2208 Justin Uberti 2209 Google 2210 747 6th Ave S 2211 Kirkland, WA 98033 2212 USA 2214 Email: justin@uberti.name 2216 Cullen Jennings 2217 Cisco 2218 170 West Tasman Drive 2219 San Jose, CA 95134 2220 USA 2222 Email: fluffy@iii.ca