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
|
<pre>Internet Engineering Task Force (IETF) S. Ikonin
Request for Comments: 6262 SPIRIT DSP
Category: Standards Track August 2011
ISSN: 2070-1721
<span class="h1">RTP Payload Format for IP-MR Speech Codec</span>
Abstract
This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the Real-time Transport
Protocol (RTP). The payload format supports transmission of multiple
frames per packet and introduces redundancy for robustness against
packet loss and bit errors.
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/rfc6262">http://www.rfc-editor.org/info/rfc6262</a>.
Copyright Notice
Copyright (c) 2011 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.
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
<span class="grey">Ikonin Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
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
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-2">2</a>. IP-MR Codec Description .........................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Payload Format ..................................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. RTP Header Usage ...........................................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. RTP Payload Structure ......................................<a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Speech Payload Header ......................................<a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Speech Payload Table of Contents ...........................<a href="#page-6">6</a>
<a href="#section-3.5">3.5</a>. Speech Payload Data ........................................<a href="#page-6">6</a>
<a href="#section-3.6">3.6</a>. Redundancy Payload Header ..................................<a href="#page-7">7</a>
<a href="#section-3.7">3.7</a>. Redundancy Payload Table of Contents .......................<a href="#page-8">8</a>
<a href="#section-3.8">3.8</a>. Redundancy Payload Data ....................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. Payload Examples ................................................<a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Payload Carrying a Single Frame ............................<a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. Payload Carrying Multiple Frames with Redundancy ..........<a href="#page-10">10</a>
<a href="#section-5">5</a>. Congestion Control .............................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-7">7</a>. Payload Format Parameters ......................................<a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Media Type Registration ...................................<a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Mapping Media Type Parameters into SDP ....................<a href="#page-14">14</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-14">14</a>
<a href="#section-9">9</a>. Normative References ...........................................<a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. Retrieving Frame Information ..........................<a href="#page-16">16</a>
<a href="#appendix-A.1">A.1</a>. get_frame_info.c ..........................................<a href="#page-16">16</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies the payload format for packetization of
SPIRIT IP-MR encoded speech signals into the Real-time Transport
Protocol (RTP). The payload format supports transmission of multiple
frames per packet and introduces redundancy for robustness against
packet loss and bit errors.
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">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="grey">Ikonin Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. IP-MR Codec Description</span>
IP-MR is a wideband speech codec designed by SPIRIT for conferencing
services over packet-switched networks such as the Internet.
IP-MR is a scalable codec. This means that the source not only has
the ability to change transmission rate on the fly, but the gateway
is also able to decrease bandwidth at any time without performance
overhead. There are 6 coding rates from 7.7 to 34.2 kbps available.
The codec operates on a frame-by-frame basis with a frame size of 20
ms at a 16 kHz sampling rate with a total end-to-end delay of 25 ms.
Each compressed frame is represented as a sequence of layers. The
first (base) layer is mandatory while the other (enhancement) layers
can be safely discarded. Information about the particular frame
structure is available from the payload header. In order to adjust
outgoing bandwidth, the gateway MUST read the frame(s) structure from
the payload header, define which enhancement layers to discard, and
compose a new RTP packet according to this specification.
In fact, not all bits within a frame are equally tolerant to
distortion. IP-MR defines 6 classes ('A'-'F') of sensitivity to bit
errors. Any damage of class 'A' bits causes significant
reconstruction artifacts while the loss in class 'F' may not even be
perceived by the listener. Note that only the base layer in a
bitstream is represented as a set of classes.
The IP-MR payload format allows frame duplication through the packets
to improve robustness against packet loss (<a href="#section-3.6">Section 3.6</a>). The base
layer can be retransmitted completely or in several sensitive
classes. Enchantment layers are not retransmittable.
The fine-grained redundancy in conjunction with bitrate scalability
allows applications to adjust the trade-off between overhead and
robustness against packet loss. Note that this approach is supported
natively within a packet and requires no out-of-band signals or
session-initialization procedures.
The main IP-MR features are as follows:
o High-quality wideband speech codec.
o Bitrate scalable with 6 average rates from 7.7 to 34.2 kbps.
o Built-in discontinuous transmission (DTX) and comfort noise
generation (CNG) support.
<span class="grey">Ikonin Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
o Flexible in-band redundancy control scheme for packet-loss
protection.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Payload Format</span>
The payload format consists of the RTP header and the IP-MR payload.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. RTP Header Usage</span>
The format of the RTP header is specified in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. This payload
format uses the fields of the header in a manner consistent with that
specification.
The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame-block in the packet. The
timestamp clock frequency SHALL be 16 kHz. The duration of one frame
is 20 ms, which corresponds to 320 samples per frame. Thus, the
timestamp is increased by 320 for each consecutive frame. The
timestamp is also used to recover the correct decoding order of the
frame-blocks.
The RTP header marker bit (M) SHALL be set to 1 whenever the first
frame-block carried in the packet is the first frame-block in a
talkspurt (see definition of talkspurt in <a href="./rfc3551#section-4.1">Section 4.1 of [RFC3551]</a>).
For all other packets, the marker bit SHALL be set to zero (M=0).
The assignment of an RTP payload type for the format defined in this
memo is outside the scope of this document. The RTP profiles in use
currently mandate binding the payload type dynamically for this
payload format. This is basically necessary because the payload type
expresses the configuration of the payload itself, i.e., basic or
interleaved mode, and the number of channels carried.
The remaining RTP header fields are used as specified in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. RTP Payload Structure</span>
The IP-MR payload is composed of two payloads, one for current speech
and one for redundancy. Both payloads are represented in this form:
Header, Table of Contents (TOC), and Data. Redundancy payload
carries data for preceding and pre-preceding packets.
+--------+-----+----------------------+- - - - +- - +- - - - - +
| Header | TOC | Data | Header | TOC | Data |
+--------+-----+----------------------+- - - - +- - +- - - - - +
|<- Speech -------------------------->|<- Redundancy (opt) ---->|
<span class="grey">Ikonin Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Speech Payload Header</span>
This header carries parameters that are common for all frames in the
packet:
0 1
0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+
|T| CR | BR |D|A|GR |R|
+-+-+-+-+-+-+-+-+-+-+-+-+
o T (1 bit): Reserved. MUST always be set to 0. Receiver MAY
discard packet if the 'T' bit is not equal to 0.
o CR (3 bits): Coding rate index - top enchantment layer available.
The CR value 7 (NO_DATA) indicates that there is no speech data
(and thus no speech TOC) in the payload. This MAY be used to
transmit redundancy data only.
o BR (3 bits): Base rate index - base layer bitrate. Speech payload
can be scaled to any rate index between BR and CR. Packets with
BR = 6 or BR > CR MUST be discarded. Redundancy data is also
considered to have a base rate of BR.
o D (1 bit): Reserved. MUST always be set to 1. Receiver MAY
discard packet if the 'D' bit is zero.
o A (1 bit): Byte alignment. The value of 1 specifies that padding
bits were added to enable each compressed frame (3.5) to start
with the byte (8-bit) boundary. The value of 0 specifies
unaligned frames. Note that the speech payload is always padded
to the byte boundary independently on an 'A' bit value.
o GR (2 bits): Number of frames in packet (grouping size). Actual
grouping size is GR + 1; thus, the maximum grouping supported is
4.
o R (1 bit): Redundancy presence. Value of 1 indicates redundancy
payload presence.
Note that the values of 'T' and 'D' bits are fixed; any other values
are not allowed by specification. Padding bits ('P' bits) MUST
always be set to zero.
<span class="grey">Ikonin Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
The following table defines the mapping between rate index and rate
value:
+------------+--------------+
| rate index | avg. bitrate |
+------------+--------------+
| 0 | 7.7 kbps |
| 1 | 9.8 kbps |
| 2 | 14.3 kbps |
| 3 | 20.8 kbps |
| 4 | 27.9 kbps |
| 5 | 34.2 kbps |
| 6 | (reserved) |
| 7 | NO_DATA |
+------------+--------------+
The value of 6 is reserved. If receiving this value, the packet MUST
be discarded.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Speech Payload Table of Contents</span>
The speech TOC is a bitmask indicating the presence of each frame in
the packet. TOC is only available if the 'CR' value is not equal to
7 (NO_DATA).
0 1 2 3
+-+-+-+-+
|E|E|E|E|
+-+-+-+-+
|<----->| <-- #(GR+1)
o E (1 bit): Frame existence indicator. The value of 0 indicates
speech data is not present for the corresponding frame. The IP-MR
encoder sets the 'E' flag to 0 for the periods of silence in DTX
mode. Applications MUST set this bit to 0 if the frame is known
to be damaged.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Speech Payload Data</span>
Speech data contains (GR+1) compressed IP-MR frames (20 ms of data).
A compressed frame has a length of zero if the corresponding TOC flag
is zero.
The beginning of each compressed frame is aligned if the 'A' bit is
nonzero, while the end of the speech payload is always aligned to a
byte (8-bit) boundary:
<span class="grey">Ikonin Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
+- - -+------------+------------+------------+------------+
| TOC | Frame1 | Frame2 | Frame3 | Frame4 |
+- - -+------------+------------+------------+------------+ ALWAYS
|<- aligned |<- aligned |<- aligned |<- aligned |<- ALIGNED
Marked regions MUST be padded only if the 'A' bit is set to '1'.
The compressed frame structure is as follows:
|<---- sensitive classes ------>|<----- enchantment layers -------->|
+-------------------------------+----+-----+------+- - - - - +------+
| L1 (Base Layer) | L2 | L3 | L4 | | LN |
+-------------------------------+----+-----+------+- - - - - +------+
|<- A --->|<- B ->| ... |<- F ->| |
|<- BR rate ------------------->| |
|<- CR rate ------------------------------------------------------->|
<a href="#appendix-A">Appendix A</a> of this document provides a helper routine written in "C"
that MUST be used to extract sensitivity classes and bounds for the
enchantment layers from the compressed frame data.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Redundancy Payload Header</span>
The redundancy payload presence is signaled by the 'R' bit of the
speech payload header. The redundancy header is composed of two
fields of 3 bits each:
0 1 2 3 4 5
+-+-+-+-+-+-+
| CL1 | CL2 |
+-+-+-+-+-+-+
The 'CL1' and 'CL2' fields both specify the sensitivity classes
available for preceding and pre-preceding packets respectively.
+-------+--------------------+
| CL | Redundancy classes |
| | available |
+-------+--------------------+
| 0 | NONE |
| 1 | A |
| 2 | A-B |
| 3 | A-C |
| 4 | A-D |
| 5 | A-E |
| 6 | A-F |
| 7 | (reserved) |
+-------+--------------------+
<span class="grey">Ikonin Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
A receiver can reconstruct the base layer of preceding packets
completely (CL=6) or partially (0<CL< 6) based on the sensitivity
classes delivered. A decoder MUST discard the redundancy payload if
'CL' is equal to 0 or 7.
Note that the index of the base rate and grouping parameter is not
transmitted for the redundancy payload. Applications MUST assume
that 'BR' and 'GR' are the same as for the current packet.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Redundancy Payload Table of Contents</span>
The redundancy TOC is a bitmask indicating the presence of each frame
in the redundancy payload. The redundancy TOC is only available if
the 'CL' value is not equal to 0 or 7.
0 1 ...
+-+-+-+-+-+-+-+-+
|E|E|E|E|E|E|E|E|
+-+-+-+-+-+-+-+-+
| |<----->| pre-preceding payload #(GR+1)
|<----->| preceding payload #(GR+1)
o E (1 bit): Redundancy frame existence indicator. The value of 0
indicates redundancy data is not present for corresponding frame.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Redundancy Payload Data</span>
IP-MR defines 6 classes ('A'-'F') of sensitivity to bit errors. Any
damage of class 'A' bits causes significant reconstruction artifacts
while the loss in class 'F' may not even be perceived by the
listener. Note that only the base layer in a bitstream is
represented as a set of classes. Together, the sensitivity classes'
approach and redundancy allow IP-MR duplicate frames through the
packets to improve robustness against packet loss.
Redundancy data carries a number of sensitivity classes for preceding
and pre-preceding packets as indicated by the 'CL1' and 'CL2' fields
of the redundancy header. The sensitivity classes' data is available
individually for each frame only if the corresponding 'E' bit of the
redundancy TOC is nonzero:
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|A-C|A-B|1000|1001|cl_A1|cl_B1|cl_C1|cl_A1|cl_B1|cl_A4|cl_B4|
+---+---+----+----|-----+-----+-----+-----+-----+-----+-----+
|<- CL >|<- TOC ->|<- preceding --->|<- pre-preceding ----->|
<span class="grey">Ikonin Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
Redundancy data is only available if the base rates (BRs) and coding
rates (CRs) of preceding and pre-preceding packets are the same as
for the current packet.
A receiver MAY use redundancy data to compensate for packet loss
(note that in this case, the 'CL' field MUST also be passed to the
decoder). The helper routine provided in <a href="#appendix-A">Appendix A</a> MUST be used to
extract sensitivity classes' length for each frame. The following
pseudocode describes the sequence of operations:
int sensitivityBits[numOfRedundancyFrames][6];
int redundancyBits [numOfRedundancyFrames];
for(i = 0 ; i < numOfRedundancyFrames; i++) {
GetFrameInfo(CR, BR, pRedundancyPayloadData, dummy,
sensitivityBits[i], dummy);
redundancyBits[i] = 0;
for(j = 0; j < CL[i]; j++ ) {
redundancyBits[i] += sensitivityBits[i][j];
}
flushBits(pRedundancyPayloadData, redundancyBits[i]);
}
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Payload Examples</span>
This section provides detailed examples of the IP-MR payload format.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Payload Carrying a Single Frame</span>
The following diagram shows a typical IP-MR payload carrying one
(GR=0) non-aligned (A=0) speech frame without redundancy (R=0). The
base layer is coded at 7.8 kbps (BR=0) while the coding rate is 9.7
kbps (CR=1). The 'E' bit value of 1 signals that compressed frame
bits s(0) - s(193) are present. There is a padding bit 'P' to
maintain speech payload size alignment.
<span class="grey">Ikonin Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|CR=1 |BR=0 |1|0|0 0|0|1|s(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| s(193)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Payload Carrying Multiple Frames with Redundancy</span>
The following diagram shows a payload carrying 3 (GR=2) aligned (A=1)
speech frames with redundancy (R=1). The TOC value of '101'
indicates speech data present for the first (bits sp1(0)-sp1(92)) and
third frames (bits sp3(0)-sp3(171)). There are no enchantment layers
because the base and coding rates are equal (BR=CR=0). The padding
bit 'P' is inserted to maintain necessary alignment.
The redundancy payload present for both preceding and pre-preceding
payloads (CL1 = A-B, CL2=A), but redundancy data is only available
for 5 (TOC='111011') of 6 (2*(GR+1)) frames. There is redundancy
data of 20, 39, and 35 bits for each of the three frames of the
preceding packet and 15 and 19 bits for the two frames of the pre-
preceding packet.
<span class="grey">Ikonin Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|CR=0 |BR=0 |1|1|1 0|1|1 0 1|P|sp1(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp1(92)|P|P|P|sp3(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sp3(171)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|CL1=2|CL2=1|1 1 1|0 1 1|red1_1_AB(0) red1_1_AB(19)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|red1_2_AB(38)|red1_3_AB(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red1_3_AB(34)|red2_2_A(0) red2_2_A(14)|red2_3_A(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| red2_3_A(18)|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Congestion Control</span>
The general congestion control considerations for transporting RTP
data applicable to IP-MR speech over RTP (see RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and any
applicable RTP profile like the Audio-Visual Profile (AVP)
[<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>]). However, the multi-rate capability of IP-MR speech
coding provides a mechanism that may help to control congestion,
since the bandwidth demand can be adjusted by selecting a different
encoding mode.
The number of frames encapsulated in each RTP payload highly
influences the overall bandwidth of the RTP stream due to header
overhead constraints. Packetizing more frames in each RTP payload
can reduce the number of packets sent and thus reduce the overhead
from IP/UDP/RTP headers, at the expense of increased delay.
<span class="grey">Ikonin Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
Due to the scalability nature of the IP_MR codec, the transmission
rate can be reduced at any transport stage to fit channel bandwidth.
The minimal rate is specified by the BR field of the payload header
and can be as low as 7.7 kbps. It is up to the application to keep
the balance between coding quality (high BR) and bitstream
scalability (low BR). Because coding quality depends on coding rate
(CR) rather than base rate (BR), it is NOT RECOMMENDED to use high BR
values for real-time communications.
Applications MAY utilize bitstream redundancy to combat packet loss.
However, the gateway is free to chose any option to reduce the
transmission rate; the coding layer or redundancy bits can be
dropped. Due to this fact, it is NOT RECOMMENDED for applications to
increase the total bitrate when adding redundancy in response to
packet loss.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</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 in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity, and
source authenticity. Confidentiality is achieved by encryption of
the RTP payload. Integrity of the RTP packets is achieved through a
suitable cryptographic integrity-protection mechanism. Such a
cryptographic system may also allow the authentication of the source
of the payload. A suitable security mechanism for this RTP payload
format should provide confidentiality, integrity protection, and
source authentication at least capable of determining if an RTP
packet is from a member of the RTP session.
Note that the appropriate mechanisms to provide security to RTP and
payloads following this memo may vary. The security mechanisms are
dependent on the application, the transport, and the signaling
protocol employed. Therefore, a single mechanism is not sufficient;
although if suitable, usage of the Secure Real-time Transport
Protocol (SRTP) [<a href="./rfc3711" title=""The Secure Real-time Transport Protocol (SRTP)"">RFC3711</a>] is recommended. Other mechanisms that may
be used are IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] and Transport Layer Security (TLS)
[<a href="./rfc5246" title=""The Transport Layer Security (TLS) Protocol Version 1.2"">RFC5246</a>] (RTP over TCP); other alternatives may exist.
This payload format does not exhibit any significant non-uniformity
in the receiver-side computational complexity for packet processing
and thus is unlikely to pose a denial-of-service threat due to the
receipt of pathological data.
<span class="grey">Ikonin Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Payload Format Parameters</span>
This section describes the media types and names associated with this
payload format.
The IP-MR media subtype is defined as 'ip-mr_v2.5'. This subtype was
registered to specify an internal codec version. Later, this version
was accepted as final, the bitstream was frozen, and IP-MR v2.5 was
published under the name of IP-MR. Currently, the terms 'IP-MR' and
'IP-MR v2.5' are synonyms. The subtype name 'ip-mr_v2.5' is being
used in implementations.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Media Type Registration</span>
Media Type name: audio
Media Subtype name: ip-mr_v2.5
Required parameters: none
Optional parameters:
These parameters apply to RTP transfer only.
ptime: The media packet length in milliseconds. Allowed values
are: 20, 40, 60, and 80.
Encoding considerations:
This media type is framed and binary (see <a href="./rfc4288#section-4.8">RFC 4288, Section 4.8</a>).
Security considerations:
See <a href="./rfc6262#section-6">Section 6 of RFC 6262</a>.
Interoperability considerations:
none
Published specification:
<a href="./rfc6262">RFC 6262</a>
Applications that use this media type:
Real-time audio applications like voice over IP,
teleconference, and multimedia streaming.
Additional information:
none
Person & email address to contact for further information:
V. Sviridenko <vladimirs@spiritdsp.com>
<span class="grey">Ikonin Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
Intended usage:
COMMON
Restrictions on usage:
This media type depends on RTP framing and thus is only defined
for transfer via RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
Authors:
Sergey Ikonin <info@spiritdsp.com>
Dmitry Yudin <info@spiritdsp.com>
Change controller:
IETF Audio/Video Transport working group delegated from the IESG.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Mapping Media Type Parameters into SDP</span>
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing the IP-MR codec, the mapping is
as follows:
o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name. The RTP clock rate in "a=rtpmap" MUST be
16000.
o The parameter "ptime" goes in the SDP "a=ptime" attribute.
Any remaining parameters go in the SDP "a=fmtp" attribute by copying
them directly from the media type parameter string as a semicolon-
separated list of parameter=value pairs.
Note that the payload format (encoding) names are commonly shown in
uppercase. Media subtypes are commonly shown in lowercase. These
names are case-insensitive in both places.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
One media type (ip-mr_v2.5) has been defined and registered in the
media types registry.
<span class="grey">Ikonin Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</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-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-RFC3711">RFC3711</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
<a href="./rfc3711">RFC 3711</a>, March 2004.
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</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-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.
<span class="grey">Ikonin Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Retrieving Frame Information</span>
This appendix contains the C code for implementation of the frame-
parsing function. This function extracts information about a coded
frame, including frame size, number of layers, size of each layer,
and size of perceptual sensitive classes.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. get_frame_info.c</span>
/*
Copyright (c) 2011 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
- Redistributions of source code must retain the above copyright
notice, this list of conditions and
the following disclaimer.
- Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
- Neither the name of Internet Society, IETF or IETF Trust, nor the
names of specific contributors, may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
/******************************************************************
<span class="grey">Ikonin Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
get_frame_info.c
Retrieving frame information for IP-MR Speech Codec
******************************************************************/
#define RATES_NUM 6 // number of codec rates
#define SENSE_CLASSES 6 // number of sensitivity classes (A..F)
// frame types
#define FT_SPEECH 0 // active speech
#define FT_DTX_SID 1 // silence insertion descriptor
// get specified bit from coded data
int GetBit(const unsigned char *buf, int curBit)
{
return (buf[curBit>>3]>>(curBit%8))&1;
}
// retrieve frame information
int GetFrameInfo( // o: frame size in bits
short rate, // i: encoding rate (0..5)
short base_rate, // i: base (core) layer rate,
const unsigned char buf[2], // i: coded bit frame
int size, // i: coded bit frame size in bytes
short pLayerBits[RATES_NUM], // o: number of bits in layers
short pSenseBits[SENSE_CLASSES], // o: number of bits in
// sensitivity classes
short *nLayers // o: number of layers
)
{
static const short Bits_1[4] = { 0, 9, 9,15};
static const short Bits_2[16] = { 43,50,36,31,46,48,40,44,
47,43,44,45,43,44,47,36};
static const short Bits_3[2][6] = {{13,11,23,33,36,31},
{25, 0,23,32,36,31},};
int FrType;
int i, nBits = 0;
if (rate < 0 || rate > 5) {
return 0; // incorrect stream
}
// extract frame type bit if required
FrType = GetBit(buf, nBits++) ? FT_SPEECH : FT_DTX_SID;
if((FrType != FT_DTX_SID && size < 2) || size < 1) {
return 0; // not enough input data
<span class="grey">Ikonin Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
}
for(i = 0; i < SENSE_CLASSES; i++) {
pSenseBits[i] = 0;
}
{
int cw_0;
int b[14];
// extract meaning bits
for(i = 0 ; i < 14; i++) {
b[i] = GetBit(buf, nBits++);
}
// parse
if(FrType == FT_DTX_SID) {
cw_0 = (b[0]<<0)|(b[1]<<1)|(b[2]<<2)|(b[3]<<3);
rate = 0;
pSenseBits[0] = 10 + Bits_2[cw_0];
} else {
int i, idx;
int nFlag_1, nFlag_2, cw_1, cw_2;
nFlag_1 = b[0] + b[2] + b[4] + b[6];
cw_1 = (cw_1 << 1) | b[0];
cw_1 = (cw_1 << 1) | b[2];
cw_1 = (cw_1 << 1) | b[4];
cw_1 = (cw_1 << 1) | b[6];
nFlag_2 = b[1] + b[3] + b[5] + b[7];
cw_2 = (cw_2 << 1) | b[1];
cw_2 = (cw_2 << 1) | b[3];
cw_2 = (cw_2 << 1) | b[5];
cw_2 = (cw_2 << 1) | b[7];
cw_0 = (b[10]<<0)|(b[11]<<1)|(b[12]<<2)|(b[13]<<3);
if (base_rate < 0) base_rate = 0;
if (base_rate > rate) base_rate = rate;
idx = base_rate == 0 ? 0 : 1;
pSenseBits[0] = 15+Bits_2[cw_0];
pSenseBits[1] = Bits_1[(cw_1>>0)&0x3] +
Bits_1[(cw_1>>2)&0x3];
pSenseBits[2] = nFlag_1*5;
pSenseBits[3] = nFlag_2*30;
<span class="grey">Ikonin Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6262">RFC 6262</a> RTP Payload Format for IP-MR Speech Codec August 2011</span>
pSenseBits[5] = (4 - nFlag_2)*(Bits_3[idx][0]);
for (i = 1; i < rate+1; i++) {
pLayerBits[i] = 4*Bits_3[idx][i];
}
}
pLayerBits[0] = 0;
for (i = 0; i < SENSE_CLASSES; i++) {
pLayerBits[0] += pSenseBits[i];
}
*nLayers = rate+1;
}
{
// count total frame size
int payloadBitCount = 0;
for (i = 0; i < *nLayers; i++) {
payloadBitCount += pLayerBits[i];
}
return payloadBitCount;
}
}
Author's Address
Sergey Ikonin
SPIRIT DSP
Building 27, A. Solzhenitsyna Street
109004, Moscow
Russia
Tel: +7 495 661-2178
Fax: +7 495 912-6786
EMail: s.ikonin@gmail.com
Ikonin Standards Track [Page 19]
</pre>
|
