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>Network Working Group Y. Hiwasaki
Request for Comments: 5686 H. Ohmuro
Category: Standards Track NTT Corporation
October 2009
<span class="h1">RTP Payload Format for mU-law EMbedded Codec for Low-delay IP</span>
<span class="h1">Communication (UEMCLIP) Speech Codec</span>
Abstract
This document describes the RTP payload format of a mU-law EMbedded
Coder for Low-delay IP communication (UEMCLIP), an enhanced speech
codec of ITU-T G.711. The bitstream has a scalable structure with an
embedded u-law bitstream, also known as PCMU, thus providing a handy
transcoding operation between narrowband and wideband speech.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Media Format Background .........................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Payload Format ..................................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. RTP Header Usage ...........................................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Multiple Frames in an RTP Packet ...........................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Payload Data ...............................................<a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. Main Header .........................................<a href="#page-7">7</a>
<a href="#section-3.3.2">3.3.2</a>. Sub-Layer ..........................................<a href="#page-10">10</a>
<a href="#section-4">4</a>. Transcoding between UEMCLIP and G.711 ..........................<a href="#page-11">11</a>
<a href="#section-5">5</a>. Congestion Control Considerations ..............................<a href="#page-12">12</a>
<a href="#section-6">6</a>. Payload Format Parameters ......................................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Media Type Registration ...................................<a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Mapping to SDP Parameters .................................<a href="#page-14">14</a>
<a href="#section-6.2.1">6.2.1</a>. Mode Specification .................................<a href="#page-15">15</a>
<a href="#section-6.3">6.3</a>. Offer-Answer Model Considerations .........................<a href="#page-16">16</a>
<a href="#section-6.3.1">6.3.1</a>. Offer-Answer Guidelines ............................<a href="#page-16">16</a>
<a href="#section-6.3.2">6.3.2</a>. Examples ...........................................<a href="#page-17">17</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-19">19</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-19">19</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-19">19</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-19">19</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-20">20</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies the payload format for sending UEMCLIP-
encoded (mU-law EMbedded Coder for Low-delay IP communication) speech
using the Real-time Transport Protocol (RTP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. UEMCLIP is a
proprietary codec that enhances u-law ITU-T G.711 [<a href="#ref-ITU-T-G.711">ITU-T-G.711</a>] and
that is designed to help the market for smooth transition towards the
forthcoming wideband communication environment while achieving a very
small media transcoding load with the existing terminals, in which
the implementation of G.711 is mandatory.
It should be noted that, generally speaking, codecs are negotiated
and changed using an SDP exchange. Also, [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] defines general
RTP mixer and translator models, where media transcoding may not take
place at the node. For those cases, the design concept of the
embedded structure is not useful. However, there are other cases
when costly transcoding is unavoidable in commonly deployed types of
Multi-point Control Units (MCUs), which terminate media and RTCP
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
packets [<a href="./rfc5117" title=""RTP Topologies"">RFC5117</a>], and when narrowband and wideband terminals
coexist. This embedded bitstream structure can reduce the media
transcoding to a simple bitstream truncation.
The background and the basic idea of the media format is described in
<a href="#section-2">Section 2</a>. The details of the payload format are given in <a href="#section-3">Section 3</a>.
The transcoding issues with G.711 are discussed in <a href="#section-4">Section 4</a>, and the
considerations for congestion control are in Section 5. In
<a href="#section-6">Section 6</a>, the payload format parameters for a media type
registration for UEMCLIP RTP payload format and Session Description
Protocol (SDP) mappings are provided. The security considerations
and IANA considerations are dealt with in <a href="#section-7">Section 7</a> and <a href="#section-8">Section 8</a>,
respectively.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</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-2" href="#section-2">2</a>. Media Format Background</span>
UEMCLIP is an enhanced version of u-law ITU-T G.711, otherwise known
as PCMU [<a href="./rfc4856" title=""Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences"">RFC4856</a>]. It is targeted at Voice over Internet Protocol
(VoIP) applications, and its main goal is to provide a wideband
communication platform that is highly interoperable with existing
terminals equipped with G.711 and to stimulate the market to
gradually shift to using wideband communication. In widely deployed
multi-point conferencing systems, the packets usually go through
RTCP-terminating (RTP Control Protocol) MCUs, "Topo-RTCP-terminating-
MCU" as defined in [<a href="./rfc5117" title=""RTP Topologies"">RFC5117</a>]. Because the G.711 bitstream is
embedded in the bitstream, costly media transcoding can be avoided in
this case.
This document does not discuss the implementation details of the
encoder and decoder, but only describes the bitstream format.
Because of its scalable nature, there are a number of sub-bitstreams
(sub-layer) in a UEMCLIP bitstream. By choosing appropriate sub-
layers, the codec can adapt to the following requirements:
o Sampling frequency,
o Number of channels,
o Speech quality, and
o Bit-rate.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
The UEMCLIP codec operates at a 20-ms frame, and includes three sub-
coders as shown in Table 1. The core layer is u-law G.711 at 64
kbit/s, and other two are quality and bandwidth enhancement layers
with bit-rate of 16 kbit/s each.
+-------+---------------------+----------+--------------------------+
| Layer | Description | Bit-rate | Coding algorithm |
+-------+---------------------+----------+--------------------------+
| a | G.711 core | 64 | u-law PCM |
| | | | |
| b | Lower-band | 16 | Time domain block |
| | enhancement | | quantization |
| | | | |
| c | Higher-band | 16 | MDCT block quantization |
+-------+---------------------+----------+--------------------------+
Table 1: Sub-Layer Description
Based on these sub-layers, the UEMCLIP codec operates in four modes
as shown in Table 2. Here, "Ch" is the number of channels and "Fs"
is the sampling frequency in kHz. It should be noted that the
current version only supports single-channel operation and there
might be future extensions with multi-channel capabilities. The
absent Modes 2 and 5 are reserved for possible future extension to 32
kHz sampling modes. As the mode definition is expected to grow, any
other modes not defined in this table MUST NOT be used for
compatibility and interoperability reasons.
+------+----+----+-------+-------+-------+-------------+------------+
| Mode | Ch | Fs | Layer | Layer | Layer | Bit-rate | Total |
| | | | a | b | c | w/o headers | bit-rate |
| | | | | | | [kbit/s] | [kbit/s] |
+------+----+----+-------+-------+-------+-------------+------------+
| 0 | 1 | 8 | x | - | - | 64 | 67.2 |
| | | | | | | | |
| 1 | 1 | 16 | x | - | x | 80 | 84.0 |
| | | | | | | | |
| 2 | - | - | - | - | - | - | - |
| | | | | | | | |
| 3 | 1 | 8 | x | x | - | 80 | 84.0 |
| | | | | | | | |
| 4 | 1 | 16 | x | x | x | 96 | 100.8 |
| | | | | | | | |
| 5 | - | - | - | - | - | - | - |
+------+----+----+-------+-------+-------+-------------+------------+
Table 2: Mode Description
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
The UEMCLIP bitstream contains internal headers and other side-
information apart from the layer data. This results in total bit-
rate larger than the sum of the layers shown in the above table. The
detail of the internal headers and auxiliary information are
described in <a href="#section-3.3.1">Section 3.3.1</a>.
Defining the sampling frequency and the number of channels does not
result in a singular mode, i.e., there can be multiple modes for the
same sampling frequency or number of channels. The supported modes
would differ between implementations; thus, the sender and the
receiver must negotiate what mode to use for transmission.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Payload Format</span>
As an RTP payload, the UEMCLIP bitstream can contain one or more
frames as shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| one or more frames of UEMCLIP |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 1: RTP Payload Format
The UEMCLIP bitstream has a scalable structure; thus, it is possible
to reconstruct the signal by decoding a part of it. A UEMCLIP frame
is composed of a main header (MH) followed by one or more (up to
three) sub-layers (SLs) as shown in Figure 2.
+--+-------+//-+
|MH| SL #1 |...|
+--+-------+//-+
Figure 2: A UEMCLIP Frame (Bitstream Format)
As a sub-layer, the core layer, i.e., "Layer a", MUST always be
included. It should be noted that the location of the core layer may
or may not immediately follow MH field. The decoder MUST always
refer to the layer indices for proper decoding because the order of
the sub-layers is arbitrary.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
The UEMCLIP bitstream does not explicitly include the following
information: mode and sampling frequency (Fs). As described before,
this information MUST be exchanged while establishing a connection,
for example, by means of SDP.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. RTP Header Usage</span>
Each RTP packet starts with a fixed RTP header, as explained in
[<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. The following fields of the RTP fixed header used
specifically for UEMCLIP streams are emphasized:
Payload type: The assignment of an RTP payload type for this packet
format is outside the scope of this document; however, it is
expected that a payload type in the dynamic range shall be
assigned.
Timestamp: This encodes the sampling instant of the first speech
signal sample in the RTP data packet. For UEMCLIP streams, the
RTP timestamp MUST advance based on a clock either at 8000 or
16000 (Hz). In cases where the audio sampling rate can change
during a session, the RTP timestamp rate MUST be equal to the
maximum rate (in Hz) given in the mode range (see <a href="#section-6.2.1">Section 6.2.1</a>).
This implies that the RTP timestamp rate for UEMCLIP payload type
MUST NOT change during a session. For example, for a UEMCLIP
stream with 8-kHz audio sampling, where a transition to a 16-kHz
audio sampling mode is allowed, the RTP time stamp must always
advance using the 16-kHz clock rate. For a fixed audio sampling
mode, the RTP timestamp rate should be either 8 or 16 kHz,
depending on the sampling rate.
Marker bit: If the codec is used for applications with discontinuous
transmission (DTX, or silence compression), the first packet after
a silence period during which packets have not been transmitted
contiguously SHOULD have the marker bit in the RTP data header set
to one. The marker bit in all other packets MUST be zero.
Applications without DTX MUST set the marker bit to zero.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Multiple Frames in an RTP Packet</span>
More than one UEMCLIP frame may be included in a single RTP packet by
a sender. However, senders have the following additional
restrictions:
o A single RTP packet SHOULD NOT include more UEMCLIP frames than
will fit in the path MTU.
o All frames contained in a single RTP packet MUST be of the same
mode.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
o Frames MUST NOT be split between RTP packets.
It is RECOMMENDED that the number of frames contained within an RTP
packet be consistent with the application. Since UEMCLIP is designed
for telephony applications where delay has a great impact on the
quality, then fewer frames per packet for lower delay, is preferable.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Payload Data</span>
In a UEMCLIP bitstream, all numbers are encoded in a network byte
order.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Main Header</span>
The main header (MH) is placed at the top of a frame and has a size
of 6 bytes. The content of the main header is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MX | PC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PC(cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: UEMCLIP Main Header Format (MH)
Mixing information (MX): 8 bits
Mixing information field. This field is only relevant when Topo-
RTCP-terminating-MCUs are utilized to interpret these fields. See
<a href="#section-3.3.1.1">Section 3.3.1.1</a> for details of the fields.
Packet-loss Concealment information (PC): 40 bits
Packet-loss concealment (PLC) information field. See
<a href="#section-3.3.1.2">Section 3.3.1.2</a>.
<span class="h5"><a class="selflink" id="section-3.3.1.1" href="#section-3.3.1.1">3.3.1.1</a>. Mixing Information Field</span>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|R|V| PW1 |
|1|1|1| |
+-+-+-+-+-+-+-+-+
Figure 4: Mixing Information Field (MX)
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
Check bit #1 (C1): 1 bit
Validity flag of V1 and PW1. This bit being "1" indicates that
both parameters are valid, and "0" indicates that the parameters
should be ignored. If any of these parameters is invalid, this
bit should be set to "0". This flag is mainly intended for a
UEMCLIP-conscious Topo-RTCP-terminating-MCU. This flag should be
set to "0" in case of upward transcoding from G.711 (see
<a href="#section-4">Section 4</a>).
Reserved bit #1 (R1): 1 bit
This bit should be ignored. The default of this bit is 0.
VAD flag #1 (V1): 1 bit
Voice activity detection flag of the current frame, designed to be
used for MCU operations. This flag being "1" indicates that the
frame is an active (voice) segment, and "0" indicates that it is
an inactive (non-voice) or a silent segment. This flag is
specifically designed for mixing information. DTX judgment based
this flag is not recommended.
Power #1 (PW1): 5 bits
Signal power code of the current frame. The code is obtained by
calculating a root mean square (RMS) of "Layer a" and encoding
this RMS using G.711 u-law [<a href="#ref-ITU-T-G.711">ITU-T-G.711</a>]. Denoting the encoded
RMS as R, then PW1 is obtained by PW1 = ((~R)>>2) & 0x1F, where
"~", ">>", "&" are one's complement arithmetic, right SHIFT, and
bitwise AND operators, respectively.
<span class="h5"><a class="selflink" id="section-3.3.1.2" href="#section-3.3.1.2">3.3.1.2</a>. PLC Information Field</span>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R2 |V| K |U| P1 |U| P2 | PW2 |
|2| |2| |1| |2| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| R3 |
| |
+-+-+-+-+-+-+-+-+
Figure 5: PLC Information Field (PC)
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
Check bit #2 (C2): 1 bit
Validity flag of V2, K, U1, P1, U2, P2, and PW2. If the flag is
"1", it means that all these parameters are valid, and "0" means
that the parameters should be ignored. If any of these parameters
is invalid, this bit should be set to "0". Similarly to C1, this
flag should be set to "0" in case of upward transcoding from G.711
(see <a href="#section-4">Section 4</a>).
Reserved bit #2 (R2): 2 bits
These bits should be ignored. The default of these bits are 0.
VAD flag #2 (V2): 1 bit
Voice activity detection flag of the current frame, designed to be
used for packet-loss concealment. This might not be the same as
V1 in the mixing information, and might not be synchronous to the
marker bit in the RTP header. DTX judgment based this flag is not
recommended.
Frame indicator (K): 4 bits
This value indicates the frame offset of U2, P2, and PW2. Since
it is a better idea to carry the speech feature parameters as PLC
information in a different frame to maintain the speech quality,
this frame offset value gives with which frame the parameters are
to be associated. The value ranges between "0" and "15". If the
current frame number is N, for example, the value K indicates that
U2, P2, and PW2 are associated with the frame of N-K. The frame
indicator is equal to the difference in the RTP sequence number
when one UEMCLIP frame is contained in a single RTP packet.
V/UV flag #1 (U1): 1 bit
Voiced/Unvoiced signal indicator of the current frame. This flag
being "0" indicates that the frame is a voiced signal segment, and
"1" indicates that it is an unvoiced signal segment.
Pitch lag #1 (P1): 7 bits
Pitch code of the current frame. The actual pitch lag is
calculated as P1+20 samples in 8-kHz sampling rate. Pitch lag
must be 20 <= pitch length <= 120. Codes ranging between "0x65"
and "0x7F" are not used. To obtain the pitch lag, any pitch
estimation method can be used, such as the one used in G.711
<a href="#appendix-I">Appendix I</a> [<a href="#ref-ITU-T-G.711Appendix1">ITU-T-G.711Appendix1</a>].
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
V/UV flag #2 (U2): 1 bit
Voiced/Unvoiced signal indicator of the offset frame. This flag
being "0" indicates that the frame is a voiced signal segment, and
"1" indicates that it is an unvoiced signal segment. The offset
value is defined as K.
Pitch lag #2 (P2): 7 bits
Pitch code of the offset frame. The offset value is defined as K.
The calculation method is identical to "P1", except that it is
based on the signal of offset frame.
Power #2 (PW2): 8 bits
Signal power code of the offset frame. The offset value is
defined as K.
Reserved bits #3 (R3): 8 bits
These bits should be ignored. The default of all bits are "0".
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Sub-Layer</span>
Sub-layer (SL) is a sub-header followed by layer bitstreams, as shown
in Figure 6. The sub-header indicates the layer location and the
number of bytes.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
|CI |FI |QI |R4 | SB | LD ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
Figure 6: Sub-Layer Format (SL)
Channel index (CI): 2 bits
Indicates the channel number. For all modes given in Table 2,
this should be "0". The detail is given in Table 3.
Frequency index (FI): 2 bits
Indicates the frequency number. "0" means that the layer is in the
base frequency band, higher number means that the layer is in
respective frequency band. The detail is given in Table 3.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
Quality index (QI): 2 bits
Indicates the quality layer number. "0" means that the layer is in
the base layer, and higher number means that the layer is in
respective quality layer. The detail is given in Table 3.
Reserved #4 (R4): 2 bits
Not used (reserved). The default value is "0".
Sub-layer Size (SB): 8 bits
Indicates the byte size of the following sub-layer data.
Layer Data (LD): SB*8 bits
The actual sub-layer data.
For all the layers shown in Table 1, the layer indices are shown in
Table 3.
+-------+----+----+----+
| Layer | CI | FI | QI |
+-------+----+----+----+
| a | 0 | 0 | 0 |
| | | | |
| b | 0 | 0 | 1 |
| | | | |
| c | 0 | 1 | 0 |
+-------+----+----+----+
Table 3: Layer Indices
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Transcoding between UEMCLIP and G.711</span>
As given in <a href="#section-2">Section 2</a>, the u-law-encoded G.711 bitstream (Layer a) is
the core layer of a UEMCLIP bitstream, and is always embedded. This
means that media transcoding from the UEMCLIP bitstream to G.711 does
not have to undergo decoding and re-encoding procedures, but simple
extraction would suffice. However, this does not apply for the
reverse procedure, i.e., transcoding from G.711 to UEMCLIP, because
the auxiliary information in the main header (MH) must be assigned
separately. It should be noted that this media transcoding is useful
for a Media Translator (Topo-Media-Translator) or a Point-to-
Multipoint Using RTCP Terminating MCU (Topo-RTCP-terminating-MCU) in
[<a href="./rfc5117" title=""RTP Topologies"">RFC5117</a>], and all the requirements apply. This means that a
transcoding device of this sort MUST rewrite RTCP packets, together
with the RTP media packets.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
The transcoding from UEMCLIP to u-law G.711 can be done easily by
finding an appropriate sub-layer. Within a frame, the transcoder
should look for a sub-layer with a layer index of "0x00", and
subsequent LD that has a size of SB*8 bits (UEMCLIP has a 20-ms frame
thus, SB=160) are the actual G.711 bitstream data. It should be
noted that the transcoder should not always expect the core layer to
be located right after the main header.
On the other hand, the transcoding from G.711 to UEMCLIP is not
entirely straightforward. Since there are no means to generate
enhancement sub-layers, a G.711 bitstream can only be converted to
UEMCLIP Mode 0 bitstream. If the original G.711 bitstream is encoded
in A-law, it should first be converted to u-law to become the core
layer. Because a UEMCLIP frame size is 20 ms, a u-law-encoded G.711
bitstream MUST be a 160-sample chunk to become a core layer. For the
main header contents, when the UEMCLIP encoder is not available, it
should follow these guidelines:
o The check bits for mixing and PLC (C1 and C2) are set to 0.
o The reserved bits (R1 to R3) in MH are set to respective default
values.
For the core layer (i.e., u-law G.711 bitstream), it should have the
following sub-layer header:
o All CI, FI, QI, and R4 MUST be 0.
o Sub-layer size (SB) MUST be 160 for a 20-ms frame.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Congestion Control Considerations</span>
The general congestion control considerations for transporting RTP
data also apply to UEMCLIP over RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] as well as any
applicable RTP profile like Audio-Visual Profile (AVP) [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>].
The bandwidth of a UEMCLIP bitstream can be reduced by changing to
lower-bit-rate modes. The embedded layer structure of UEMCLIP may
help to control congestion, when dynamic mode changing (see
<a href="#section-6.2.1">Section 6.2.1</a>) is available, and the range of modes is obtained by
offer-answer negotiation as given in <a href="#section-6.3">Section 6.3</a>. It should be noted
that this involves proper RTCP handling when the bit-rate is modified
in an RTP translator or a mixer [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
Packing more frames in each RTP payload can reduce the number of
packets sent, and hence the overhead from IP/UDP/RTP headers, at the
expense of increased delay and reduced error robustness against
packet losses. It should be treated with care because increased
delay means reduced quality.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Payload Format Parameters</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Media Type Registration</span>
This registration is done using the template defined in [<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>] and
following [<a href="./rfc4855" title=""Media Type Registration of RTP Payload Formats"">RFC4855</a>].
Media type name: audio
Media subtype name: UEMCLIP
Required parameters:
Rate: Defines the sampling rate, and it MUST be either 8000 or
16000. See <a href="#section-6.2.1">Section 6.2.1</a> "Mode specification" of <a href="./rfc5686">RFC 5686</a>
(this RFC) for details.
Optional parameters:
ptime: See <a href="./rfc4566">RFC 4566</a> [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
maxptime: See <a href="./rfc4566">RFC 4566</a> [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
mode: Indicates the range of dynamically changeable modes during
a session. Possible values are a comma-separated list of modes
from the supported mode set: 0, 1, 3, and 4. If only one mode
is specified, it means that the mode must not be changed during
the session. When not specified, the mode transmission
defaults to a singular mode as specified in Table 4. See
<a href="#section-6.2.1">Section 6.2.1</a> "Mode specification" of <a href="./rfc5686">RFC 5686</a> (this RFC) for
details.
Encoding considerations: This media type is framed and contains
binary data. See <a href="./rfc4288#section-4.8">Section 4.8 of RFC 4288</a>.
Security considerations: See <a href="#section-7">Section 7</a> "Security Considerations" of
<a href="./rfc5686">RFC 5686</a> (this RFC).
Interoperability considerations: This media may be readily
transcoded to u-law-encoded ITU-T G.711. See <a href="#section-4">Section 4</a>
"Transcoding between UEMCLIP and G.711" of <a href="./rfc5686">RFC 5686</a> (this RFC).
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
Published specification: <a href="./rfc5686">RFC 5686</a> (this RFC)
Applications that use this media type: Audio and video streaming and
conferencing tools.
Additional information: None
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP.
Person & email address to contact for further information:
Yusuke Hiwasaki <hiwasaki.yusuke@lab.ntt.co.jp>
Author: Yusuke Hiwasaki
Change Controller: IETF Audio/Video Transport Working Group
delegated from the IESG
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Mapping to SDP Parameters</span>
The media types audio/UEMCLIP are mapped to fields in the Session
Description Protocol (SDP) [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>] as follows:
Media name: The "m=" line of SDP MUST be audio.
Encoding name: Registered media subtype name should be used for the
"a=rtpmap" line.
Sampling Frequency: Depending on the mode, clock rate (sampling
frequency) specified in "a=rtpmap" MUST be selected from the ones
defined in Table 2. See <a href="#section-6.2.1">Section 6.2.1</a> for details.
Encoding parameters: Since this is an audio stream, the encoding
parameters indicate the number of audio channels, and this SHOULD
default to "1", as selected from the ones defined in Table 2.
This is OPTIONAL.
Packet time: A frame length of any UEMCLIP is 20 ms, thus the
argument of "a=ptime" SHOULD be a multiple of "20". When not
listed in SDP, it should also default to the minimum size: "20".
UMECLIP specific: Any description specific to UEMCLIP is defined in
the Format Specification Parameters ("a=fmtp"). Each parameter
MUST be separated with ";", and if any attribute (value) exists,
it MUST be defined with "=". For compatibility reasons, any
application/terminal MUST ignore any parameters that it does not
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
understand. This is to ensure the upper-compatibility with
parameters added in future enhancements. The mode specification
should be made here (see <a href="#section-6.2.1">Section 6.2.1</a>).
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Mode Specification</span>
Since UEMCLIP codec can operate in number of modes (bit-rates), it is
desirable to specify the range of modes at which an encoder or a
decoder can operate. When exchanging SDP messages, an offerer should
specify all possible combinations of mode numbers as arguments to
"mode=" in "a=fmtp" line, delimited by commas ",". In case of
specifying multiple modes, those SHOULD appear in the descending
priority order.
Although UEMCLIP decoders SHOULD accept bitstreams in any modes, an
implementation may fail to adapt to the dynamic mode changes during a
session. For this reason, an application may choose to operate
either with one fixed mode or with multiple modes that can be
dynamically changed. If the mode is to be fixed and changes are not
allowed, this can be indicated by specifying a single mode per
payload type.
The mode numbers that can be specified in a payload type as arguments
to "mode" are restricted by a combination of a clock rate and a
number of audio channels. This is because SDP binds a payload type
to a combination of a sampling frequency and a number of audio
channels. Table 4 gives selectable mode numbers that are attributed
with clock rates. When mode specifications are not given at all, a
payload type MUST default to a single mode using the default value
specified in this table.
+------------+----------+------------------+--------------+
| Clock rate | Channels | Selectable modes | Default mode |
+------------+----------+------------------+--------------+
| 8000 | 1 | 0,3 | 0 |
| | | | |
| 16000 | 1 | 0,1,3,4 | 1 |
+------------+----------+------------------+--------------+
Table 4: Default Modes
It should be noted that a mode attributed with a larger sampling
frequency (Fs) is not used in conjunction with smaller clock rates
specified in "a=rtpmap". This means that Modes 0 and 3 can be
specified in a payload type having a clock rate of both 8000 and
16000 in "a=rtpmap", but Modes 1 and 4 cannot be specified with one
having a clock rate of 8000.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Offer-Answer Model Considerations</span>
<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>. Offer-Answer Guidelines</span>
The procedures related to exchanging SDP messages MUST follow
[<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>]. The following is a detailed list on the semantics of
using the UEMCLIP payload format in an offer-answer exchange.
o An offerer SHOULD offer every possible combination of UEMCLIP
payload type it can handle, i.e., sampling frequency, channel
number, and fmtp parameters, in a preferred order. When the
transmission bandwidth is restricted, it MUST be offered in
accordance to the restriction.
o When multiple UEMCLIP payload types are offered, it is RECOMMENDED
that the answerer select a single UEMCLIP payload type and answer
it back.
o In a UEMCLIP payload type, an answerer MUST answer back suitable
mode number(s) as a subset of what has been offered. This means
that there is a symmetry assumption on sent and received streams,
and the offerer MUST NOT send in modes that it does not offer.
o In an offering/answering SDP, any fmtp parameters that are not
known MUST be ignored. If any unknown/undefined parameters should
be offered, an answerer MUST delete the entry from the answer
message.
o A receiver of an SDP message MUST only use specified payload types
and modes. When a mode specification is missing, i.e., a mode is
not specified at all, the session MUST default to one single mode
without mode changes during a session. For this case, the default
mode values, as shown in Table 4, MUST be used based on the
sampling frequency and number of channels. This table must be
looked up only when there are no mode specifications; thus, the
offerer/answerer MUST NOT assume that the default modes are always
available when it is not in the specified list of modes.
o When an offered condition does not fit an answerer's capabilities,
it naturally MUST NOT answer any of the conditions, and the
session MAY proceed to re-INVITE, if possible. If a condition
(mode) is decided upon, an offerer and an answerer MUST transmit
on this condition.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>. Examples</span>
When an offerer indicates that he/she wishes to dynamically switch
between modes (0,1,3, and 4) during a session, an example of an
offered SDP could be:
v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4,1,3,0
It should be noted that the listed modes appears in the offerer's
preference.
When an answerer can only operate in Modes 1 and 0 but can
dynamically switch between those modes during a session, an answerer
MUST delete the entries of Mode 3 and 4, and answer back as:
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1,0
As a result, both would start communicating in either Mode 1 or 0,
and can dynamically switch between those modes during the session.
On the other hand, when the answerer is capable of communicating
either in Modes 1 or 0, and cannot switch between modes during a
session, an example of such answer is as follows:
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 96
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=1
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
As a result, both will start communicating in Mode 1. It should be
noted that mode change during this session is not allowed because the
answerer responded with a single mode, and answerer selected Mode 1
above Mode 0 according to the offered order.
If an offerer does not want a mode change during a session but is
capable of receiving either Modes 4 or 1 bitstreams, the SDP should
somewhat look like:
v=0
o=john 51050101 51050101 IN IP4 offhost.example.com
s=-
c=IN IP4 offhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96 97
a=rtpmap:96 UEMCLIP/16000/1
a=fmtp:96 mode=4
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1
and if the answerer prefers to communicate in Mode 1, an answer would
be:
v=0
o=lena 549947322 549947322 IN IP4 anshost.example.org
s=-
c=IN IP4 anshost.example.org
t=0 0
m=audio 5004 RTP/AVP 97
a=rtpmap:97 UEMCLIP/16000/1
a=fmtp:97 mode=1
Please note that it is RECOMMENDED to select a single UEMCLIP payload
type for answers.
The "ptime" attribute is used to denote the desired packetization
interval. When not specified, it SHOULD default to 20. Since
UEMCLIP uses 20-ms frames, ptime values of multiples of 20 imply
multiple frames per packet. In the example below, the ptime is set
to 60, and this means that offerer wants to receive 3 frames in each
packet.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
v=0
o=kosuke 2890844730 2890844730 IN IP4 anotherhost.example.com
s=-
c=IN IP4 anotherhost.example.com
t=0 0
m=audio 5004 RTP/AVP 96
a=ptime:60
a=rtpmap:96 UEMCLIP/16000/1
When mode specification is not present, it should default to a fixed
mode, and in this case, Mode 1 (see <a href="#section-6.2.1">Section 6.2.1</a>).
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and any appropriate profiles. This implies
that confidentiality of the media streams is achieved by encryption
unless the applicable profile specifies other means.
A potential denial-of-service threat exists for data encoding using
compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological datagrams
into the stream that are complex to decode and cause the receiver
output to become overloaded. However, the UEMCLIP covered in this
document do not exhibit any significant non-uniformity.
Another potential threat is memory attacks by illegal layer indices
or byte numbers. The implementor of the decoder should always be
aware that the indicated numbers may be corrupted and not point to
the right sub-layer, and they may force reading beyond the bitstream
boundaries. It is advised that a decoder implementation reject
layers of such indices.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
One new media subtype (audio/UEMCLIP) has been registered by IANA.
For details, see <a href="#section-6.1">Section 6.1</a>.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-ITU-T-G.711">ITU-T-G.711</a>]
International Telecommunications Union, "Pulse code
modulation (PCM) of voice frequencies", ITU-
T Recommendation G.711, November 1988.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</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-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-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-RFC3551">RFC3551</a>] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, <a href="./rfc3551">RFC 3551</a>,
July 2003.
[<a id="ref-RFC4288">RFC4288</a>] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", <a href="https://www.rfc-editor.org/bcp/bcp13">BCP 13</a>, <a href="./rfc4288">RFC 4288</a>, December 2005.
[<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-RFC4855">RFC4855</a>] Casner, S., "Media Type Registration of RTP Payload
Formats", <a href="./rfc4855">RFC 4855</a>, February 2007.
[<a id="ref-RFC4856">RFC4856</a>] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences",
<a href="./rfc4856">RFC 4856</a>, February 2007.
[<a id="ref-RFC5117">RFC5117</a>] Westerlund, M. and S. Wenger, "RTP Topologies", <a href="./rfc5117">RFC 5117</a>,
January 2008.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-ITU-T-G.711Appendix1">ITU-T-G.711Appendix1</a>]
International Telecommunications Union, "Pulse code
modulation (PCM) of voice frequencies, <a href="#appendix-I">Appendix I</a>: A high
quality low-complexity algorithm for packet loss
concealment with G.711", ITU-T Recommendation G.711
<a href="#appendix-I">Appendix I</a>, September 1999.
<span class="grey">Hiwasaki & Ohmuro Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5686">RFC 5686</a> RTP Payload Format for UEMCLIP October 2009</span>
Authors' Addresses
Yusuke Hiwasaki
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi
Tokyo 180-8585
Japan
Phone: +81(422)59-4815
EMail: hiwasaki.yusuke@lab.ntt.co.jp
Hitoshi Ohmuro
NTT Corporation
3-9-11 Midori-cho,
Musashino-shi
Tokyo 180-8585
Japan
Phone: +81(422)59-2151
EMail: ohmuro.hitoshi@lab.ntt.co.jp
Hiwasaki & Ohmuro Standards Track [Page 21]
</pre>
|
