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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
|
<pre>Internet Engineering Task Force (IETF) G. Camarillo
Request for Comments: 5888 Ericsson
Obsoletes: <a href="./rfc3388">3388</a> H. Schulzrinne
Category: Standards Track Columbia University
ISSN: 2070-1721 June 2010
<span class="h1">The Session Description Protocol (SDP) Grouping Framework</span>
Abstract
In this specification, we define a framework to group "m" lines in
the Session Description Protocol (SDP) for different purposes. This
framework uses the "group" and "mid" SDP attributes, both of which
are defined in this specification. Additionally, we specify how to
use the framework for two different purposes: for lip synchronization
and for receiving a media flow consisting of several media streams on
different transport addresses. This document obsoletes <a href="./rfc3388">RFC 3388</a>.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5888">http://www.rfc-editor.org/info/rfc5888</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Overview of Operation . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Media Stream Identification Attribute . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Group Attribute . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Use of "group" and "mid" . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-7">7</a>. Lip Synchronization (LS) . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-7.1">7.1</a>. Example of LS . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-8">8</a>. Flow Identification (FID) . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8.1">8.1</a>. SIP and Cellular Access . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8.2">8.2</a>. DTMF Tones . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.3">8.3</a>. Media Flow Definition . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.4">8.4</a>. FID Semantics . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-8.4.1">8.4.1</a>. Examples of FID . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8.5">8.5</a>. Scenarios That FID Does Not Cover . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.5.1">8.5.1</a>. Parallel Encoding Using Different Codecs . . . . . . . <a href="#page-11">11</a>
<a href="#section-8.5.2">8.5.2</a>. Layered Encoding . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-8.5.3">8.5.3</a>. Same IP Address and Port Number . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-9">9</a>. Usage of the "group" Attribute in SIP . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9.1">9.1</a>. Mid Value in Answers . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-9.1.1">9.1.1</a>. Example . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-9.2">9.2</a>. Group Value in Answers . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9.2.1">9.2.1</a>. Example . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9.3">9.3</a>. Capability Negotiation . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9.3.1">9.3.1</a>. Example . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9.4">9.4</a>. Backward Compatibility . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-9.4.1">9.4.1</a>. Offerer Does Not Support "group" . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-9.4.2">9.4.2</a>. Answerer Does Not Support "group" . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-10">10</a>. Changes from <a href="./rfc3388">RFC 3388</a> . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-11">11</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-12">12</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-13">13</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-14">14</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-14.1">14.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-14.2">14.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="./rfc3388">RFC 3388</a> [<a href="./rfc3388" title=""Grouping of Media Lines in the Session Description Protocol (SDP)"">RFC3388</a>] specified a media-line grouping framework for SDP
[<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>]. This specification obsoletes <a href="./rfc3388">RFC 3388</a> [<a href="./rfc3388" title=""Grouping of Media Lines in the Session Description Protocol (SDP)"">RFC3388</a>].
An SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] session description typically contains one or more
media lines, which are commonly known as "m" lines. When a session
description contains more than one "m" line, SDP does not provide any
means to express a particular relationship between two or more of
them. When an application receives an SDP session description with
more than one "m" line, it is up to the application to determine what
to do with them. SDP does not carry any information about grouping
media streams.
While in some environments this information can be carried out of
band, it is necessary to have a mechanism in SDP to express how
different media streams within a session description relate to each
other. The framework defined in this specification is such a
mechanism.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Overview of Operation</span>
This section provides a non-normative description of how the SDP
Grouping Framework defined in this document works. In a given
session description, each "m" line is identified by a token, which is
carried in a "mid" attribute below the "m" line. The session
description carries session-level "group" attributes that group
different "m" lines (identified by their tokens) using different
group semantics. The semantics of a group describe the purpose for
which the "m" lines are grouped. For example, the "group" line in
the session description below indicates that the "m" lines identified
by tokens 1 and 2 (the audio and the video "m" lines, respectively)
are grouped for the purpose of lip synchronization (LS).
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Media Stream Identification Attribute</span>
This document defines the "media stream identification" media
attribute, which is used for identifying media streams within a
session description. Its formatting in SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] is described by
the following Augmented Backus-Naur Form (ABNF) [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]:
mid-attribute = "a=mid:" identification-tag
identification-tag = token
; token is defined in <a href="./rfc4566">RFC 4566</a>
The identification-tag MUST be unique within an SDP session
description.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Group Attribute</span>
This document defines the "group" session-level attribute, which is
used for grouping together different media streams. Its formatting
in SDP is described by the following ABNF [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]:
group-attribute = "a=group:" semantics
*(SP identification-tag)
semantics = "LS" / "FID" / semantics-extension
semantics-extension = token
; token is defined in <a href="./rfc4566">RFC 4566</a>
This document defines two standard semantics: Lip Synchronization
(LS) and Flow Identification (FID). Semantics extensions follow the
Standards Action policy [<a href="./rfc5226" title="">RFC5226</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Use of "group" and "mid"</span>
All of the "m" lines of a session description that uses "group" MUST
be identified with a "mid" attribute whether they appear in the group
line(s) or not. If a session description contains at least one "m"
line that has no "mid" identification, the application MUST NOT
perform any grouping of media lines.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
"a=group" lines are used to group together several "m" lines that are
identified by their "mid" attribute. "a=group" lines that contain
identification-tags that do not correspond to any "m" line within the
session description MUST be ignored. The application acts as if the
"a=group" line did not exist. The behavior of an application
receiving an SDP description with grouped "m" lines is defined by the
semantics field in the "a=group" line.
There MAY be several "a=group" lines in a session description. The
"a=group" lines of a session description can use the same or
different semantics. An "m" line identified by its "mid" attribute
MAY appear in more than one "a=group" line.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Lip Synchronization (LS)</span>
An application that receives a session description that contains "m"
lines that are grouped together using LS semantics MUST synchronize
the playout of the corresponding media streams. Note that LS
semantics apply not only to a video stream that has to be
synchronized with an audio stream; the playout of two streams of the
same type can be synchronized as well.
For RTP streams, synchronization is typically performed using the RTP
Control Protocol (RTCP), which provides enough information to map
time stamps from the different streams into a local absolute time
value. However, the concept of media stream synchronization MAY also
apply to media streams that do not make use of RTP. If this is the
case, the application MUST recover the original timing relationship
between the streams using whatever mechanism is available.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Example of LS</span>
The following example shows a session description of a conference
that is being multicast. The first media stream (mid:1) contains the
voice of the speaker who speaks in English. The second media stream
(mid:2) contains the video component, and the third (mid:3) media
stream carries the translation to Spanish of what she is saying. The
first and second media streams have to be synchronized.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
c=IN IP4 233.252.0.1/127
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3
Note that although the third media stream is not present in the group
line, it still has to contain a "mid" attribute (mid:3), as stated
before.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Flow Identification (FID)</span>
An "m" line in an SDP session description defines a media stream.
However, SDP does not define what a media stream is. This definition
can be found in the Real Time Streaming Protocol (RTSP)
specification. The RTSP RFC [<a href="./rfc2326" title=""Real Time Streaming Protocol (RTSP)"">RFC2326</a>] defines a media stream as "a
single media instance, e.g., an audio stream or a video stream as
well as a single whiteboard or shared application group. When using
RTP, a stream consists of all RTP and RTCP packets created by a
source within an RTP session".
This definition assumes that a single audio (or video) stream maps
into an RTP session. The RTP RFC [<a href="./rfc1889" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC1889</a>] (at present obsoleted by
[<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]) used to define an RTP session as follows: "For each
participant, the session is defined by a particular pair of
destination transport addresses (one network address plus a port pair
for RTP and RTCP)".
While the previous definitions cover the most common cases, there are
situations where a single media instance (e.g., an audio stream or a
video stream) is sent using more than one RTP session. Two examples
(among many others) of this kind of situation are cellular systems
using the Session Initiation Protocol (SIP; [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>]) and systems
receiving Dual-Tone Multi-Frequency (DTMF) tones on a different host
than the voice.
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. SIP and Cellular Access</span>
Systems using a cellular access and SIP as a signalling protocol need
to receive media over the air. During a session, the media can be
encoded using different codecs. The encoded media has to traverse
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
the radio interface. The radio interface is generally characterized
as being prone to bit errors and associated with relatively high
packet transfer delays. In addition, radio interface resources in a
cellular environment are scarce and thus expensive, which calls for
special measures in providing a highly efficient transport. In order
to get an appropriate speech quality in combination with an efficient
transport, precise knowledge of codec properties is required so that
a proper radio bearer for the RTP session can be configured before
transferring the media. These radio bearers are dedicated bearers
per media type (i.e., codec).
Cellular systems typically configure different radio bearers on
different port numbers. Therefore, incoming media has to have
different destination port numbers for the different possible codecs
in order to be routed properly to the correct radio bearer. Thus,
this is an example in which several RTP sessions are used to carry a
single media instance (the encoded speech from the sender).
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. DTMF Tones</span>
Some voice sessions include DTMF tones. Sometimes, the voice
handling is performed by a different host than the DTMF handling. It
is common to have an application server in the network gathering DTMF
tones for the user while the user receives the encoded speech on his
user agent. In this situation, it is necessary to establish two RTP
sessions: one for the voice and the other for the DTMF tones. Both
RTP sessions are logically part of the same media instance.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Media Flow Definition</span>
The previous examples show that the definition of a media stream in
[<a href="./rfc2326" title=""Real Time Streaming Protocol (RTSP)"">RFC2326</a>] does not cover some scenarios. It cannot be assumed that a
single media instance maps into a single RTP session. Therefore, we
introduce the definition of a media flow:
A media flow consists of a single media instance, e.g., an audio
stream or a video stream as well as a single whiteboard or shared
application group. When using RTP, a media flow comprises one or
more RTP sessions.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. FID Semantics</span>
Several "m" lines grouped together using FID semantics form a media
flow. A media agent handling a media flow that comprises several "m"
lines MUST send a copy of the media to every "m" line that is part of
the flow as long as the codecs and the direction attribute present in
a particular "m" line allow it.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
It is assumed that the application uses only one codec at a time to
encode the media produced. This codec MAY change dynamically during
the session, but at any particular moment, only one codec is in use.
The application encodes the media using the current codec and checks,
one by one, all of the "m" lines that are part of the flow. If a
particular "m" line contains the codec being used and the direction
attribute is "sendonly" or "sendrecv", a copy of the encoded media is
sent to the address/port specified in that particular media stream.
If either the "m" line does not contain the codec being used or the
direction attribute is neither "sendonly" nor "sendrecv", nothing is
sent over this media stream.
The application typically ends up sending media to different
destinations (IP address/port number) depending on the codec used at
any moment.
<span class="h4"><a class="selflink" id="section-8.4.1" href="#section-8.4.1">8.4.1</a>. Examples of FID</span>
The session description below might be sent by a SIP user agent using
a cellular access. The user agent supports GSM (Global System for
Mobile communications) on port 30000 and AMR (Adaptive Multi-Rate) on
port 30002. When the remote party sends GSM, it will send RTP
packets to port number 30000. When AMR is the codec chosen, packets
will be sent to port 30002. Note that the remote party can switch
between both codecs dynamically in the middle of the session.
However, in this example, only one media stream at a time carries
voice. The other remains "muted" while its corresponding codec is
not in use.
v=0
o=Laura 289083124 289083124 IN IP4 three.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
(The linebreak in the fmtp line accommodates RFC formatting
restrictions; SDP does not have continuation lines.)
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
In the previous example, a system receives media on the same IP
address on different port numbers. The following example shows how a
system can receive different codecs on different IP addresses.
v=0
o=Laura 289083124 289083124 IN IP4 four.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.2
a=rtpmap:0 PCMU/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
(The linebreak in the fmtp line accommodates RFC formatting
restrictions; SDP does not have continuation lines.)
The cellular terminal in this example only supports the AMR codec.
However, many current IP phones only support PCM (Pulse-Code
Modulation; payload 0). In order to be able to interoperate with
them, the cellular terminal uses a transcoder whose IP address is
192.0.2.2. The cellular terminal includes the transcoder IP address
in its SDP description to provide support for PCM. Remote systems
will send AMR directly to the terminal, but PCM will be sent to the
transcoder. The transcoder will be configured (using whatever method
is preferred) to convert the incoming PCM audio to AMR and send it to
the terminal.
The next example shows how the "group" attribute used with FID
semantics can indicate the use of two different codecs in the two
directions of a bidirectional media stream.
v=0
o=Laura 289083124 289083124 IN IP4 five.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=recvonly
a=mid:2
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
A user agent that receives the SDP description above knows that, at a
certain moment, it can send either PCM u-law to port number 30000 or
PCM A-law to port number 30002. However, the media agent also knows
that the other end will only send PCM u-law (payload 0).
The following example shows a session description with different "m"
lines grouped together using FID semantics that contain the same
codec.
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 20000 RTP/AVP 0 8
c=IN IP4 192.0.2.2
a=recvonly
a=mid:3
At a particular point in time, if the media agent receiving the SDP
message above is sending PCM u-law (payload 0), it sends RTP packets
to 192.0.2.1 on port 30000 and to 192.0.2.2 on port 20000 (first and
third "m" lines). If it is sending PCM A-law (payload 8), it sends
RTP packets to 192.0.2.1 on port 30002 and to 192.0.2.2 on port 20000
(second and third "m" lines).
The system that generated the SDP description above supports PCM
u-law on port 30000 and PCM A-law on port 30002. Besides, it uses an
application server that records the conversation and whose IP address
is 192.0.2.2. The application server does not need to understand the
media content, so it always receives a copy of the media stream,
regardless of the codec and payload type that is being used. That is
why the application server always receives a copy of the audio stream
regardless of the codec being used at any given moment (it actually
performs an RTP dump, so it can effectively receive any codec).
Remember that if several "m" lines that are grouped together using
the FID semantics contain the same codec, the media agent MUST send
copies of the same media stream as several RTP sessions at the same
time.
The last example in this section deals with DTMF tones. DTMF tones
can be transmitted using a regular voice codec or can be transmitted
as telephony events. The RTP payload for DTMF tones treated as
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
telephone events is described in [<a href="./rfc4733" title=""RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"">RFC4733</a>]. Below, there is an
example of an SDP session description using FID semantics and this
payload type.
v=0
o=Laura 289083124 289083124 IN IP4 seven.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 192.0.2.2
a=rtpmap:97 telephone-events
a=mid:2
The remote party would send PCM encoded voice (payload 0) to
192.0.2.1 and DTMF tones encoded as telephony events to 192.0.2.2.
Note that only voice or DTMF is sent at a particular point in time.
When DTMF tones are sent, the first media stream does not carry any
data and, when voice is sent, there is no data in the second media
stream. FID semantics provide different destinations for alternative
codecs.
<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>. Scenarios That FID Does Not Cover</span>
It is worthwhile mentioning some scenarios where the "group"
attribute using existing semantics (particularly FID) might seem to
be applicable but is not.
<span class="h4"><a class="selflink" id="section-8.5.1" href="#section-8.5.1">8.5.1</a>. Parallel Encoding Using Different Codecs</span>
FID semantics are useful when the application only uses one codec at
a time. An application that encodes the same media using different
codecs simultaneously MUST NOT use FID to group those media lines.
Some systems that handle DTMF tones are a typical example of parallel
encoding using different codecs. Some systems implement the RTP
payload defined in <a href="./rfc4733">RFC 4733</a> [<a href="./rfc4733" title=""RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals"">RFC4733</a>], but when they send DTMF tones,
they do not mute the voice channel. Therefore, in effect they are
sending two copies of the same DTMF tone: encoded as voice and
encoded as a telephony event. When the receiver gets both copies, it
typically uses the telephony event rather than the tone encoded as
voice. FID semantics MUST NOT be used in this context to group both
media streams, since such a system is not using alternative codecs
but rather different parallel encodings for the same information.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
<span class="h4"><a class="selflink" id="section-8.5.2" href="#section-8.5.2">8.5.2</a>. Layered Encoding</span>
Layered encoding schemes encode media in different layers. The
quality of the media stream at the receiver varies depending on the
number of layers received. SDP provides a means to group together
contiguous multicast addresses that transport different layers. The
"c" line below:
c=IN IP4 233.252.0.1/127/3
is equivalent to the following three "c" lines:
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127
FID MUST NOT be used to group "m" lines that do not represent the
same information. Therefore, FID MUST NOT be used to group "m" lines
that contain the different layers of layered encoding schemes.
Besides, we do not define new group semantics to provide a more
flexible way of grouping different layers, because the already
existing SDP mechanism covers the most useful scenarios. Since the
existing SDP mechanism already covers the most useful scenarios, we
do not define a new group semantics to define a more flexible way of
grouping different layers.
<span class="h4"><a class="selflink" id="section-8.5.3" href="#section-8.5.3">8.5.3</a>. Same IP Address and Port Number</span>
If media streams using several different codecs have to be sent to
the same IP address and port, the traditional SDP syntax of listing
several codecs in the same "m" line MUST be used. FID MUST NOT be
used to group "m" lines with the same IP address/port. Therefore, an
SDP description like the one below MUST NOT be generated.
v=0
o=Laura 289083124 289083124 IN IP4 eight.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 8
a=mid:2
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
The correct SDP description for the session above would be the
following one:
v=0
o=Laura 289083124 289083124 IN IP4 nine.example.com
c=IN IP4 192.0.2.1
t=0 0
m=audio 30000 RTP/AVP 0 8
If two "m" lines are grouped using FID, they MUST differ in their
transport addresses (i.e., IP address plus port).
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Usage of the "group" Attribute in SIP</span>
SDP descriptions are used by several different protocols, SIP among
them. We include a section about SIP, because the "group" attribute
will most likely be used mainly by SIP systems.
SIP [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>] is an application layer protocol for establishing,
terminating, and modifying multimedia sessions. SIP carries session
descriptions in the bodies of the SIP messages but is independent
from the protocol used for describing sessions. SDP [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] is one
of the protocols that can be used for this purpose.
At session establishment, SIP provides a three-way handshake
(INVITE-200 OK-ACK) between end systems. However, just two of these
three messages carry SDP, as described in [<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>].
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Mid Value in Answers</span>
The "mid" attribute is an identifier for a particular media stream.
Therefore, the "mid" value in the offer MUST be the same as the "mid"
value in the answer. Besides, subsequent offers (e.g., in a
re-INVITE) SHOULD use the same "mid" value for the already existing
media streams.
[<a id="ref-RFC3264">RFC3264</a>] describes the usage of SDP in text of SIP. The offerer and
the answerer align their media description so that the nth media
stream ("m=" line) in the offerer's session description corresponds
to the nth media stream in the answerer's description.
The presence of the "group" attribute in an SDP session description
does not modify this behavior.
Since the "mid" attribute provides a means to label "m" lines, it
would be possible to perform media alignment using "mid" labels
rather than matching nth "m" lines. However, this would not bring
any gain and would add complexity to implementations. Therefore, SIP
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
systems MUST perform media alignment matching nth lines regardless of
the presence of the "group" or "mid" attributes.
If a media stream that contained a particular "mid" identifier in the
offer contains a different identifier in the answer, the application
ignores all of the "mid" and "group" lines that might appear in the
session description. The following example illustrates this
scenario.
<span class="h4"><a class="selflink" id="section-9.1.1" href="#section-9.1.1">9.1.1</a>. Example</span>
Two SIP entities exchange SDPs during session establishment. The
INVITE contains the SDP description below:
v=0
o=Laura 289083124 289083124 IN IP4 ten.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2
m=audio 30000 RTP/AVP 0 8
a=mid:1
m=audio 30002 RTP/AVP 0 8
a=mid:2
The 200 OK response contains the following SDP description:
v=0
o=Bob 289083122 289083122 IN IP4 eleven.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8
a=mid:2
m=audio 25002 RTP/AVP 0 8
a=mid:1
Since alignment of "m" lines is performed based on matching of nth
lines, the first stream had "mid:1" in the INVITE and "mid:2" in the
200 OK. Therefore, the application ignores every "mid" and "group"
line contained in the SDP description.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
A well-behaved SIP user agent would have returned the SDP description
below in the 200 OK response.
v=0
o=Bob 289083122 289083122 IN IP4 twelve.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:2
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Group Value in Answers</span>
A SIP entity that receives an offer that contains an "a=group" line
with semantics that it does not understand MUST return an answer
without the "group" line. Note that, as described in the previous
section, the "mid" lines MUST still be present in the answer.
A SIP entity that receives an offer that contains an "a=group" line
with semantics that are understood MUST return an answer that
contains an "a=group" line with the same semantics. The
identification-tags contained in this "a=group" line MUST be the same
as those received in the offer, or a subset of them (zero
identification-tags is a valid subset). When the identification-tags
in the answer are a subset, the "group" value to be used in the
session MUST be the one present in the answer.
SIP entities refuse media streams by setting the port to zero in the
corresponding "m" line. "a=group" lines MUST NOT contain
identification-tags that correspond to "m" lines with the port set to
zero.
Note that grouping of "m" lines MUST always be requested by the
offerer, but never by the answerer. Since SIP provides a two-way SDP
exchange, an answerer that requested grouping would not know whether
the "group" attribute was accepted by the offerer or not. An
answerer that wants to group media lines issues another offer after
having responded to the first one (in a re-INVITE, for instance).
<span class="h4"><a class="selflink" id="section-9.2.1" href="#section-9.2.1">9.2.1</a>. Example</span>
The example below shows how the callee refuses a media stream offered
by the caller by setting its port number to zero. The "mid" value
corresponding to that media stream is removed from the "group" value
in the answer.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
SDP description in the INVITE from caller to callee:
v=0
o=Laura 289083124 289083124 IN IP4 thirteen.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 30004 RTP/AVP 3
a=mid:3
SDP description in the INVITE from callee to caller:
v=0
o=Bob 289083125 289083125 IN IP4 fourteen.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:FID 1 3
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 0 RTP/AVP 8
a=mid:2
m=audio 20002 RTP/AVP 3
a=mid:3
<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>. Capability Negotiation</span>
A client that understands "group" and "mid", but does not want to use
these SDP features in a particular session, may still want to
indicate that it supports these features. To indicate this support,
a client can add an "a=3Dgroup" line with no identification-tags for
every semantics value it understands.
If a server receives an offer that contains empty "a=group" lines, it
SHOULD add its capabilities also in the form of empty "a=group" lines
to its answer.
<span class="h4"><a class="selflink" id="section-9.3.1" href="#section-9.3.1">9.3.1</a>. Example</span>
A system that supports both LS and FID semantics but does not want to
group any media stream for this particular session generates the
following SDP description:
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
v=0
o=Bob 289083125 289083125 IN IP4 fifteen.example.com
c=IN IP4 192.0.2.3
t=0 0
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8
The server that receives that offer supports FID but not LS. It
responds with the SDP description below:
v=0
o=Laura 289083124 289083124 IN IP4 sixteen.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:FID
m=audio 30000 RTP/AVP 0
<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>. Backward Compatibility</span>
This document does not define any SIP "Require" header field.
Therefore, if one of the SIP user agents does not understand the
"group" attribute, the standard SDP fall-back mechanism MUST be used,
namely, attributes that are not understood are simply ignored.
<span class="h4"><a class="selflink" id="section-9.4.1" href="#section-9.4.1">9.4.1</a>. Offerer Does Not Support "group"</span>
This situation does not represent a problem, because grouping
requests are always performed by offerers and not by answerers. If
the offerer does not support "group", this attribute will simply not
be used.
<span class="h4"><a class="selflink" id="section-9.4.2" href="#section-9.4.2">9.4.2</a>. Answerer Does Not Support "group"</span>
The answerer will ignore the "group" attribute since it does not
understand it and will also ignore the "mid" attribute. For LS
semantics, the answerer might decide to perform, or not to perform,
synchronization between media streams.
For FID semantics, the answerer will consider the session to consist
of several media streams.
Different implementations will behave in different ways.
In the case of audio and different "m" lines for different codecs, an
implementation might decide to act as a mixer with the different
incoming RTP sessions, which is the correct behavior.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
An implementation might also decide to refuse the request (e.g., 488
Not Acceptable Here, or 606 Not Acceptable), because it contains
several "m" lines. In this case, the server does not support the
type of session that the caller wanted to establish. In case the
client is willing to establish a simpler session anyway, the client
can re-try the request without the "group" attribute and with only
one "m" line per flow.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Changes from <a href="./rfc3388">RFC 3388</a></span>
<a href="#section-3">Section 3</a> (Overview of Operation) has been added for clarity. The
AMR and GSM acronyms are now expanded on their first use. The
examples now use IP addresses in the range suitable for examples.
The grouping mechanism is now defined as an extensible framework.
Earlier, <a href="./rfc3388">RFC 3388</a> [<a href="./rfc3388" title=""Grouping of Media Lines in the Session Description Protocol (SDP)"">RFC3388</a>] used to discourage extensions to this
mechanism in favor of using new session description protocols.
Given a semantics value, <a href="./rfc3388">RFC 3388</a> [<a href="./rfc3388" title=""Grouping of Media Lines in the Session Description Protocol (SDP)"">RFC3388</a>] used to restrict "m" line
identifiers to only appear in a single group using that semantics.
That restriction has been lifted in this specification. From
conversations with implementers, existing (i.e., legacy)
implementations enforce this restriction on a per-semantics basis.
That is, they only enforce this restriction for supported semantics.
Because of the nature of existing semantics, implementations will
only use a single "m" line identifier across groups using a given
semantics even after the restriction has been lifted by this
specification. Consequently, the lifting of this restriction will
not cause backward-compatibility problems, because implementations
supporting new semantics will be updated to not enforce this
restriction at the same time as they are updated to support the new
semantics.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Security Considerations</span>
Using the "group" parameter with FID semantics, an entity that
managed to modify the session descriptions exchanged between the
participants to establish a multimedia session could force the
participants to send a copy of the media to any destination of its
choosing.
Integrity mechanisms provided by protocols used to exchange session
descriptions and media encryption can be used to prevent this attack.
In SIP, Secure/Multipurpose Internet Mail Extensions (S/MIME)
[<a href="./rfc5750" title=""Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling"">RFC5750</a>] and Transport Layer Security (TLS) [<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] can be used to
protect session description exchanges in an end-to-end and a hop-by-
hop fashion, respectively.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. IANA Considerations</span>
This document defines two SDP attributes: "mid" and "group".
The "mid" attribute is used to identify media streams within a
session description, and its format is defined in <a href="#section-4">Section 4</a>.
The "group" attribute is used for grouping together different media
streams, and its format is defined in <a href="#section-5">Section 5</a>.
This document defines a framework to group media lines in SDP using
different semantics. Semantics values to be used with this framework
are registered by the IANA following the Standards Action policy
[<a href="./rfc5226" title="">RFC5226</a>].
The IANA Considerations section of the RFC MUST include the following
information, which appears in the IANA registry along with the RFC
number of the publication.
o A brief description of the semantics.
o Token to be used within the "group" attribute. This token may be
of any length, but SHOULD be no more than four characters long.
o Reference to a standards track RFC.
The following are the current entries in the registry:
Semantics Token Reference
--------------------------------- ----- -----------
Lip Synchronization LS [<a href="./rfc5888">RFC5888</a>]
Flow Identification FID [<a href="./rfc5888">RFC5888</a>]
Single Reservation Flow SRF [<a href="./rfc3524">RFC3524</a>]
Alternative Network Address Types ANAT [<a href="./rfc4091">RFC4091</a>]
Forward Error Correction FEC [<a href="./rfc4756">RFC4756</a>]
Decoding Dependency DDP [<a href="./rfc5583">RFC5583</a>]
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Acknowledgments</span>
Goran Eriksson and Jan Holler were coauthors of <a href="./rfc3388">RFC 3388</a> [<a href="./rfc3388" title=""Grouping of Media Lines in the Session Description Protocol (SDP)"">RFC3388</a>].
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. References</span>
<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
June 2002.
[<a id="ref-RFC3264">RFC3264</a>] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", <a href="./rfc3264">RFC 3264</a>,
June 2002.
[<a id="ref-RFC4566">RFC4566</a>] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", <a href="./rfc4566">RFC 4566</a>, July 2006.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-RFC5246">RFC5246</a>] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.
[<a id="ref-RFC5750">RFC5750</a>] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", <a href="./rfc5750">RFC 5750</a>, January 2010.
<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>. Informative References</span>
[<a id="ref-RFC1889">RFC1889</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", <a href="./rfc1889">RFC 1889</a>, January 1996.
[<a id="ref-RFC2326">RFC2326</a>] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", <a href="./rfc2326">RFC 2326</a>, April 1998.
[<a id="ref-RFC3388">RFC3388</a>] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", <a href="./rfc3388">RFC 3388</a>, December 2002.
<span class="grey">Camarillo & Schulzrinne Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5888">RFC 5888</a> SDP Grouping Framework June 2010</span>
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC4733">RFC4733</a>] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
Digits, Telephony Tones, and Telephony Signals", <a href="./rfc4733">RFC 4733</a>,
December 2006.
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
FINLAND
EMail: Gonzalo.Camarillo@ericsson.com
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Camarillo & Schulzrinne Standards Track [Page 21]
</pre>
|
