forked from fluffy/webrtc-w3c
/
webrtc-20120530.html
3132 lines (2577 loc) · 196 KB
/
webrtc-20120530.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
<head>
<link type="text/css" rel="stylesheet" href="./webrtc.css" />
<title>WebRTC 1.0: Real-time Communication Between
Browsers</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline.
To tag a new releas in git hub
Once the version is checked in and ready to go, you tag it with (need
to chance the 20110823 to correct date )
git tag -a v20120323 -m "This is release 20120323"
Tags are not transferred by default with the push so you have to
add a - -tags parameter to the push so it looks like. Note you need to
remoce the space between the - and -tag to make a double dash.
git push - -tags
or alternatively you can push just the new tag with
git push origin v20120323
To generate the dated version of the specification:
Open this doc in Mozilla.
Do a CTRL-ALT-SHIFT-S
Select "XHMTL( source)" from dialog box. This will pop a new tab with
generated version of the document.
This will open a new tab with generated html. Copy and paste this to
a new file. Note if you use Chrome or Safari, this step will not
work. What will happen is the paste will have the original document,
not what was displayed in the window that you did the copy on.
Rename the new file to the correct day such as
webrtc-broken-20111003.html then search for and edit the links for
"This version" and "Previos version". Add the new file into CVS and
check in.
Once everyone is happy, the webrtc-broken.html and
webrtc-broken-20111003.html files can be copied to
webrtc.html and webrtc-20111003.html
respectively in the ../editor/. directory.
-->
<link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8" /></head>
<body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p><h1 id="title" class="title">WebRTC 1.0: Real-time Communication Between Browsers</h1><h2 id="w3c-editor-s-draft-30-may-2012"><acronym title="World Wide Web Consortium">W3C</acronym> Editor's Draft 30 May 2012</h2><dl><dt>This version:</dt><dd><a href="http://dev.w3.org/2011/webrtc/editor/webrtc.html-20120530">http://dev.w3.org/2011/webrtc/editor/webrtc-20120530.html</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/webrtc/">http://www.w3.org/TR/webrtc/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2011/webrtc/editor/webrtc.html">http://dev.w3.org/2011/webrtc/editor/webrtc.html</a></dd><dt>Previous version:</dt><dd><a href="http://dev.w3.org/2011/webrtc/editor/webrtc-20120528.html">http://dev.w3.org/2011/webrtc/editor/webrtc-20120528.html</a></dd><dt>Editors:</dt><dd><span>Adam Bergkvist</span>, Ericsson</dd>
<dd><span>Daniel C. Burnett</span>, Voxeo</dd>
<dd><span>Cullen Jennings</span>, Cisco</dd>
<dd><span>Anant Narayanan</span>, Mozilla</dd>
</dl><p class="copyright">Initial Author of this Specification was Ian Hickson, Google Inc., with the following copyright statement:<br /> © Copyright 2004-2011 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA. You are granted a license to use, reproduce and create derivative works of this document.</p> <p class="copyright">All subsequent changes since 26 July 2011 done by the <acronym title="World Wide Web Consortium">W3C</acronym> WebRTC Working Group are under the following <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>:<br />© 2011-2012 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <a href="http://www.w3.org/Consortium/Legal/copyright-documents">Document use</a> rules apply.</p> <p class="copyright">For the entire publication on the <acronym title="World Wide Web Consortium">W3C</acronym> site the <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a> and <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> rules apply.</p><hr /></div>
<div id="abstract" class="introductory section"><h2>Abstract</h2>
<p>This document defines a set of APIs to represent streaming media,
including audio and video, in JavaScript, to allow media to be sent over
the network to another browser or device implementing the appropriate
set of real-time protocols, and media received from another browser or
device to be processed and displayed locally. This specification is
being developed in conjunction with a protocol specification developed
by the IETF RTCWEB group and an API specification to get access to local
media devices developed by the Media Capture Task Force.</p>
</div><div class="introductory section" id="sotd"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
<p>This document is not complete. It is subject to major changes and,
while early experimentation is encouraged, it is therefore not
intended for implementation. The API is based on preliminary work done
in the WHATWG. The Web Real-Time Communications Working Group expects
this specification to evolve significantly based on:</p>
<ul>
<li>The outcome of ongoing exchanges in the companion RTCWEB group at
IETF to define the set of protocols that, together with this document,
will enable real-time communications in Web browsers.</li>
<li>Privacy issues that arise when exposing local capabilities and
local streams.</li>
<li>Technical discussions within the group, on the data channel in
particular.</li>
<li>Experience gained through early experimentations.</li>
<li>Feedback received from other groups and individuals.</li>
</ul>
<p>This document was published by the <a href="http://www.w3.org/2011/04/webrtc/">Web Real-Time Communications Working Group</a> as an Editor's Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-webrtc@w3.org">public-webrtc@w3.org</a> (<a href="mailto:public-webrtc-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-webrtc/">archives</a>). All feedback is welcome.</p><p>Publication as an Editor's Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/47318/status">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">1. </span>Conformance</a></li><li class="tocline"><a href="#intro" class="tocxref"><span class="secno">2. </span>Introduction</a></li><li class="tocline"><a href="#network-stream-api" class="tocxref"><span class="secno">3. </span>Network Stream API</a><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">3.1 </span>Introduction</a></li><li class="tocline"><a href="#interface-definitions" class="tocxref"><span class="secno">3.2 </span>Interface definitions</a><ul class="toc"><li class="tocline"><a href="#mediastream" class="tocxref"><span class="secno">3.2.1 </span>MediaStream</a><ul class="toc"><li class="tocline"><a href="#label" class="tocxref"><span class="secno">3.2.1.1 </span>label</a></li><li class="tocline"><a href="#events-on-mediastream" class="tocxref"><span class="secno">3.2.1.2 </span>Events on MediaStream</a></li></ul></li><li class="tocline"><a href="#mediastreamtrack" class="tocxref"><span class="secno">3.2.2 </span>MediaStreamTrack</a></li></ul></li><li class="tocline"><a href="#audiomediastreamtrack" class="tocxref"><span class="secno">3.3 </span>AudioMediaStreamTrack</a><ul class="toc"><li class="tocline"><a href="#attributes" class="tocxref"><span class="secno">3.3.1 </span>Attributes</a></li><li class="tocline"><a href="#methods" class="tocxref"><span class="secno">3.3.2 </span>Methods</a></li></ul></li></ul></li><li class="tocline"><a href="#peer-to-peer-connections" class="tocxref"><span class="secno">4. </span>Peer-to-peer connections</a><ul class="toc"><li class="tocline"><a href="#peerconnection" class="tocxref"><span class="secno">4.1 </span>PeerConnection</a><ul class="toc"><li class="tocline"><a href="#sdptype" class="tocxref"><span class="secno">4.1.1 </span>SdpType</a></li><li class="tocline"><a href="#sessiondescription-class" class="tocxref"><span class="secno">4.1.2 </span> SessionDescription Class </a><ul class="toc"><li class="tocline"><a href="#attributes-1" class="tocxref"><span class="secno">4.1.2.1 </span>Attributes</a></li><li class="tocline"><a href="#methods-1" class="tocxref"><span class="secno">4.1.2.2 </span>Methods</a></li></ul></li><li class="tocline"><a href="#sessiondescriptioncallback" class="tocxref"><span class="secno">4.1.3 </span> SessionDescriptionCallback </a></li><li class="tocline"><a href="#peerconnectionerrorcallback" class="tocxref"><span class="secno">4.1.4 </span> PeerConnectionErrorCallback </a></li><li class="tocline"><a href="#peerstate-enum" class="tocxref"><span class="secno">4.1.5 </span> PeerState Enum </a></li><li class="tocline"><a href="#icestate-enum" class="tocxref"><span class="secno">4.1.6 </span> IceState Enum </a></li><li class="tocline"><a href="#icecandidate-type" class="tocxref"><span class="secno">4.1.7 </span> IceCandidate Type </a><ul class="toc"><li class="tocline"><a href="#attributes-2" class="tocxref"><span class="secno">4.1.7.1 </span>Attributes</a></li><li class="tocline"><a href="#methods-2" class="tocxref"><span class="secno">4.1.7.2 </span>Methods</a></li></ul></li><li class="tocline"><a href="#icecandidatecallback" class="tocxref"><span class="secno">4.1.8 </span> IceCandidateCallback </a></li><li class="tocline"><a href="#iceservers-type---option-1" class="tocxref"><span class="secno">4.1.9 </span> IceServers Type - Option 1</a><ul class="toc"><li class="tocline"><a href="#attributes-3" class="tocxref"><span class="secno">4.1.9.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#iceservers-type---option-2" class="tocxref"><span class="secno">4.1.10 </span> IceServers Type - Option 2</a><ul class="toc"><li class="tocline"><a href="#attributes-4" class="tocxref"><span class="secno">4.1.10.1 </span>Attributes</a></li></ul></li><li class="tocline"><a href="#peerconnection-interface" class="tocxref"><span class="secno">4.1.11 </span>PeerConnection Interface</a><ul class="toc"><li class="tocline"><a href="#attributes-5" class="tocxref"><span class="secno">4.1.11.1 </span>Attributes</a></li><li class="tocline"><a href="#methods-3" class="tocxref"><span class="secno">4.1.11.2 </span>Methods</a></li></ul></li></ul></li></ul></li><li class="tocline"><a href="#iana-registrations" class="tocxref"><span class="secno">5. </span>IANA Registrations</a><ul class="toc"><li class="tocline"><a href="#constraints" class="tocxref"><span class="secno">5.1 </span>Constraints</a></li></ul></li><li class="tocline"><a href="#simple-example" class="tocxref"><span class="secno">6. </span>Simple Example</a></li><li class="tocline"><a href="#advanced-example" class="tocxref"><span class="secno">7. </span>Advanced Example</a></li><li class="tocline"><a href="#peer-to-peer-data-api" class="tocxref"><span class="secno">8. </span>Peer-to-peer Data API</a><ul class="toc"><li class="tocline"><a href="#datachannel" class="tocxref"><span class="secno">8.1 </span>DataChannel</a><ul class="toc"><li class="tocline"><a href="#attributes-6" class="tocxref"><span class="secno">8.1.1 </span>Attributes</a></li><li class="tocline"><a href="#methods-4" class="tocxref"><span class="secno">8.1.2 </span>Methods</a></li><li class="tocline"><a href="#constants" class="tocxref"><span class="secno">8.1.3 </span>Constants</a></li><li class="tocline"><a href="#dictionary-datachannelinit-members" class="tocxref"><span class="secno">8.1.4 </span>Dictionary <span class="idlType formerLink idlType"><code>DataChannelInit</code></span> Members</a></li></ul></li><li class="tocline"><a href="#examples" class="tocxref"><span class="secno">8.2 </span>Examples</a></li></ul></li><li class="tocline"><a href="#garbage-collection" class="tocxref"><span class="secno">9. </span>Garbage collection</a></li><li class="tocline"><a href="#event-definitions" class="tocxref"><span class="secno">10. </span>Event definitions</a><ul class="toc"><li class="tocline"><a href="#peerconnectionevent" class="tocxref"><span class="secno">10.1 </span>PeerConnectionEvent</a><ul class="toc"><li class="tocline"><a href="#attributes-7" class="tocxref"><span class="secno">10.1.1 </span>Attributes</a></li><li class="tocline"><a href="#dictionary-peerconnectioneventinit-members" class="tocxref"><span class="secno">10.1.2 </span>Dictionary <span class="idlType formerLink idlType"><code>PeerConnectionEventInit</code></span> Members</a></li></ul></li><li class="tocline"><a href="#peerconnectioniceevent" class="tocxref"><span class="secno">10.2 </span>PeerConnectionIceEvent</a><ul class="toc"><li class="tocline"><a href="#attributes-8" class="tocxref"><span class="secno">10.2.1 </span>Attributes</a></li><li class="tocline"><a href="#dictionary-peerconnectioneventiceinit-members" class="tocxref"><span class="secno">10.2.2 </span>Dictionary <span class="idlType formerLink idlType"><code>PeerConnectionEventIceInit</code></span> Members</a></li></ul></li><li class="tocline"><a href="#mediastreamtrackevent" class="tocxref"><span class="secno">10.3 </span>MediaStreamTrackEvent</a><ul class="toc"><li class="tocline"><a href="#attributes-9" class="tocxref"><span class="secno">10.3.1 </span>Attributes</a></li><li class="tocline"><a href="#dictionary-mediastreamtrackeventinit-members" class="tocxref"><span class="secno">10.3.2 </span>Dictionary <span class="idlType formerLink idlType"><code>MediaStreamTrackEventInit</code></span> Members</a></li></ul></li><li class="tocline"><a href="#mediastreamevent" class="tocxref"><span class="secno">10.4 </span>MediaStreamEvent</a><ul class="toc"><li class="tocline"><a href="#attributes-10" class="tocxref"><span class="secno">10.4.1 </span>Attributes</a></li><li class="tocline"><a href="#dictionary-mediastreameventinit-members" class="tocxref"><span class="secno">10.4.2 </span>Dictionary <span class="idlType formerLink idlType"><code>MediaStreamEventInit</code></span> Members</a></li></ul></li><li class="tocline"><a href="#datachannelevent" class="tocxref"><span class="secno">10.5 </span>DataChannelEvent</a><ul class="toc"><li class="tocline"><a href="#attributes-11" class="tocxref"><span class="secno">10.5.1 </span>Attributes</a></li><li class="tocline"><a href="#dictionary-datachanneleventinit-members" class="tocxref"><span class="secno">10.5.2 </span>Dictionary <span class="idlType formerLink idlType"><code>DataChannelEventInit</code></span> Members</a></li></ul></li></ul></li><li class="tocline"><a href="#event-summary" class="tocxref"><span class="secno">11. </span>Event summary</a></li><li class="tocline"><a href="#change-log" class="tocxref"><span class="secno">12. </span>Change Log</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div>
<div id="conformance" class="section">
<!-- OddPage -->
<h2><span class="secno">1. </span>Conformance</h2><p>As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.</p>
<p>The key words <em class="rfc2119" title="must">must</em>, <em class="rfc2119" title="must not">must not</em>, <em class="rfc2119" title="required">required</em>, <em class="rfc2119" title="should">should</em>, <em class="rfc2119" title="should not">should not</em>, <em class="rfc2119" title="recommended">recommended</em>, <em class="rfc2119" title="may">may</em>, and <em class="rfc2119" title="optional">optional</em> in this specification are to be interpreted as described in [<cite><a class="bibref" rel="biblioentry" href="#bib-RFC2119">RFC2119</a></cite>].</p>
<p> Implementations that use ECMAScript to implement the APIs defined in
this specification must implement them in a manner consistent with the
ECMAScript Bindings defined in the Web IDL specification [<cite><a class="bibref" rel="biblioentry" href="#bib-WEBIDL">WEBIDL</a></cite>], as
this specification uses that specification and terminology. </p>
</div>
<div id="intro" class="informative section">
<!-- OddPage -->
<h2><span class="secno">2. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
<p>There are a number of facets to video-conferencing in HTML covered by
this specification:</p>
<ul>
<li>Representing a multimedia stream (video, audio, or both) from
local devices (video cameras, microphones, Web cams) or from
prerecorded files provided by the user.</li>
<li>Connecting to remote peers using NAT-traversal technologies such
as ICE, STUN, and TURN.</li>
<li>Sending the locally-produced streams to remote peers and receiving
streams from remote peers.</li>
<li>Sending arbitrary data directly to remote peers.</li>
</ul>
<p>This document defines the APIs used for these features. This
specification is being developed in conjunction with a protocol
specification developed by the <a href="http://datatracker.ietf.org/wg/rtcweb/">IETF RTCWEB group</a> and
an API specification to get access to local media devices developed by
the <a href="http://www.w3.org/2011/04/webrtc/">Media Capture Task
Force</a>.</p>
</div>
<div id="network-stream-api" class="section">
<!-- OddPage -->
<h2><span class="secno">3. </span>Network Stream API</h2>
<div id="introduction" class="section">
<h3><span class="secno">3.1 </span>Introduction</h3>
<p>The <code>MediaStream</code> interface, as defined in the
[<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] specification, typically represents a stream of data
of audio and/or video. A <code>MediaStream</code> may be extended to represent a
stream that either comes from or is sent to a remote node (and not
just the local camera, for instance). The extensions required to
enable this capability on the <code>MediaStream</code> object will be
described in this document.</p>
<p>A <code>MediaStream</code> as defined in [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] may
contain zero or more <code>MediaStreamTrack</code> objects. A
<code>MediaStreamTrack</code> sent to another peer will appear as one
and only one <code>MediaStreamTrack</code> to the recipient.</p>
<p>Channels are the smallest unit considered in the
<code>MediaStream</code> specification. Channels are intended to be
encoded together for transmission as, for instance, an RTP payload
type. All of the channels that a codec needs to encode jointly <em class="rfc2119" title="must">must</em> be
in the same <code>MediaStreamTrack</code> and the codecs <em class="rfc2119" title="should">should</em> be
able to encode, or discard, all the channels in the track.</p>
<p>The concepts of an input and output to a given
<code>MediaStream</code> apply in the case of <code>MediaStream</code>
objects transmitted over the network as well. A <code>
<a>MediaStream</a>
</code> created by a <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object (later described in this document) will take as input
the data received from a remote peer. Similarly, a
<code>MediaStream</code> from a local source, for instance a camera
via [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] will have an output that represents what is
transmitted to a remote peer if the object is used with a <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object.</p>
<p>The concept of duplicating <code>MediaStream</code> objects as
described in [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] is also applicable here. This feature
can be used, for instance, in a video-conferencing scenario to display
the local video from the user’s camera and microphone in a local
monitor, while only transmitting the audio to the remote peer (e.g. in
response to the user using a "video mute" feature). Combining tracks
from different <code>
<a>MediaStream</a>
</code> objects into a new <code>
<a>MediaStream</a>
</code> is useful in certain cases.</p>
</div>
<div id="interface-definitions" class="section">
<h3><span class="secno">3.2 </span>Interface definitions</h3>
<p class="note">In this section, we only specify aspects of the the
following objects that are relevant when used along with a
<code>PeerConnection</code>. Please refer to the original definitions
of the objects in the [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] document for general
information on using <code>MediaStream</code> and
<code>MediaStreamTrack</code> both in and outside the context of
<code>PeerConnection</code>.</p>
<div id="mediastream" class="section">
<h4><span class="secno">3.2.1 </span>MediaStream</h4>
<div id="label" class="section">
<h5><span class="secno">3.2.1.1 </span>label</h5>
<p>The <code>label</code> attribute specified in
<code>MediaStream</code> returns a label that is unique to this
stream, so that streams can be recognized after they are sent
through the <code>
<a href="#peerconnection">PeerConnection</a>
</code> API.</p>
<p>When a <code>
<a href="#mediastream">MediaStream</a>
</code> is created to represent a stream obtained from a remote
peer, the <code>label</code> attribute is initialized from
information provided by the remote source.</p>
<p class="note">The label of a <code>
<a>MediaStream</a>
</code> object is unique to the source of the stream, but that
does not mean it is not possible to end up with duplicates. For
example, a locally generated stream could be sent from one user to
a remote peer using <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code>, and then sent back to the original user in the same
manner, in which case the original user will have multiple streams
with the same label (the locally-generated one and the one
received from the remote peer).</p>
</div>
<div id="events-on-mediastream" class="section">
<h5><span class="secno">3.2.1.2 </span>Events on MediaStream</h5>
<p>A new media component may be associated with an existing <code>
<a>MediaStream</a>
</code>. This happens, e.g., on the A-side when the B-side adds
a new <code>
<a>MediaStreamTrack</a>
</code> object to one of the track lists of a <code>
<a>MediaStream</a>
</code> that is being sent over a <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code>. If this happens for the reason exemplified, or for any
other reason than the <code>add()</code> [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] method
being invoked locally on a <code>
<a>MediaStreamTrackList</a>
</code> or tracks are being added as the stream is created (i.e.
the stream is initialized with tracks), the user agent <em class="rfc2119" title="must">must</em> run
the following steps:</p>
<ol>
<li>
<p>Create a <code>
<a>MediaStreamTrack</a>
</code> object <var>track</var> to represent the new media
component.</p>
</li>
<li>
<p>If <var>track’s</var> <code>
<a href="#dom-mediastreamtrack-kind">kind</a>
</code> attribute equals "<code>audio</code>", add it to the
<code>
<a>MediaStream</a>
</code> object’s <code>
<a href="#dom-mediastream-audiotracks">audioTracks</a>
</code> <code>
<a>MediaStreamTrackList</a>
</code> object. [[OPEN ISSUE: Is there a way to generalize this
so that if we add a "smell" track this continues to work.]]</p>
</li>
<li>
<p>If <var>track’s</var> <code>
<a href="#dom-mediastreamtrack-kind">kind</a>
</code> attribute equals "<code>video</code>", add it to the
<code>
<a>MediaStream</a>
</code> object’s <code>
<a href="#dom-mediastream-videotracks">videoTracks</a>
</code> <code>
<a>MediaStreamTrackList</a>
</code> object.</p>
</li>
<li>
<p><a href="#dfn-fire-a-track-event-2" class="internalDFN">Fire a track event</a> named <code>
<a href="#event-mediastreamtracklist-addtrack">addtrack</a>
</code> with the newly created <var>track</var> at the <code>
<a>MediaStreamTrackList</a>
</code> object.</p>
</li>
</ol>
<p>An existing media component may also be disassociated from a
<code>
<a>MediaStream</a>
</code>. If this happens for any other reason than the
<code>remove()</code> [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] method being invoked
locally on a <code>
<a>MediaStreamTrackList</a>
</code> or the stream is being destroyed, the user agent <em class="rfc2119" title="must">must</em>
run the following steps:</p>
<ol>
<li>
<p>Let <var>track</var> be the <code>
<a>MediaStreamTrack</a>
</code> object representing the media component about to be
removed.</p>
</li>
<li>
<p>Remove <var>track</var> from the <code>
<a>MediaStreamTrackList</a>
</code> object.</p>
</li>
<li>
<p><a href="#dfn-fire-a-track-event-2" class="internalDFN">Fire a track event</a> named <code>
<a href="#event-mediastreamtracklist-removetrack">removetrack</a>
</code> with <var>track</var> at the <code>
<a>MediaStreamTrackList</a>
</code> object.</p>
</li>
</ol>
<p>The event source for the <code>onended</code> event in the
networked case is the <code>PeerConnection</code> object.</p>
</div>
</div>
<div id="mediastreamtrack" class="section">
<h4><span class="secno">3.2.2 </span>MediaStreamTrack</h4>
<p>A <code>MediaStreamTrack</code> object’s reference to its
<code>MediaStream</code> in the non-local media source case (an RTP
source, as is the case for a <code>MediaStream</code> received over
a <code>PeerConnection</code>) is always strong.</p>
<p>When a track belongs to a <code>
<a>MediaStream</a>
</code> that comes from a remote peer and the remote peer has
permanently stopped sending data the <code>ended</code> event <em class="rfc2119" title="must">must</em>
be fired on the track, as specified in [<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>].
[[ OPEN ISSUE: How do you know when it has stopped? This seems like
an SDP question, not a media-levelquestion.]]</p>
<p>A track in a <code>
<a>MediaStream</a>
</code>, received with a <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code>, <em class="rfc2119" title="must">must</em> have its <code>readyState</code> attribute
[<cite><a class="bibref" rel="biblioentry" href="#bib-GETUSERMEDIA">GETUSERMEDIA</a></cite>] set to <code>
<a href="#widl-MediaStreamTrack-MUTED">MUTED</a>
</code> (1) until media data arrives.</p>
<p>In addition, a <code>MediaStreamTrack</code> has its
<code>readyState</code> set to <code>MUTED</code> on the B-side if
the A-side disables the corresponding <code>
<a>MediaStreamTrack</a>
</code> in the <code>
<a>MediaStream</a>
</code> that is being sent. When the addstream event triggers on a
<code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code>, all <code>
<a>MediaStreamTrack</a>
</code> objects in the resulting <code>
<a>MediaStream</a>
</code> are muted until media data can be read from the RTP
source.
[[ OPEN ISSUE: How do you know when it has been disabled? This seems like
an SDP question, not a media-levelquestion.]]
</p>
</div>
</div>
<div id="audiomediastreamtrack" class="section">
<h3><span class="secno">3.3 </span>AudioMediaStreamTrack</h3>
<p>The <code>
<a href="#idl-def-AudioMediaStreamTrack" class="idlType"><code>AudioMediaStreamTrack</code></a>
</code> is a specialization of of a normal <code>
<a>MediaStreamTrack</a>
</code> that only carries audio and is extended to have the
capability to send and/or receive DTMF codes.</p>
<pre class="idl"><span id="idl-def-AudioMediaStreamTrack" class="idlInterface">interface <span class="idlInterfaceID">AudioMediaStreamTrack</span> : <span class="idlSuperclass"><a>MediaStreamTrack</a></span> {
<span class="idlAttribute"> readonly attribute <span class="idlAttrType"><a>boolean</a></span> <span class="idlAttrName"><a href="#widl-AudioMediaStreamTrack-canInsertDTMF">canInsertDTMF</a></span>;</span>
<span class="idlMethod"> <span class="idlMethType"><a>void</a></span> <span class="idlMethName"><a href="#widl-AudioMediaStreamTrack-insertDTMF-void-DOMString-tones-long-duration">insertDTMF</a></span> (<span class="idlParam"><span class="idlParamType"><a>DOMString</a></span> <span class="idlParamName">tones</span></span>, <span class="idlParam">optional <span class="idlParamType"><a>long</a></span> <span class="idlParamName">duration</span></span>);</span>
};</span>
</pre><div id="attributes" class="section"><h4><span class="secno">3.3.1 </span>Attributes</h4><dl class="attributes"><dt id="widl-AudioMediaStreamTrack-canInsertDTMF"><code>canInsertDTMF</code> of type <span class="idlAttrType"><a>boolean</a></span>, readonly</dt><dd>
<p>The <dfn id="dom-audiomediastreamtrack-caninsertdtmf">
<code>canInsertDTMF</code>
</dfn> attribute <em class="rfc2119" title="must">must</em> indicate if the <code>
<a href="#idl-def-AudioMediaStreamTrack" class="idlType"><code>AudioMediaStreamTrack</code></a>
</code> is capable of sending DTMF.</p>
</dd></dl></div><div id="methods" class="section"><h4><span class="secno">3.3.2 </span>Methods</h4><dl class="methods"><dt id="widl-AudioMediaStreamTrack-insertDTMF-void-DOMString-tones-long-duration"><code>insertDTMF</code></dt><dd>
<p>When a <code>
<a href="#idl-def-AudioMediaStreamTrack" class="idlType"><code>AudioMediaStreamTrack</code></a>
</code> object’s <dfn id="dom-AudioMediaStreamTrack-insertDTMF">
<code>insertDTMF()</code>
</dfn> method is invoked, the user agent <em class="rfc2119" title="must">must</em> queue a task that
that sends the DTMF tones.</p>
<p>The tone parameters is treated as a series of characters. The
characters 0 to 9, A to D, #, and * generated the associated DTMF
tones. The characters a to d are equivalent to A to D. The
character , indicates a an delay of 2 seconds before processing
the next character in the tones parameter. Unrecognized characters
are ignored.</p>
<p>The duration parameters indicates the duration in ms to play
the each DTMF passed in the tones parameters. The duration can not
be more than 6000 or less than 70. The default duration is 100 ms
for each tone. The gap between tones <em class="rfc2119" title="must">must</em> be at least 50 ms but
should be as short as possible. [[OPEN ISSUE: How are invalid values
handled?]]</p>
<p>If insertDTMF is called on the same object while an existing
task for this object is generate DTMF is still running, the
previous task is canceled. Calling insertDTMF with an empty tones
parameter can be used to cancel any tones currently being
send.</p>
<p class="note">Editor Note: We need to add a callback that is set
on the object that is called after the tones are sent. This is
needed to allow the application to know when it can send new tones
without canceling the tones that are currently being sent.</p>
<p class="note">Editor Note: It seems we would want a callback or
event for incoming tones. The proposal sent to the list had them
played as audio to the speaker but I don’t see how that is
useful.</p>
<table class="parameters"><tr><th>Parameter</th><th>Type</th><th>Nullable</th><th>Optional</th><th>Description</th></tr><tr><td class="prmName">tones</td><td class="prmType"><code><a>DOMString</a></code></td><td class="prmNullFalse">✘</td><td class="prmOptFalse">✘</td><td class="prmDesc"></td></tr><tr><td class="prmName">duration</td><td class="prmType"><code><a>long</a></code></td><td class="prmNullFalse">✘</td><td class="prmOptTrue">✔</td><td class="prmDesc"></td></tr></table><div><em>Return type: </em><code><a>void</a></code></div></dd></dl></div>
</div>
</div>
<div id="peer-to-peer-connections" class="section">
<!-- OddPage -->
<h2><span class="secno">4. </span>Peer-to-peer connections</h2>
<p>A <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> allows two users to communicate directly, browser to browser.
Communications are coordinated via a signaling channel which is provided
by unspecified means, but generally by a script in the page via the server,
e.g. using <code>XMLHttpRequest</code>.</p>
<p>Calling <code>new <a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>(<var>configuration</var>
)</code> creates a <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object.</p>
<p>The <var>configuration</var> has the information to find and access
the [<cite><a class="bibref" rel="biblioentry" href="#bib-STUN">STUN</a></cite>] and [<cite><a class="bibref" rel="biblioentry" href="#bib-TURN">TURN</a></cite>] servers. There may be multiple servers of
each type and any TURN server also acts as a STUN server. </p>
<p>A PeerConnection object has an associated ICE Agent, PeerConnection
state, and ICE State. These are initialized when the object is
created.</p>
<p>When the <dfn id="dom-peerconnection">
<code>PeerConnection()</code>
</dfn> constructor is invoked, the user agent <em class="rfc2119" title="must">must</em> run the following
steps. This algorithm has a synchronous section (which is triggered as
part of the event loop algorithm).</p>
<ol>
<li>
<p>Create an ICE Agent and let <var>connection</var>’s <a href="#peerconnection-ice-agent"><code>PeerConnection</code> ICE
Agent</a> be that ICE Agent and provide it the STUN and TURN servers
from the configuration array. The [<cite><a class="bibref" rel="biblioentry" href="#bib-ICE">ICE</a></cite>] will proceed with
gathering as soon as the IceTransports constraint is not set to
"none". At this point the ICE Agent does not know how many
ICE components it needs (and hence the number of candidates to
gather) but it can make a reasonable
assumption and as the PeerConnection object gets more information,
it can adjust the number of components. </p>
</li>
<li>
<p>Set <var>connection</var>’s <a href="#peerconnection-readiness-state"><code>PeerConnection</code>
readiness state</a> to <code>
<a href="#widl-PeerConnection-NEW">"new"</a>
</code>. </p>
</li>
<li>
<p>Set <var>connection</var>’s <a href="#peerconnection-readiness-state"><code>PeerConnection</code>
ice state </a> to <code>
<a href="#widl-PeerConnection-NEW">"new"</a>
</code>. </p>
</li>
<li>
<p>Let <var>connection</var>’s <code title="dom-PeerConnection-localStreams">
<a href="#widl-PeerConnection-localStreams">localStreams</a>
</code> attribute be an empty read-only <code>
<a>MediaStream</a>
</code> array. </p>
</li>
<li>
<p>Let <var>connection</var>’s <code title="dom-PeerConnection-remoteStreams">
<a href="#widl-PeerConnection-remoteStreams">remoteStreams</a>
</code> attribute be an empty read-only <code>
<a>MediaStream</a>
</code> array. </p>
</li>
<li>
<p>Return <var>connection</var>, but continue these steps
asynchronously.</p>
</li>
<li>
<p>Await a stable state. The synchronous section consists of the
remaining steps of this algorithm. </p>
</li>
</ol>
<p> During the lifetime of the PeerConnection object, the following
procedures are followed: </p>
<ol>
<li>
<p>If the ice state is "new" and the IceTransports constraint
is not set to "none", it <em class="rfc2119" title="must">must</em> queue a task to start gathering ICE
address and set the ice state to "gathering".</p>
</li>
<li>
<p> If the ICE Agent has found one or more candidate pairs for any
MediaTrack that forms a valid connection, the ICE state is changed
to "connected". </p>
</li>
<li>
<p> When the ICE Agent finishes checking all candidate pairs, if at least
one connection has been found for some MediaTrack, the iceState is
changed to "completed" and if no connection has been found for any
MediaTrack, the iceState is changed to "failed".
[[OPEN ISSUE: Note that this means that if I was able to negotiate
audio but not video via ICE, then iceState == "completed". Is this
really what is desired?]]
</p>
</li>
<li>
<p> If the iceState is "connected" or "completed" and both the local
and remote session descriptions are set, the peerState is set to
"active". </p>
</li>
<li>
<p> If the iceState is "failed", a task is queued to calls the close
method. Open Issue: CJ - this seems wrong to me. </p>
</li>
</ol>
<p>User agents negotiate the codec resolution, bitrate, and other media
parameters. User agents are encouraged to initially negotiate for the
maximum resolution of a video stream. For streams that are then rendered
(using a <code>video</code> element), user agents are encouraged to
renegotiate for a resolution that matches the rendered display size.</p>
<p class="note">Starting with the native resolution means that if the
Web application notifies its peer of the native resolution as it starts
sending data, and the peer prepares its <code>video</code> element
accordingly, there will be no need for a renegotiation once the stream
is flowing.</p>
<!--
<p>All SDP media descriptions for RTP flows represented by <code>
<a>MediaTrack</a>
</code> objects MUST include a label attribute ("<code
title="">a=label:</code>") whose value is the value of the <code>
<a>MediaStream</a>
</code> object's <code title="dom-MediaStream-label">
<a href="#dom-mediastream-label">label</a>
</code> attribute. [[!SDP]] [[!SDPLABEL]]</p>
<p><a href="#peerconnection"><code>PeerConnection</code>s</a> MUST not
generate any candidates for media streams whose media descriptions do
not have a label attribute ("<code>a=label:</code>"). [[!ICE]] [[!SDP]]
[[!SDPLABEL]] (Note: CJ - I have no idea why this is here) </p>
-->
<p> The word "components" in this context refers to an RTP media flow
and does not have anything to do with how [<cite><a class="bibref" rel="biblioentry" href="#bib-ICE">ICE</a></cite>] uses the term
"component". </p>
<p>When a user agent has reached the point where a <code>
<a>MediaStream</a>
</code> can be created to represent incoming components, the user
agent <em class="rfc2119" title="must">must</em> run the following steps:</p>
<ol>
<li>
<p>Let <var>connection</var> be the <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> expecting this media.</p>
</li>
<li>
<p>Create a <code>
<a>MediaStream</a>
</code> object to represent the media stream.
<!-- Set its <code>
<a href="#dom-mediastream-label">label</a>
</code> attribute to the value of the SDP Label attribute for that
component's media stream. -->
[[OPEN ISSUE: What if one already exists?]]
</p>
</li>
<li>
<p>Run the following steps for each component in the media
stream.</p>
<ol>
<li>
<p>Create a <code>
<a>MediaStreamTrack</a>
</code> object <var>track</var> to represent the
component.
[[EDITORIAL: Can we just reference 3.2.1.2 here?]]
</p>
</li>
<li>
<p>If <var>track's</var> <code>
<a href="#dom-mediastreamtrack-kind">kind</a>
</code> attribute equals "<code>audio</code>", add it to the
<code>
<a>MediaStream</a>
</code> object's <code>
<a href="#dom-mediastream-audiotracks">audioTracks</a>
</code> <code>
<a>MediaStreamTrackList</a>
</code> object.</p>
</li>
<li>
<p>If <var>track's</var> <code>
<a href="#dom-mediastreamtrack-kind">kind</a>
</code> attribute equals "<code>video</code>", add it to the
<code>
<a>MediaStream</a>
</code> object's <code>
<a href="#dom-mediastream-videotracks">videoTracks</a>
</code> <code>
<a>MediaStreamTrackList</a>
</code> object.</p>
</li>
</ol>
<p class="note">
The creation of new incoming <code>MediaStream</code>s may be
triggered either by SDP negotiation or by the receipt of
media on a given flow.
<!-- [[OPEN ISSUE: How many <code>MediaStream</code>s are created
when you receive multiple conflicting pranswers?]] -->
</p>
<p class="note">The internal order in the <code>
<a>MediaStreamTrackList</a>
</code> objects on the receiving side should reflect the order on
the sending side. One way to enforce this is to specify the order in
the SDP.</p>
</li>
<li>
<p>Queue a task to run the following substeps:</p>
<ol>
<li>
<p>If the <var>connection</var>’s <a href="#peerconnection-readiness-state"><code>PeerConnection</code>
readiness state</a> is <code>
<a href="#widl-PeerConnection-CLOSED">CLOSED</a>
</code> (3), abort these steps.</p>
</li>
<!-- close() was probably called just before this
task ran -->
<li>
<p>Add the newly created <code>
<a>MediaStream</a>
</code> object to the end of <var>connection</var>’s <code title="dom-PeerConnection-remoteStreams">
<a href="#widl-PeerConnection-remoteStreams">remoteStreams</a>
</code> array.</p>
</li>
<li>
<p><a href="#fire-a-stream-event">Fire a stream event</a> named
<code title="event-MediaStream-addstream">
<a href="#event-mediastream-addstream">addstream</a>
</code> with the newly created <code>
<a>MediaStream</a>
</code> object at the <var title="">connection</var> object.
</p>
</li>
</ol>
</li>
</ol>
<p>When a user agent has negotiated media for a component that belongs
to a media stream that is already represented by an existing <code>
<a>MediaStream</a>
</code> object, the user agent <em class="rfc2119" title="must">must</em> associate the component with that
<code>
<a>MediaStream</a>
</code> object.</p>
<p>When a <a href="#peerconnection">
<code>PeerConnection</code>
</a> finds that a stream from the remote peer has been removed
<!-- (its
port has been set to zero in a media description sent on the signaling
channel), -->
, the user agent <em class="rfc2119" title="must">must</em> follow these steps:</p>
<ol>
<li>
<p>Let <var>connection</var> be the <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> associated with the stream being removed.</p>
</li>
<li>
<p>Let <var>stream</var> be the <code>
<a>MediaStream</a>
</code> object that represents the media stream being removed, if
any. If there isn't one, then abort these steps.</p>
</li>
<li>
<p>By definition, <var>stream</var> is now <a>finished</a>.</p>
<p class="note">A <span title="concept-task">task</span> is thus
<span title="queue a task">queued</span> to update <var>stream</var>
and fire an event.</p>
</li>
<li>
<p>Queue a task to run the following substeps:</p>
<ol>
<li>
<p>If the <var>connection</var>’s <a href="#peerconnection-readiness-state"><code>PeerConnection</code>
readiness state</a> is <code>
<a href="#widl-PeerConnection-CLOSED">CLOSED</a>
</code> (3), abort these steps.</p>
</li>
<!-- close() was probably called just before this
task ran -->
<li>
<p>Remove <var>stream</var> from <var>connection</var>’s <code>
<a href="#widl-PeerConnection-remoteStreams">remoteStreams</a>
</code> array.</p>
</li>
<li>
<p><a href="#fire-a-stream-event">Fire a stream event</a> named
<code title="event-MediaStream-removestream">
<a href="#event-mediastream-removestream">removestream</a>
</code> with <var title="">stream</var> at the
<var>connection</var> object.</p>
</li>
</ol>
</li>
</ol>
<p>The task source for the <span title="concept-task">tasks</span>
listed in this section is the networking task source.</p>
<p>If something in the browser changes that causes the <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object to need to initiate a new session descipriton
negotiation, an <code>
<a href="#event-renegotiation">renegotiationneeded</a>
</code> event is fired at the <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object. </p>
<p>In particular, if a <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object is <a title="consumer">consuming</a> a <code>
<a>MediaStream</a>
</code> and a track is added to one of the stream's <code>
<a>MediaStreamTrackList</a>
</code> objects, by, e.g., the <code>
<a href="#dom-mediastreamtracklist-add">add()</a>
</code> method being invoked, the <code>
<a href="#idl-def-PeerConnection" class="idlType"><code>PeerConnection</code></a>
</code> object <em class="rfc2119" title="must">must</em> fire the "renegotiationneeded" event. Removal
of media components must also trigger "renegotianneeded".</p>
<p class="warning">To prevent network sniffing from allowing a fourth
party to establish a connection to a peer using the information sent
out-of-band to the other peer and thus spoofing the client, the
configuration information <em class="rfc2119" title="should">should</em> always be transmitted using an
encrypted connection.</p>
<div id="peerconnection" class="section">
<h3><span class="secno">4.1 </span>PeerConnection</h3>
<p> The general operation of the PeerConnection is described in
[<cite><a class="bibref" rel="biblioentry" href="#bib-RTCWEB-JSEP">RTCWEB-JSEP</a></cite>]. </p>
<div id="sdptype" class="section">
<h4><span class="secno">4.1.1 </span>SdpType</h4>
<p> The SdpType enums serve as arguments to setLocalDescription and
setRemoteDescription. They provide information as to how the SDP
should be handled. </p>
<pre> enum SdpType { "offer", "pranswer", "answer" } </pre>
<!-- <dl class='idl' title='enum SdpType { "offer", "pranswer", "answer" }'> </dl> -->
<dl>
<dt>
<code title="widl-SdpType-offer">
<a href="#widl-SdpType-offer">"offer"</a>
</code>
</dt>
<dd>
<p> An SdpType of "offer" indicates that a description should be
treated as an [<cite><a class="bibref" rel="biblioentry" href="#bib-SDP">SDP</a></cite>] offer. </p>
</dd>
<dt>
<code title="widl-SdpType-pranswer">
<a href="#widl-SdpType-pranswer">"pranswer"</a>
</code>
</dt>
<dd>
<p> An SdpType of "pranswer" indicates that a description should
be treated as an [<cite><a class="bibref" rel="biblioentry" href="#bib-SDP">SDP</a></cite>] answer, but not a final answer. A
description used as a SDP "pranswer" may be applied as a
response to a SDP offer, or an update to a previously sent SDP
"pranswer". </p>
</dd>
<dt>
<code title="widl-SdpType-answer">
<a href="#widl-SdpType-answer">"answer"</a>
</code>
</dt>
<dd>
<p> An SdpType of "answer" indicates that a description should
be treated as an [<cite><a class="bibref" rel="biblioentry" href="#bib-SDP">SDP</a></cite>] final answer, and the offer-answer
exchange should be considered complete. A description used as a
SDP answer may be applied as a response to a SDP offer, or an
update to a previously send SDP "pranswer". </p>
</dd>
</dl>
</div>
<div id="sessiondescription-class" class="section">
<h4><span class="secno">4.1.2 </span> SessionDescription Class </h4>
<p>The <dfn id="dom-sessiondescription">
<code>SessionDescription()</code>
</dfn> constructor takes one argument, <var>description</var>,
whose content is used to construct the new <code>
<a href="#idl-def-SessionDescription" class="idlType"><code>SessionDescription</code></a>
</code> object. This class is a future extensible carrier
for for the data contained in it and does not perform any
substantive processing. </p>
<pre class="idl"><span id="idl-def-SessionDescription" class="idlInterface">[<span class="extAttr">Constructor (DOMString description)</span>]
interface <span class="idlInterfaceID">SessionDescription</span> {
<span class="idlAttribute"> attribute <span class="idlAttrType"><a>SdpType</a></span> <span class="idlAttrName"><a href="#widl-SessionDescription-type">type</a></span>;</span>
<span class="idlAttribute"> attribute <span class="idlAttrType"><a>DOMString</a></span> <span class="idlAttrName"><a href="#widl-SessionDescription-sdp">sdp</a></span>;</span>
<span class="idlMethod"> <span class="idlMethType"><a>stringifier</a></span> <span class="idlMethName"><a href="#widl-SessionDescription-DOMString-stringifier">DOMString</a></span> ();</span>
};</span>
</pre><div id="attributes-1" class="section"><h5><span class="secno">4.1.2.1 </span>Attributes</h5><dl class="attributes"><dt id="widl-SessionDescription-sdp"><code>sdp</code> of type <span class="idlAttrType"><a>DOMString</a></span></dt><dd>The string representation of the SDP [<cite><a class="bibref" rel="biblioentry" href="#bib-SDP">SDP</a></cite>]</dd><dt id="widl-SessionDescription-type"><code>type</code> of type <span class="idlAttrType"><a>SdpType</a></span></dt><dd>What type of SDP this SessionDescription represents.</dd></dl></div><div id="methods-1" class="section"><h5><span class="secno">4.1.2.2 </span>Methods</h5><dl class="methods"><dt id="widl-SessionDescription-DOMString-stringifier"><code>DOMString</code></dt><dd>
<p>Objects that implement the <code>
<a href="#idl-def-SessionDescription" class="idlType"><code>SessionDescription</code></a>
</code> interface must stringify as [<cite><a class="bibref" rel="biblioentry" href="#bib-SDP">SDP</a></cite>]. </p>
<div><em>No parameters.</em></div><div><em>Return type: </em><code><a>stringifier</a></code></div></dd></dl></div>
</div>
<div id="sessiondescriptioncallback" class="section">
<h4><span class="secno">4.1.3 </span> SessionDescriptionCallback </h4>
<pre> callback SessionDescriptionCallback = void (SessionDescription
sdp) </pre>
<dl>
<!-- dl title='callback SessionDescriptionCallback = void' class='idl' -->
<dt>SessionDescription sdp</dt>
<dd>The object containing the SDP [<cite><a class="bibref" rel="biblioentry" href="#bib-SDP">SDP</a></cite>]. </dd>
</dl>
</div>
<div id="peerconnectionerrorcallback" class="section">
<h4><span class="secno">4.1.4 </span> PeerConnectionErrorCallback </h4>
<pre> callback PeerConnectionErrorCallback = void (DOMString errorInformation)
</pre>
<dl>
<!-- dl title='callback PeerConnectionErrorCallback = void' class='idl' -->
<dt>DOMString errorInformation</dt>
<dd>Information about what went wrong. Open Issue: How does this
work? Is it human readable? I18N? ENUM? </dd>
</dl>
<p> TODO: Open Issue: should this be defined as event like
NavigatorUserMediaErrorCallback in getusermedia </p>
</div>
<div id="peerstate-enum" class="section">
<h4><span class="secno">4.1.5 </span> PeerState Enum </h4>
<pre>enum PeerState { "new" "opening", "active", "closing", "closed"
}</pre>
<!-- <dl title='enum PeerState { "new" "opening","active", "closing", "closed" }' class='idl' > </dl> -->
<dl>
<dt>
<code title="widl-PeerConnection-NEW">
<a href="#widl-PeerConnection-NEW">"new"</a>
</code>
</dt>
<dd> The object was just created, and no networking has yet
occurred. </dd>
<dt>
<code title="dom-PeerConnection-NEGOTIATING">
<a href="#widl-PeerConnection-OPENING">"opening"</a>
</code>
</dt>
<dd>The user agent is attempting to establish an connection with
the ICE Agent and waiting for local and remote SDP to be set.
(Open Issue: do we need more states between "opening" and
"active") </dd>
<dt>
<code title="dom-PeerConnection-ACTIVE">
<a href="#widl-PeerConnection-ACTIVE">"active"</a>
</code>
</dt>
<dd>The ICE Agent has found a connection both the local and remote