-
Notifications
You must be signed in to change notification settings - Fork 9
/
Copy pathdraft-ietf-mmusic-sdp-bundle-negotiation-54.xml
3249 lines (3085 loc) · 152 KB
/
draft-ietf-mmusic-sdp-bundle-negotiation-54.xml
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="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="pre5378Trust200902" category="std" docName="draft-ietf-mmusic-sdp-bundle-negotiation-54.txt" updates="3264,5888,7941" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Bundled media">
Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
</title>
<author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Harald Tveit Alvestrand" surname="Alvestrand" initials="H. T.">
<organization>Google</organization>
<address>
<postal>
<street>Kungsbron 2</street>
<city>Stockholm</city>
<code>11122</code>
<country>Sweden</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>400 3rd Avenue SW, Suite 350</street>
<city>Calgary</city>
<region>AB</region>
<code>T2P 4H2</code>
<country>Canada</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date year="2018" />
<area>Transport</area>
<workgroup>MMUSIC Working Group</workgroup>
<keyword>RTP</keyword>
<keyword>SDP</keyword>
<keyword>Bundle</keyword>
<keyword>Multiplexing</keyword>
<keyword>RTCWEB</keyword>
<keyword>CLUE</keyword>
<keyword>RTCWEB</keyword>
<keyword>MMUSIC</keyword>
<keyword>AVT</keyword>
<keyword>WEB</keyword>
<keyword>Browser</keyword>
<abstract>
<t>
This specification defines a new Session Description
Protocol (SDP) Grouping Framework extension, 'BUNDLE'.
The extension can be used with the SDP Offer/Answer mechanism
to negotiate the usage of a single transport (5-tuple) for
sending and receiving media described by multiple SDP media descriptions
("m=" sections). Such transport is referred to as a BUNDLE transport,
and the media is referred to as bundled media. The "m=" sections that
use the BUNDLE transport form a BUNDLE group.
</t>
<t>
This specification updates RFC 3264, to also allow assigning a zero port value
to a "m=" section in cases where the media described by the "m=" section
is not disabled or rejected.
</t>
<t>
This specification updates RFC 5888, to also allow an SDP 'group' attribute to
contain an identification-tag that identifies a "m=" section with the port set to zero.
</t>
<t>
This specification defines a new RTP Control Protocol
(RTCP) source description (SDES) item and a new RTP header
extension that can be used to correlate bundled RTP/RTCP packets
with their appropriate "m=" section.
</t>
<t>
This specification updates RFC 7941, by adding an exception,
for the MID RTP header extension, to the requirement regarding protection
of an SDES RTP header extension carrying an SDES item for the MID RTP
header extension.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<section title="Background" toc="default">
<t>
When the SDP offer/answer mechanism <xref format="default" pageno="false" target="RFC3264"/>
is used to negotiate the establishment of multimedia communication sessions, if separate
transports (5-tuples) are negotiated for each individual media stream, each transport consumes
additional resources (especially when Interactive Connectivity Establishment (ICE)
<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> is used).
For this reason, it is attractive to use a single transport for multiple media streams.
</t>
</section>
<section title="BUNDLE Mechanism" toc="default">
<t>
This specification defines a way to use a single transport (BUNDLE transport)
for sending and receiving media (bundled media) described by multiple SDP media descriptions
("m=" sections). The address:port combination used by an endpoint for sending and receiving
bundled media is referred to as the BUNDLE address:port. The set of SDP attributes that are
applied to each "m=" section within a BUNDLE group is referred to as BUNDLE attributes.
The same BUNDLE transport is used for sending and receiving bundled media, which
means that the symmetric Real-time Transport Protocol (RTP) mechanism <xref format="default"
pageno="false" target="RFC4961"/> is always used for RTP-based bundled media.
</t>
<t>
This specification defines a new SDP Grouping Framework <xref format="default" pageno="false"
target="RFC5888"/> extension called 'BUNDLE'. The extension can be used with the Session Description
Protocol (SDP) Offer/Answer mechanism <xref format="default" pageno="false" target="RFC3264"/>
to negotiate which "m=" sections will become part of a BUNDLE group. In addition, the offerer and
answerer <xref format="default" pageno="false" target="RFC3264"/> use the BUNDLE extension to negotiate
the BUNDLE addresses:ports (offerer BUNDLE address:port and answerer BUNDLE address:port) and the
set of BUNDLE attributes (offerer BUNDLE attributes and answerer BUNDLE attributes) that will be applied to
each "m=" section within the BUNDLE group.
</t>
<t>
The use of a BUNDLE transport allows the usage of a single set of
Interactive Connectivity Establishment (ICE) <xref format="default" pageno="false"
target="I-D.ietf-ice-rfc5245bis"/> candidates for the whole BUNDLE group.
</t>
<t>
A given BUNDLE address:port MUST only be associated with a single BUNDLE group. If an SDP offer
or answer contains multiple BUNDLE groups, the procedures in this specification apply to each
group independently. All RTP-based bundled media associated with a given BUNDLE group belong to a single
RTP session <xref format="default" pageno="false" target="RFC3550"/>.
</t>
<t>
The BUNDLE extension is backward compatible. Endpoints that do not support the extension
are expected to generate offers and answers without an SDP 'group:BUNDLE' attribute, and
are expected to assign a unique address:port to each "m=" section within an offer and answer, according
to the procedures in <xref format="default" pageno="false" target="RFC4566"/> and
<xref format="default" pageno="false" target="RFC3264"/>.
</t>
</section>
<section title="Protocol Extensions" toc="default">
<t>
In addition to defining the new SDP Grouping Framework extension, this specification defines
the following protocol extensions and RFC updates:
<list style="symbols">
<t>
The specification defines a new SDP attribute, 'bundle-only', which can be used to
request that a specific "m=" section (and the associated media) is used only used if kept
within a BUNDLE group.
</t>
<t>
The specification updates RFC 3264 <xref format="default" pageno="false"
target="RFC3264"/>, to also allow assigning a zero port value to a "m=" section
in cases where the media described by the "m=" section is not disabled or rejected.
</t>
<t>
The specification defines a new RTP Control Protocol (RTCP) <xref format="default"
pageno="false" target="RFC3550"/> source description (SDES) item, 'MID', and a new RTP SDES header
extension that can be used to associate RTP streams with "m=" sections.
</t>
<t>
The specification updates <xref format="default" pageno="false" target="RFC7941"/>, by adding an exception,
for the MID RTP header extension, to the requirement regarding protection
of an SDES RTP header extension carrying an SDES item for the MID RTP
header extension.
</t>
</list>
</t>
</section>
</section>
<section anchor="sec-term" title="Terminology" toc="default">
<t>
<list style="symbols">
<t>
"m=" section: SDP bodies contain one or more media descriptions, referred to
as "m=" sections. Each "m=" section is represented by an SDP "m=" line, and zero or more
SDP attributes associated with the "m=" line. A local address:port combination is
assigned to each "m=" section.
</t>
<t>
5-tuple: A collection of the following values: source address, source
port, destination address, destination port, and transport-layer
protocol.
</t>
<t>
Unique address:port: An address:port combination that is assigned to
only one "m=" section in an offer or answer.
</t>
<t>
Offerer BUNDLE-tag: The first identification-tag in a given
SDP 'group:BUNDLE' attribute identification-tag list in an offer.
</t>
<t>
Answerer BUNDLE-tag: The first identification-tag in a given
SDP 'group:BUNDLE' attribute identification-tag list in an answer.
</t>
<t>
Suggested offerer tagged "m=" section: The bundled "m=" section identified by the offerer BUNDLE-tag in an initial BUNDLE offer,
before a BUNDLE group has been negotiated.
</t>
<t>
Offerer tagged "m=" section: The bundled "m=" section identified by the offerer BUNDLE-tag in a subsequent offer.
The "m=" section contains characteristics (offerer BUNDLE address:port and offerer BUNDLE attributes) applied to
each "m=" section within the BUNDLE group.
</t>
<t>
Answerer tagged "m=" section: The bundled "m=" section identified by the answerer BUNDLE-tag in an answer
(initial BUNDLE answer or subsequent). The "m=" section contains characteristics (answerer BUNDLE address:port and answerer BUNDLE attributes)
applied to each "m=" section within the BUNDLE group.
</t>
<t>
BUNDLE address:port: An address:port combination that an endpoint uses for sending and receiving
bundled media.
</t>
<t>
Offerer BUNDLE address:port: the address:port combination used by the offerer
for sending and receiving media.
</t>
<t>
Answerer BUNDLE address:port: the address:port combination used by the answerer
for sending and receiving media.
</t>
<t>
BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP
attributes. Once a BUNDLE group has been created, the attribute values apply
to each bundled "m=" section within the BUNDLE group.
</t>
<t>
Offerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP
attributes included in the offerer tagged "m=" section.
</t>
<t>
Answerer BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category SDP
attributes included in the answerer tagged "m=" section.
</t>
<t>
BUNDLE transport: The transport (5-tuple) used by all media described by the
"m=" sections within a BUNDLE group.
</t>
<t>
BUNDLE group: A set of bundled "m=" sections, created using an SDP Offer/Answer
exchange, which uses a single BUNDLE transport, and a single set of BUNDLE attributes,
for sending and receiving all media (bundled media) described by the set of "m=" sections.
The same BUNDLE transport is used for sending and receiving bundled media.
</t>
<t>
Bundled "m=" section: An "m=" section, whose identification-tag
is placed in an SDP 'group:BUNDLE' attribute identification-tag list
in an offer or answer.
</t>
<t>
Bundle-only "m=" section: A bundled "m=" section that contains an
SDP 'bundle-only' attribute.
</t>
<t>
Bundled media: All media associated with a given BUNDLE group.
</t>
<t>
Initial BUNDLE offer: The first offer, within an SDP session (e.g. a SIP dialog
when the Session Initiation Protocol (SIP) <xref format="default"
pageno="false" target="RFC3261" /> is used to carry SDP), in which
the offerer indicates that it wants to negotiate a given BUNDLE group.
</t>
<t>
Initial BUNDLE answer: The answer to an initial BUNDLE offer in which the offerer indicates that it wants to negotiate
a BUNDLE group, and where the answerer accepts the creation of the BUNDLE group. The BUNDLE group is
created once the answerer sends the initial BUNDLE answer.
</t>
<t>
Subsequent offer: An offer which contains a BUNDLE group that
has been created as part of a previous offer/answer exchange.
</t>
<t>
Subsequent answer: An answer to a subsequent offer.
</t>
<t>
Identification-tag: A unique token value that is used to identify an
"m=" section. The SDP 'mid' attribute <xref format="default" pageno="false"
target="RFC5888" /> in an "m=" section carries the unique identification-tag
assigned to that "m=" section. The session-level SDP 'group' attribute
<xref format="default" pageno="false" target="RFC5888" /> carries a list of
identification-tags, identifying the "m=" sections associated with that
particular 'group' attribute.
</t>
</list>
</t>
</section>
<section title="Conventions" toc="default">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref format="default" pageno="false" target="RFC2119" />
<xref format="default" pageno="false" target="RFC8174" /> when,
and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Applicability Statement" toc="default">
<t>
The mechanism in this specification only applies to the Session
Description Protocol (SDP) <xref format="default" pageno="false"
target="RFC4566"/>, when used together with the SDP offer/answer
mechanism <xref format="default" pageno="false" target="RFC3264"/>.
Declarative usage of SDP is out of scope of this document, and is
thus undefined.
</t>
</section>
<section title="SDP Grouping Framework BUNDLE Extension" anchor="sec-group" toc="default">
<t>
This section defines a new SDP Grouping Framework <xref format="default" pageno="false"
target="RFC5888"/> extension, 'BUNDLE'. The BUNDLE extension can be used with the SDP
Offer/Answer mechanism to negotiate a set of "m=" sections that will become part of a BUNDLE
group. Within a BUNDLE group, each "m=" section uses a BUNDLE transport for sending and
receiving bundled media. Each endpoint uses a single address:port combination for sending and
receiving the bundled media.
</t>
<t>
The BUNDLE extension is indicated using an SDP 'group' attribute with a semantics value
<xref format="default" pageno="false" target="RFC5888"/> of "BUNDLE".
An identification-tag is assigned to each bundled
"m=" section, and each identification-tag is listed in the SDP 'group:BUNDLE'
attribute identification-tag list. Each "m=" section whose identification-tag
is listed in the identification-tag list is associated with a given
BUNDLE group.
</t>
<t>
SDP bodies can contain multiple BUNDLE groups. Any given bundled "m="
section MUST NOT be associated with more than one BUNDLE group at any given
time.
</t>
<t>
NOTE: The order of the "m=" sections listed in the SDP 'group:BUNDLE' attribute
identification-tag list does not have to be the same as the order in which
the "m=" sections occur in the SDP.
</t>
<t>
The multiplexing category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'group:BUNDLE'
attribute is 'NORMAL'.
</t>
<t>
<xref target="sec-sdp-oa" pageno="false" format="default"/> defines the
detailed SDP Offer/Answer procedures for the BUNDLE extension.
</t>
</section>
<section anchor="sec-bundle-only" title="SDP 'bundle-only' Attribute" toc="default">
<t>
This section defines a new SDP media-level attribute <xref target="RFC4566" pageno="false"
format="default"/>, 'bundle-only'. 'bundle-only' is a property attribute
<xref target="RFC4566" pageno="false" format="default"/>, and hence has no value.
</t>
<t>
In order to ensure that an answerer that does not support the BUNDLE extension always
rejects a bundled "m=" section in an offer, the offerer can assign a zero port value to the "m="
section. According to <xref target="RFC3264" pageno="false" format="default"/> an answerer
will reject such an "m=" section.
By including an SDP 'bundle-only' attribute in a bundled "m=" section, the offerer can
request that the answerer accepts the "m=" section only if the answerer supports the BUNDLE
extension, and if the answerer keeps the "m=" section within the associated BUNDLE group.
</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
Name: bundle-only
Value: N/A
Usage Level: media
Charset Dependent: no
Example:
a=bundle-only
]]></artwork>
</figure>
<t>
Once the offerer tagged "m=" section and the answerer tagged "m=" section have been selected,
an offerer and answerer will include an SDP 'bundle-only' attribute in, and assign a zero
port value to, every other bundled "m=" section.
</t>
<t>
The usage of the 'bundle-only' attribute is only defined for a bundled "m=" section with
a zero port value. Other usage is unspecified.
</t>
<t>
<xref target="sec-sdp-oa" pageno="false" format="default"/> defines the detailed SDP
Offer/Answer procedures for the 'bundle-only' attribute.
</t>
</section>
<section title="SDP Offer/Answer Procedures" anchor="sec-sdp-oa" toc="default">
<t>
This section describes the SDP Offer/Answer <xref format="default"
pageno="false" target="RFC3264"/> procedures for:
<list style="symbols">
<t>
Negotiating a BUNDLE group; and
</t>
<t>
Suggesting and selecting the tagged "m=" sections (offerer tagged "m=" section and answerer tagged "m=" section); and
</t>
<t>
Adding an "m=" section to a BUNDLE group; and
</t>
<t>
Moving an "m=" section out of a BUNDLE group; and
</t>
<t>
Disabling an "m=" section within a BUNDLE group.
</t>
</list>
</t>
<t>
The generic rules and procedures defined in <xref format="default" pageno="false"
target="RFC3264"/> and <xref format="default" pageno="false" target="RFC5888"/>
also apply to the BUNDLE extension. For example, if an offer is rejected
by the answerer, the previously negotiated addresses:ports, SDP parameters and characteristics
(including those associated with a BUNDLE group) apply. Hence, if an offerer
generates an offer in order to negotiate a BUNDLE group,
and the answerer rejects the offer, the BUNDLE group is not created.
</t>
<t>
The procedures in this section are independent of the media type or
"m=" line proto value assigned to a bundled "m=" section.
<xref format="default" pageno="false" target="sec-rtp"/> defines additional
considerations for RTP based media.
<xref format="default" pageno="false" target="sec-bundle-only"/> defines
additional considerations for the usage of the SDP 'bundle-only' attribute.
<xref format="default" pageno="false" target="sec-ice"/> defines additional
considerations for the usage of Interactive Connectivity Establishment (ICE)
<xref format="default" pageno="false" target="I-D.ietf-ice-rfc5245bis"/> mechanism.
</t>
<t>
Offers and answers can contain multiple BUNDLE groups. The procedures in this
section apply independently to a given BUNDLE group.
</t>
<section title="Generic SDP Considerations" anchor="sec-sdp-cons" toc="default">
<t>
This section describes generic restrictions associated with the usage of
SDP parameters within a BUNDLE group. It also describes how to calculate a
value for the whole BUNDLE group, when parameter and attribute values have been assigned
to each bundled "m=" section.
</t>
<section title="Connection Data (c=)" anchor="sec-sdp-cons-c" toc="default">
<t>
The "c=" line nettype value <xref format="default" pageno="false"
target="RFC4566"/> associated with a bundled "m=" section MUST be 'IN'.
</t>
<t>
The "c=" line addrtype value <xref format="default" pageno="false"
target="RFC4566"/> associated with a bundled "m=" section MUST be 'IP4' or
'IP6'. The same value MUST be associated with each "m=" section.
</t>
<t>
NOTE: Extensions to this specification can specify usage of the BUNDLE
mechanism for other nettype and addrtype values than the ones listed above.
</t>
</section>
<section title="Bandwidth (b=)" anchor="sec-sdp-cons-b" toc="default">
<t>
An offerer and answerer MUST use the rules and restrictions defined
in <xref target="I-D.ietf-mmusic-sdp-mux-attributes" /> for
associating the SDP bandwidth (b=) line with bundled "m=" sections.
</t>
</section>
<section anchor="sec-sdp-oa-cat" title="Attributes (a=)" toc="default">
<t>
An offerer and answerer MUST include SDP attributes in every bundled "m=" section where applicable,
following the normal offer/answer procedures for each attribute, with the following exceptions:
<list style="symbols">
<t>
In the initial BUNDLE offer, the offerer MUST NOT include IDENTICAL and TRANSPORT multiplexing category SDP
attributes (BUNDLE attributes) in bundle-only "m=" sections. The offerer MUST include
such attributes in all other bundled "m=" sections. In the initial BUNDLE offer each bundled "m=" line can contain
a different set of BUNDLE attributes, and attribute values. Once the offerer tagged "m=" section has been
selected, the BUNDLE attributes contained in the offerer tagged "m=" section will apply to each bundled "m="
section within the BUNDLE group.
</t>
<t>
In a subsequent offer, or in an answer (initial of subsequent), the offerer and answerer MUST include
IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) only in the tagged "m=" section
(offerer tagged "m=" section or answerer tagged "m=" section). The offerer and answerer MUST NOT
include such attributes in any other bundled "m=" section. The BUNDLE attributes contained in the tagged "m=" section
will apply to each bundled "m=" section within the BUNDLE group.
</t>
<t>
In an offer (initial BUNDLE offer or subsequent), or in an answer (initial BUNDLE answer or subsequent), the offerer and answerer MUST
include SDP attributes of other categories than IDENTICAL and TRANSPORT in each bundled "m=" section that
a given attribute applies to. Each bundled "m=" line can contain a different set of such attributes, and
attribute values, as such attributes only apply to the given bundled "m=" section in which they are included.
</t>
</list>
</t>
<t>
NOTE: A consequence of the rules above is that media-specific IDENTICAL and TRANSPORT multiplexing
category SDP attributes which are applicable only to some of the bundled "m=" sections within
the BUNDLE group might appear in the tagged "m=" section for which they are not applicable. For instance,
the tagged "m=" section might contain an SDP 'rtcp-mux' attribute even if the tagged "m=" section does not describe
RTP-based media (but another bundled "m=" section within the BUNDLE group does describe RTP-based media).
</t>
</section>
</section>
<section anchor="sec-sdp-oa-ino" title="Generating the Initial SDP Offer" toc="default">
<t>
The procedures in this section apply to the first offer, within an SDP session (e.g. a SIP
dialog when the Session Initiation Protocol (SIP) [RFC3261] is used to carry SDP), in which the
offerer indicates that it wants to negotiate a given BUNDLE group. This could occur in the
initial offer, or in a subsequent offer, of the SDP session.
</t>
<t>
When an offerer generates an initial BUNDLE offer, in order to negotiate a
BUNDLE group, it MUST:
<list style="symbols">
<t>
Assign a unique address:port to each bundled "m=" section,
following the procedures in <xref target="RFC3264" pageno="false"
format="default"/>, excluding any bundle-only "m=" sections (see below); and
</t>
<t>
Pick a bundled "m=" section as the suggested offerer tagged "m=" section [<xref target="sec-sdp-oa-ino-req"
pageno="false" format="default"/>]; and
</t>
<t>
Include SDP attributes in the bundled "m=" sections following the rules
in [<xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; and
</t>
<t>
Include an SDP 'group:BUNDLE' attribute in the offer; and
</t>
<t>
Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag
indicates the suggested offerer tagged "m=" section.
</t>
</list>
</t>
<t>
NOTE: When the offerer assigns unique addresses:ports to multiple bundled "m=" sections, the offerer needs to be prepared
to receive bundled media on each unique address:port, until it receives the associated answer and finds out which
bundled "m=" section (and associated address:port combination) the answerer has selected as the offerer tagged "m=" section.
</t>
<t>
If the offerer wants to request that the answerer accepts a given bundled "m=" section only if
the answerer keeps the "m=" section within the negotiated BUNDLE group, the offerer MUST:
<list style="symbols">
<t>
Include an SDP 'bundle-only' attribute [<xref target="sec-sdp-oa-ino-req" pageno="false"
format="default"/>] in the "m=" section; and
</t>
<t>
Assign a zero port value to the "m=" section.
</t>
</list>
</t>
<t>
NOTE: If the offerer assigns a zero port value to a bundled "m=" section, but does not include an
SDP 'bundle-only' attribute in the "m=" section, it is an indication that the offerer wants
to disable the "m=" section [<xref target="sec-sdp-oa-mod-dis" pageno="false" format="default"/>].
</t>
<t>
[<xref target="sec-sdp-oa-ino-ex" pageno="false" format="default"/>] and [<xref target="sec-example-add" pageno="false" format="default"/>] show
an example of an initial BUNDLE offer.
</t>
<section title="Suggesting the Offerer tagged 'm=' section" anchor="sec-sdp-oa-ino-req" toc="default">
<t>
In the initial BUNDLE offer, the bundled "m=" section indicated by the offerer BUNDLE-tag is the suggested offerer tagged "m=" section.
The address:port combination associated with the "m=" section will be used by the offerer for sending and receiving bundled
media if the answerer selects the "m=" section as the offerer tagged "m=" section [<xref target="sec-sdp-oa-ans-off"
pageno="false" format="default"/>]. In addition, if the answerer selects the "m=" section as the offerer tagged "m=" section,
the BUNDLE attributes included in the "m=" section will be applied to each "m=" section within the negotiated BUNDLE group.
</t>
<t>
The offerer MUST NOT suggest a bundle-only "m=" section as the offerer tagged "m=" section.
</t>
<t>
It is RECOMMENDED that the suggested offerer tagged "m=" section is a bundled "m=" section
that the offerer believes it is unlikely that the answerer will reject, or move out of the BUNDLE group.
How such assumption is made is outside the scope of this document.
</t>
</section>
<section anchor="sec-sdp-oa-ino-ex" title="Example: Initial SDP Offer">
<t>
The example shows an initial BUNDLE offer. The offer includes two
"m=" sections in the offer, and suggests that both "m=" sections are included in a BUNDLE group.
The audio "m=" section is the suggested offerer tagged "m=" section, indicated by placing the
identification-tag associated with the "m=" section (offerer BUNDLE-tag) first in the SDP group:BUNDLE
attribute identification-id list.
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Offer
v=0
o=alice 2890844526 2890844526 IN IP6 2001:db8::3
s=
c=IN IP6 2001:db8::3
t=0 0
a=group:BUNDLE foo bar
m=audio 10000 RTP/AVP 0 8 97
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 10002 RTP/AVP 31 32
b=AS:1000
a=mid:bar
a=rtcp-mux
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec-sdp-oa-ans" title="Generating the SDP Answer" toc="default">
<t>
When an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group the following general
SDP grouping framework restrictions, defined in <xref target="RFC5888" pageno="false"
format="default"/>, also apply to the BUNDLE group:
<list style="symbols">
<t>
The answerer is only allowed to include a BUNDLE group in an initial BUNDLE answer if the offerer requested
the BUNDLE group to be created in the corresponding initial BUNDLE offer; and
</t>
<t>
The answerer is only allowed to include a BUNDLE group in a subsequent answer if the corresponding
subsequent offer contains a previously negotiated BUNDLE group; and
</t>
<t>
The answerer is only allowed to include a bundled "m=" section in an answer if the "m=" section was
indicated as bundled in the corresponding offer; and
</t>
<t>
The answerer is only allowed to include a bundled "m=" section in the same BUNDLE group as the bundled
"m=" line in the corresponding offer.
</t>
</list>
</t>
<t>
In addition, when an answerer generates an answer (initial BUNDLE answer or subsequent) that contains a BUNDLE group, the answerer MUST:
<list style="symbols">
<t>
In case of an initial BUNDLE answer, select the offerer tagged "m=" section using the procedures in <xref target="sec-sdp-oa-ans-off"
pageno="false" format="default"/>. In case of a subsequent answer, the offerer tagged "m=" section is indicated
in the corresponding subsequent offer, and MUST NOT be changed by the answerer; and
</t>
<t>
Select the answerer tagged "m=" section [<xref target="sec-sdp-oa-ans-off"
pageno="false" format="default"/>]; and
</t>
<t>
Assign the answerer BUNDLE address:port to the answerer tagged "m=" section; and
</t>
<t>
Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every
other bundled "m=" section within the BUNDLE group; and
</t>
<t>
Include SDP attributes in the bundled "m=" sections following the rules
in [<xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; and
</t>
<t>
Include an SDP 'group:BUNDLE' attribute in the answer; and
</t>
<t>
Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The answerer BUNDLE-tag
indicates the answerer tagged "m=" section [<xref target="sec-sdp-oa-ans-off"
pageno="false" format="default"/>].
</t>
</list>
</t>
<t>
If the answerer does not want to keep an "m=" section within a BUNDLE group, it MUST:
<list style="symbols">
<t>
Move the "m=" section out of the BUNDLE group [<xref target="sec-sdp-oa-ans-mov"
pageno="false" format="default"/>]; or
</t>
<t>
Reject the "m=" section [<xref target="sec-sdp-oa-ans-rej" pageno="false"
format="default"/>].
</t>
</list>
</t>
<t>
The answerer can modify the answerer BUNDLE address:port, add and remove SDP attributes, or modify
SDP attribute values, in a subsequent answer. Changes to the answerer BUNDLE address:port
and the answerer BUNDLE attributes will be applied to each bundled "m=" section within the BUNDLE group.
</t>
<t>
NOTE: If a bundled "m=" section in an offer contains a zero port value, but the "m=" section
does not contain an SDP 'bundle-only' attribute, it is an indication that the offerer wants
to disable the "m=" section [<xref target="sec-sdp-oa-mod-dis" pageno="false" format="default"/>].
</t>
<section title="Answerer Selection of tagged 'm=' sections" anchor="sec-sdp-oa-ans-off" toc="default">
<t>
When the answerer selects the offerer tagged "m=" section, it first checks the suggested
offerer tagged "m=" section [<xref target="sec-sdp-oa-ino-req" pageno="false" format="default"/>].
The answerer MUST check whether the "m=" section fulfils the following criteria:
<list style="symbols">
<t>
The answerer will not move the "m=" section out of the BUNDLE group
[<xref target="sec-sdp-oa-ans-mov" pageno="false" format="default"/>]; and
</t>
<t>
The answerer will not reject the "m=" section [<xref target="sec-sdp-oa-ans-rej"
pageno="false" format="default"/>]; and
</t>
<t>
The "m=" section does not contain a zero port value.
</t>
</list>
</t>
<t>
If all of the criteria above are fulfilled, the answerer MUST select
the "m=" section as the offerer tagged "m=" section, and MUST also mark
the corresponding "m=" section in the answer as the answerer tagged "m=" section.
In the answer the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
</t>
<t>
If one or more of the criteria are not fulfilled, the answerer MUST pick the next
identification-tag in the identification-tag list in the offer, and perform the same criteria
check for the "m=" section indicated by that identification-tag. If there are no
more identification-tags in the identification-tag list, the answerer MUST NOT
create the BUNDLE group. Unless the answerer rejects the whole offer,
the answerer MUST apply the answerer procedures for moving an "m=" section out of a
BUNDLE group [<xref target="sec-sdp-oa-ans-mov" pageno="false" format="default"/>] or
rejecting an "m=" section within a BUNDLE group [<xref target="sec-sdp-oa-ans-rej"
pageno="false" format="default"/>] to every bundled "m=" section in the offer when
creating the answer.
</t>
<t>
[<xref target="sec-example-add" pageno="false" format="default"/>] shows an
example of an offerer BUNDLE address:port selection.
</t>
<t>
[<xref target="sec-sdp-oa-ans-ex" pageno="false" format="default"/>] and
[<xref target="sec-example-add" pageno="false" format="default"/>] show an example of an
answerer tagged "m=" section selection.
</t>
</section>
<section title="Moving A Media Description Out Of A BUNDLE Group" anchor="sec-sdp-oa-ans-mov" toc="default">
<t>
When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of
the negotiated BUNDLE group, the answerer MUST first check the following criteria:
<list style="symbols">
<t>
In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group; and
</t>
<t>
In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute.
</t>
</list>
</t>
<t>
If either criterium above is fulfilled the answerer can not move the "m=" section out of
the BUNDLE group in the answer. The answerer can either reject the whole offer, reject each
bundled "m=" section within the BUNDLE group [<xref target="sec-sdp-oa-ans-rej" pageno="false" format="default"/>],
or keep the "m=" section within the BUNDLE group in the answer and later create an offer where
the "m=" section is moved out of the BUNDLE group [<xref target="sec-sdp-oa-mod-mov"
pageno="false" format="default"/>].
</t>
<t>
NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section
can not be moved out of the BUNDLE group in an answer. Instead an offer is needed.
</t>
<t>
When the answerer generates an answer, in which it moves a bundled "m=" section out
of a BUNDLE group, the answerer:
<list style="symbols">
<t>
MUST assign a unique address:port to the "m=" section; and
</t>
<t>
MUST include any applicable SDP attribute in the "m=" section, using the normal
offer/answer procedures for the each Attributes; and
</t>
<t>
MUST NOT place the identification-tag associated with the "m=" section in
the SDP 'group:BUNDLE' attribute identification-tag list associated with
the BUNDLE group.
</t>
<t>
MUST NOT include an SDP 'bundle-only' attribute to the "m=" section; and
</t>
</list>
</t>
<t>
Because an answerer is not allowed to move an "m=" section from one BUNDLE group to another within an answer
[<xref target="sec-sdp-oa-ans" pageno="false" format="default"/>], if
the answerer wants to move an "m=" section from one BUNDLE group to another it MUST first move the
"m=" section out of the current BUNDLE group, and then generate an offer where the "m=" section is
added to another BUNDLE group [<xref target="sec-sdp-oa-mod-add" pageno="false" format="default"/>].
</t>
</section>
<section title="Rejecting a Media Description in a BUNDLE Group" anchor="sec-sdp-oa-ans-rej" toc="default">
<t>
When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check
the following criterion:
<list style="symbols">
<t>
In the corresponding offer, the "m=" section is the offerer tagged "m=" section.
</t>
</list>
</t>
<t>
If the criterium above is fulfilled the answerer can not reject the "m=" section in
the answer. The answerer can either reject the whole offer, reject each bundled "m=" section
within the BUNDLE group, or keep the "m=" section within the BUNDLE group in the answer and later create
an offer where the "m=" section is disabled within the BUNDLE group [<xref target="sec-sdp-oa-mod-dis"
pageno="false" format="default"/>].
</t>
<t>
When an answerer generates an answer, in which it rejects a bundled "m=" section,
the answerer:
<list style="symbols">
<t>
MUST assign a zero port value to the "m=" section, according to the procedures in
<xref target="RFC3264" pageno="false" format="default"/>; and
</t>
<t>
MUST NOT place the identification-tag associated with the "m=" section in
the SDP 'group:BUNDLE' attribute identification-tag list associated with
the BUNDLE group; and
</t>
<t>
MUST NOT include an SDP 'bundle-only' attribute in the "m=" section.
</t>
</list>
</t>
</section>
<section title="Example: SDP Answer" anchor="sec-sdp-oa-ans-ex">
<t>
The example below shows an answer, based on the corresponding offer in
[<xref target="sec-sdp-oa-ino-ex" pageno="false" format="default"/>].
The answerer accepts both bundled "m=" sections within the created
BUNDLE group. The audio "m=" section is the answerer tagged "m=" section, indicated
by placing the identification-tag associated with the "m=" section
(answerer BUNDLE-tag) first in the SDP group;BUNDLE attribute
identification-id list. The answerer includes an SDP 'bundle-only'
attribute in, and assigns a zero port value to, the video "m=" section.
</t>
<figure>
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
SDP Answer
v=0
o=bob 2808844564 2808844564 IN IP6 2001:db8::1
s=
c=IN IP6 2001:db8::1
t=0 0
a=group:BUNDLE foo bar
m=audio 20000 RTP/AVP 0
b=AS:200
a=mid:foo
a=rtcp-mux
a=rtpmap:0 PCMU/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
m=video 0 RTP/AVP 32
b=AS:1000
a=mid:bar
a=bundle-only
a=rtpmap:32 MPV/90000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
]]></artwork>
</figure>
</section>
</section>
<section anchor="sec-sdp-oa-off-ans" title="Offerer Processing of the SDP Answer" toc="default">
<t>
When an offerer receives an answer, if the answer contains a BUNDLE group, the offerer
MUST check that any bundled "m=" section in the answer was indicated as bundled in the
corresponding offer. If there is no mismatch, the offerer MUST apply the properties (BUNDLE address:port,
BUNDLE attributes etc) of the offerer tagged "m=" section (selected by the answerer
[<xref format="default" pageno="false" target="sec-sdp-oa-ans-off"/>]) to each bundled "m=" section
within the BUNDLE group.
</t>
<t>
NOTE: As the answerer might reject one or more bundled "m=" sections in an initial BUNDLE offer,
or move a bundled "m=" section out of a BUNDLE group, a given bundled "m=" section in the
offer might not be indicated as bundled in the corresponding answer.
</t>
<t>
If the answer does not contain a BUNDLE group, the offerer MUST process the answer
as a normal answer.
</t>
</section>
<section title="Modifying the Session" anchor="sec-sdp-oa-mod" toc="default">
<t>
When a BUNDLE group has previously been negotiated, and an offerer generates a subsequent
offer, the offerer MUST:
<list style="symbols">
<t>
Pick one bundled "m=" section as the offerer tagged "m=" section. The offerer
can either pick the "m=" section that was previously selected by the answerer
as the offerer tagged "m=" section, or pick another bundled "m=" section within the
BUNDLE group; and
</t>
<t>
Assign a BUNDLE address:port (previously negotiated or newly suggest) to
the offerer tagged "m=" section; and
</t>
<t>
Include an SDP 'bundle-only' attribute in, and assign a zero port value to, every
other bundled "m=" section within the BUNDLE group; and
</t>
<t>
Include SDP attributes in the bundled "m=" sections following the rules in
[<xref target="sec-sdp-oa-cat" pageno="false" format="default"/>]; and
</t>
<t>
Include an SDP 'group:BUNDLE' attribute in the offer; and
</t>
<t>
Place the identification-tag of each bundled "m=" section in the
SDP 'group:BUNDLE' attribute identification-tag list. The offerer BUNDLE-tag
indicates the offerer tagged "m=" section.
</t>
</list>
</t>
<t>
The offerer MUST NOT pick a given bundled "m=" section as the offerer tagged "m=" section if:
<list style="symbols">
<t>
The offerer wants to move the "m=" section out of the BUNDLE group
[<xref target="sec-sdp-oa-mod-mov" pageno="false" format="default"/>]; or
</t>
<t>
The offerer wants to disable the "m=" section [<xref format="default"
pageno="false" target="sec-sdp-oa-mod-dis"/>].
</t>
</list>
</t>
<t>
The offerer can modify the offerer BUNDLE address:port, add and remove SDP attributes, or modify
SDP attribute values, in the subsequent offer. Changes to the offerer BUNDLE address:port and the
offerer BUNDLE attributes will (if the offer is accepted by the answerer) be applied to each
bundled "m=" section within the BUNDLE group.
</t>
<section title="Adding a Media Description to a BUNDLE group" anchor="sec-sdp-oa-mod-add" toc="default">
<t>
When an offerer generates a subsequent offer, in which it wants to add a bundled "m=" section to
a previously negotiated BUNDLE group, the offerer follows the procedures in <xref target="sec-sdp-oa-mod"
pageno="false" format="default"/>. The offerer either picks the added "m=" section, or an "m=" section
previously added to the BUNDLE group, as the offerer tagged "m=" section.
</t>
<t>
NOTE: As described in <xref target="sec-sdp-oa-ans-mov" pageno="false" format="default"/>, the answerer can not move the added "m=" section
out of the BUNDLE group in its answer. If the answer wants to move the "m=" section out of the BUNDLE group, it will have to first accept
it into the BUNDLE group in the answer, and then send a subsequent offer where the "m=" section is moved out of the BUNDLE group
[<xref target="sec-sdp-oa-mod-mov" pageno="false" format="default"/>].
</t>
</section>
<section title="Moving a Media Description Out of a BUNDLE Group" anchor="sec-sdp-oa-mod-mov" toc="default">
<t>
When an offerer generates a subsequent offer, in which it want to remove a bundled "m=" section from