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
|
<pre>Internet Engineering Task Force (IETF) X. Duan
Request for Comments: 5993 S. Wang
Category: Standards Track China Mobile Communications Corporation
ISSN: 2070-1721 M. Westerlund
K. Hellwig
I. Johansson
Ericsson AB
October 2010
<span class="h1">RTP Payload Format for</span>
<span class="h1">Global System for Mobile Communications Half Rate (GSM-HR)</span>
Abstract
This document specifies the payload format for packetization of
Global System for Mobile Communications Half Rate (GSM-HR) speech
codec data into the Real-time Transport Protocol (RTP). The payload
format supports transmission of multiple frames per payload and
packet loss robustness methods using redundancy.
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/rfc5993">http://www.rfc-editor.org/info/rfc5993</a>.
<span class="grey">Duan, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Payload Format Capabilities . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Use of Forward Error Correction (FEC) . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Payload Structure . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2.1">5.2.1</a>. Encoding of Speech Frames . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.2.2">5.2.2</a>. Encoding of Silence Description Frames . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. Implementation Considerations . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3.1">5.3.1</a>. Transmission of SID Frames . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3.2">5.3.2</a>. Receiving Redundant Frames . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3.3">5.3.3</a>. Decoding Validation . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-6">6</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. 3 Frames . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. 3 Frames with Lost Frame in the Middle . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. Payload Format Parameters . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7.1">7.1</a>. Media Type Definition . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7.2">7.2</a>. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.2.1">7.2.1</a>. Offer/Answer Considerations . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.2.2">7.2.2</a>. Declarative SDP Considerations . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. Congestion Control . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-10">10</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-11">11</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-12">12</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-12.1">12.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-12.2">12.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<span class="grey">Duan, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
<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 GSM
Half Rate (GSM-HR) codec [<a href="#ref-TS46.002" title=""Half rate speech; Half rate speech processing functions"">TS46.002</a>] encoded speech signals into the
Real-time Transport Protocol (RTP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. The payload format
supports transmission of multiple frames per payload and packet loss
robustness methods using redundancy.
This document starts with conventions, a brief description of the
codec, and payload format capabilities. The payload format is
specified in <a href="#section-5">Section 5</a>. Examples can be found in <a href="#section-6">Section 6</a>. The
media type specification and its mappings to SDP, and considerations
when using the Session Description Protocol (SDP) offer/answer
procedures are then specified. The document ends with considerations
related to congestion control and security.
This document registers a media type (audio/GSM-HR-08) for the Real-
time Transport Protocol (RTP) payload format for the GSM-HR codec.
Note: This format is not compatible with the one provided back in
1999 to 2000 in early draft versions of what was later published as
<a href="./rfc3551">RFC 3551</a>. <a href="./rfc3551">RFC 3551</a> was based on a later version of the Audio-Visual
Profile (AVP) draft, which did not provide any specification of the
GSM-HR payload format. To avoid a possible conflict with this older
format, the media type of the payload format specified in this
document has a media type name that is different from (audio/GSM-HR).
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
This document uses the normal IETF bit-order representation. Bit
fields in figures are read left to right and then down. The leftmost
bit in each field is the most significant. The numbering starts from
0 and ascends, where bit 0 will be the most significant.
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="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. GSM Half Rate</span>
The Global System for Mobile Communications (GSM) network provides
with mobile communication services for nearly 3 billion users
(statistics as of 2008). The GSM Half Rate (GSM-HR) codec is one of
the speech codecs used in GSM networks. GSM-HR denotes the Half Rate
speech codec as specified in [<a href="#ref-TS46.002" title=""Half rate speech; Half rate speech processing functions"">TS46.002</a>].
Note: For historical reasons, these 46-series specifications are
internally referenced as 06-series. A simple mapping applies; for
example, 46.020 is referenced as 06.20, and so on.
<span class="grey">Duan, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
The GSM-HR codec has a frame length of 20 ms, with narrowband speech
sampled at 8000 Hz, i.e., 160 samples per frame. Each speech frame
is compressed into 112 bits of speech parameters, which is equivalent
to a bit rate of 5.6 kbit/s. Speech pauses are detected by a
standardized Voice Activity Detection (VAD). During speech pauses,
the transmission of speech frames is inhibited. Silence Descriptor
(SID) frames are transmitted at the end of a talkspurt and about
every 480 ms during speech pauses to allow for a decent comfort noise
(CN) quality on the receiver side.
The SID frame generation in the GSM radio network is determined by
the GSM mobile station and the GSM radio subsystem. SID frames come
during speech pauses in the uplink from the mobile station about
every 480 ms. In the downlink to the mobile station, when they are
generated by the encoder of the GSM radio subsystem, SID frames are
sent every 20 ms to the GSM base station, which then picks only one
every 480 ms for downlink radio transmission. For other
applications, like transport over IP, it is more appropriate to send
the SID frames less often than every 20 ms, but 480 ms may be too
sparse. We recommend as a compromise that a GSM-HR encoder outside
of the GSM radio network (i.e., not in the GSM mobile station and not
in the GSM radio subsystem, but, for example, in the media gateway of
the core network) should generate and send SID frames every 160 ms.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Payload Format Capabilities</span>
This RTP payload format carries one or more GSM-HR encoded frames --
either full voice or silence descriptor (SID) -- representing a mono
speech signal. To maintain synchronization or to indicate unsent or
lost frames, it has the capability to indicate No_Data frames.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Use of Forward Error Correction (FEC)</span>
Generic forward error correction within RTP is defined, for example,
in <a href="./rfc5109">RFC 5109</a> [<a href="./rfc5109" title=""RTP Payload Format for Generic Forward Error Correction"">RFC5109</a>]. Audio redundancy coding is defined in <a href="./rfc2198">RFC</a>
<a href="./rfc2198">2198</a> [<a href="./rfc2198" title=""RTP Payload for Redundant Audio Data"">RFC2198</a>]. Either scheme can be used to add redundant
information to the RTP packet stream and make it more resilient to
packet losses, at the expense of a higher bit rate. Please see
either RFC for a discussion of the implications of the higher bit
rate to network congestion.
In addition to these media-unaware mechanisms, this memo specifies an
optional-to-use GSM-HR-specific form of audio redundancy coding,
which may be beneficial in terms of packetization overhead.
Conceptually, previously transmitted transport frames are aggregated
together with new ones. A sliding window can be used to group the
frames to be sent in each payload. Figure 1 below shows an example.
<span class="grey">Duan, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An Example of Redundant Transmission
Here, each frame is retransmitted once in the following RTP payload
packet. f(n-2)...f(n+4) denote a sequence of audio frames, and
p(n-1)...p(n+4) a sequence of payload packets.
The mechanism described does not really require signaling at the
session setup. However, signaling has been defined to allow the
sender to voluntarily bound the buffering and delay requirements. If
nothing is signaled, the use of this mechanism is allowed and
unbounded. For a certain timestamp, the receiver may acquire
multiple copies of a frame containing encoded audio data. The cost
of this scheme is bandwidth, and the receiver delay is necessary to
allow the redundant copy to arrive.
This redundancy scheme provides a functionality similar to the one
described in <a href="./rfc2198">RFC 2198</a>, but it works only if both original frames and
redundant representations are GSM-HR frames. When the use of other
media coding schemes is desirable, one has to resort to <a href="./rfc2198">RFC 2198</a>.
The sender is responsible for selecting an appropriate amount of
redundancy, based on feedback regarding the channel conditions, e.g.,
in the RTP Control Protocol (RTCP) [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] receiver reports. The
sender is also responsible for avoiding congestion, which may be
exacerbated by redundancy (see <a href="#section-9">Section 9</a> for more details).
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Payload Format</span>
The format of the RTP header is specified in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. The payload
format described in this document uses the header fields in a manner
consistent with that specification.
The duration of one speech frame is 20 ms. The sampling frequency is
8000 Hz, corresponding to 160 speech samples per frame. An RTP
packet may contain multiple frames of encoded speech or SID
parameters. Each packet covers a period of one or more contiguous
<span class="grey">Duan, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
20-ms frame intervals. During silence periods, no speech packets are
sent; however, SID packets are transmitted every now and then.
To allow for error resiliency through redundant transmission, the
periods covered by multiple packets MAY overlap in time. A receiver
MUST be prepared to receive any speech frame multiple times. A given
frame MUST NOT be encoded as a speech frame in one packet and as a
SID frame or as a No_Data frame in another packet. Furthermore, a
given frame MUST NOT be encoded with different voicing modes in
different packets.
The rules regarding maximum payload size given in <a href="./rfc5405#section-3.2">Section 3.2 of
[RFC5405]</a> SHOULD be followed.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. RTP Header Usage</span>
The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame in the packet. The timestamp
clock frequency SHALL be 8000 Hz. The timestamp is also used to
recover the correct decoding order of the frames.
The RTP header marker bit (M) SHALL be set to 1 whenever the first
frame carried in the packet is the first frame in a talkspurt (see
definition of the 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.
The remaining RTP header fields are used as specified in <a href="./rfc3550">RFC 3550</a>
[<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Payload Structure</span>
The complete payload consists of a payload table of contents (ToC)
section, followed by speech data representing one or more speech
frames, SID frames, or No_Data frames. The following diagram shows
the general payload format layout:
+-------------+-------------------------
| ToC section | speech data section ...
+-------------+-------------------------
Figure 2: General Payload Format Layout
<span class="grey">Duan, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
Each ToC element is one octet and corresponds to one speech frame;
the number of ToC elements is thus equal to the number of speech
frames (including SID frames and No_Data frames). Each ToC entry
represents a consecutive speech or SID or No_Data frame. The
timestamp value for ToC element (and corresponding speech frame data)
N within the payload is (RTP timestamp field + (N-1)*160) mod 2^32.
The format of the ToC element is as follows.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |R R R R|
+-+-+-+-+-+-+-+-+
Figure 3: The TOC Element
F: Follow flag; 1 denotes that more ToC elements follow; 0 denotes
the last ToC element.
R: Reserved bits; MUST be set to zero, and MUST be ignored by
receiver.
FT: Frame type
000 = Good Speech frame
001 = Reserved
010 = Good SID frame
011 = Reserved
100 = Reserved
101 = Reserved
110 = Reserved
111 = No_Data frame
The length of the payload data depends on the frame type:
Good Speech frame: The 112 speech data bits are put in 14 octets.
Good SID frame: The 33 SID data bits are put in 14 octets, as in
the case of Speech frames, with the unused 79 bits all set to "1".
No_Data frame: Length of payload data is zero octets.
Frames marked in the GSM radio subsystem as "Bad Speech frame", "Bad
SID frame", or "No_Data frame" are not sent in RTP packets, in order
to save bandwidth. They are marked as "No_Data frame", if they occur
within an RTP packet that carries more than one speech frame, SID
frame, or No_Data frame.
<span class="grey">Duan, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Encoding of Speech Frames</span>
The 112 bits of GSM-HR-coded speech (b1...b112) are defined in TS
46.020, Annex B [<a href="#ref-TS46.020" title=""Half rate speech; Half rate speech transcoding"">TS46.020</a>], in their order of occurrence. The first
bit (b1) of the first parameter is placed in the most significant bit
(MSB) (bit 0) of the first octet (octet 1) of the payload field; the
second bit is placed in bit 1 of the first octet; and so on. The
last bit (b112) is placed in the least significant bit (LSB) (bit 7)
of octet 14.
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Encoding of Silence Description Frames</span>
The GSM-HR codec applies a specific coding for silence periods in so-
called SID frames. The coding of SID frames is based on the coding
of speech frames by using only the first 33 bits for SID parameters
and by setting all of the remaining 79 bits to "1".
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Implementation Considerations</span>
An application implementing this payload format MUST understand all
the payload parameters that are defined in this specification. Any
mapping of the parameters to a signaling protocol MUST support all
parameters. So an implementation of this payload format in an
application using SDP is required to understand all the payload
parameters in their SDP-mapped form. This requirement ensures that
an implementation always can decide whether it is capable of
communicating when the communicating entities support this version of
the specification.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Transmission of SID Frames</span>
When using this RTP payload format, the sender SHOULD generate and
send SID frames every 160 ms, i.e., every 8th frame, during silent
periods. Other SID transmission intervals may occur due to gateways
to other systems that use other transmission intervals.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Receiving Redundant Frames</span>
The reception of redundant audio frames, i.e., more than one audio
frame from the same source for the same time slot, MUST be supported
by the implementation.
<span class="grey">Duan, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>. Decoding Validation</span>
If the receiver finds a mismatch between the size of a received
payload and the size indicated by the ToC of the payload, the
receiver SHOULD discard the packet. This is recommended, because
decoding a frame parsed from a payload based on erroneous ToC data
could severely degrade the audio quality.
<span class="grey">Duan, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Examples</span>
A few examples below highlight the payload format.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. 3 Frames</span>
Below is a basic example of the aggregation of 3 consecutive speech
frames into a single packet.
The first 24 bits are ToC elements.
Bit 0 is '1', as another ToC element follows.
Bits 1..3 are 000 = Good speech frame
Bits 4..7 are 0000 = Reserved
Bit 8 is '1', as another ToC element follows.
Bits 9..11 are 000 = Good speech frame
Bits 12..15 are 0000 = Reserved
Bit 16 is '0'; no more ToC elements follow.
Bits 17..19 are 000 = Good speech frame
Bits 20..23 are 0000 = Reserved
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|0 0 0|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 2 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 3 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|
+-+-+-+-+-+-+-+-+
<span class="grey">Duan, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. 3 Frames with Lost Frame in the Middle</span>
Below is an example of a payload carrying 3 frames, where the middle
one is No_Data (for example, due to loss prior to transmission by the
RTP source).
The first 24 bits are ToC elements.
Bit 0 is '1', as another ToC element follows.
Bits 1..3 are 000 = Good speech frame
Bits 4..7 are 0000 = Reserved
Bit 8 is '1', as another ToC element follows.
Bits 9..11 are 111 = No_Data frame
Bits 12..15 are 0000 = Reserved
Bit 16 is '0'; no more ToC elements follow.
Bits 17..19 are 000 = Good speech frame
Bits 20..23 are 0000 = Reserved
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|0 0 0 0|1|1 1 1|0 0 0 0|0|0 0 0|0 0 0 0|b1 b8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|b9 Frame 1 b40|
+ +
|b41 b72|
+ +
|b73 b104|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|b105 b112|b1 b24|
+-+-+-+-+-+-+-+-+ +
|b25 Frame 3 b56|
+ +
|b57 b88|
+ +-+-+-+-+-+-+-+-+
|b89 b112|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Payload Format Parameters</span>
This RTP payload format is identified using the media type "audio/
GSM-HR-08", which is registered in accordance with [<a href="./rfc4855" title=""Media Type Registration of RTP Payload Formats"">RFC4855</a>] and uses
[<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>] as a template. Note: Media subtype names are case-
insensitive.
<span class="grey">Duan, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Media Type Definition</span>
The media type for the GSM-HR codec is allocated from the IETF tree,
since GSM-HR is a well-known speech codec. This media type
registration covers real-time transfer via RTP.
Note: Reception of any unspecified parameter MUST be ignored by the
receiver to ensure that additional parameters can be added in the
future.
Type name: audio
Subtype name: GSM-HR-08
Required parameters: none
Optional parameters:
max-red: The maximum duration in milliseconds that elapses between
the primary (first) transmission of a frame and any redundant
transmission that the sender will use. This parameter allows a
receiver to have a bounded delay when redundancy is used. Allowed
values are integers between 0 (no redundancy will be used) and
65535. If the parameter is omitted, no limitation on the use of
redundancy is present.
ptime: See [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
maxptime: See [<a href="./rfc4566" title=""SDP: Session Description Protocol"">RFC4566</a>].
Encoding considerations:
This media type is framed and binary; see <a href="./rfc4288#section-4.8">Section 4.8 of RFC 4288</a>
[<a href="./rfc4288" title=""Media Type Specifications and Registration Procedures"">RFC4288</a>].
Security considerations:
See <a href="./rfc5993#section-10">Section 10 of RFC 5993</a>.
Interoperability considerations:
The media subtype name contains "-08" to avoid potential conflict
with any earlier drafts of GSM-HR RTP payload types that aren't
bit-compatible.
<span class="grey">Duan, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
Published specifications:
<a href="./rfc5993">RFC 5993</a>, 3GPP TS 46.002
Applications that use this media type:
Real-time audio applications like voice over IP and
teleconference.
Additional information: none
Person & email address to contact for further information:
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Intended usage: COMMON
Restrictions on usage:
This media type depends on RTP framing, and hence is only defined
for transfer via RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>]. Transport within other framing
protocols is not defined at this time.
Authors:
Xiaodong Duan <duanxiaodong@chinamobile.com>
Shuaiyu Wang <wangshuaiyu@chinamobile.com>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ingemar Johansson <ingemar.s.johansson@ericsson.com>
Karl Hellwig <karl.hellwig@ericsson.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 to 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 GSM-HR codec, the mapping
is as follows:
o The media type ("audio") goes in SDP "m=" as the media name.
<span class="grey">Duan, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
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 8000,
and the encoding parameters (number of channels) MUST either be
explicitly set to 1 or omitted, implying a default value of 1.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
o 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.
<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>. Offer/Answer Considerations</span>
The following considerations apply when using SDP offer/answer
procedures to negotiate the use of GSM-HR payload in RTP:
o The SDP offerer and answerer MUST generate GSM-HR packets as
described by the offered parameters.
o In most cases, the parameters "maxptime" and "ptime" will not
affect interoperability; however, the setting of the parameters
can affect the performance of the application. The SDP offer/
answer handling of the "ptime" parameter is described in
[<a href="./rfc3264" title=""An Offer/Answer Model with Session Description Protocol (SDP)"">RFC3264</a>]. The "maxptime" parameter MUST be handled in the same
way.
o The parameter "max-red" is a stream property parameter. For
sendonly or sendrecv unicast media streams, the parameter declares
the limitation on redundancy that the stream sender will use. For
recvonly streams, it indicates the desired value for the stream
sent to the receiver. The answerer MAY change the value, but is
RECOMMENDED to use the same limitation as the offer declares. In
the case of multicast, the offerer MAY declare a limitation; this
SHALL be answered using the same value. A media sender using this
payload format is RECOMMENDED to always include the "max-red"
parameter. This information is likely to simplify the media
stream handling in the receiver. This is especially true if no
redundancy will be used, in which case "max-red" is set to 0.
o Any unknown media type parameter in an offer SHALL be removed in
the answer.
<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>. Declarative SDP Considerations</span>
In declarative usage, like SDP in the Real Time Streaming Protocol
(RTSP) [<a href="./rfc2326" title=""Real Time Streaming Protocol (RTSP)"">RFC2326</a>] or the Session Announcement Protocol (SAP)
[<a href="./rfc2974" title=""Session Announcement Protocol"">RFC2974</a>], the parameters SHALL be interpreted as follows:
<span class="grey">Duan, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
o The stream property parameter ("max-red") is declarative, and a
participant MUST follow what is declared for the session. In this
case, it means that the receiver MUST be prepared to allocate
buffer memory for the given redundancy. Any transmissions MUST
NOT use more redundancy than what has been declared. More than
one configuration may be provided if necessary by declaring
multiple RTP payload types; however, the number of types should be
kept small.
o Any "maxptime" and "ptime" values should be selected with care to
ensure that the session's participants can achieve reasonable
performance.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
One media type (audio/GSM-HR-08) has been defined, and it has been
registered in the media types registry; see <a href="#section-7.1">Section 7.1</a>.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Congestion Control</span>
The general congestion control considerations for transporting RTP
data apply; see RTP [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] and any applicable RTP profiles, e.g.,
"RTP/AVP" [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>].
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 hence the header overhead,
at the expense of increased delay and reduced error robustness. If
forward error correction (FEC) is used, the amount of FEC-induced
redundancy needs to be regulated such that the use of FEC itself does
not cause a congestion problem.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</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, and integrity of the RTP packets through a suitable
cryptographic integrity protection mechanism. 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 at least source
authentication capable of determining whether or not an RTP packet is
from a member of the RTP session.
<span class="grey">Duan, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
Note that the appropriate mechanism to provide security to RTP and
payloads following this may vary. It is dependent on the
application, the transport, and the signaling protocol employed.
Therefore, a single mechanism is not sufficient, although if
suitable, the 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>] (e.g.,
for RTP over TCP), but other alternatives may also exist.
This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational
complexity for packet processing, and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data; nor
does the RTP payload format contain any active content.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgements</span>
The authors would like to thank Xiaodong Duan, Shuaiyu Wang, Rocky
Wang, and Ying Zhang for their initial work in this area. Many
thanks also go to Tomas Frankkila for useful input and comments.
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-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-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-RFC5405">RFC5405</a>] Eggert, L. and G. Fairhurst, "Unicast UDP Usage
Guidelines for Application Designers", <a href="https://www.rfc-editor.org/bcp/bcp145">BCP 145</a>, <a href="./rfc5405">RFC 5405</a>,
November 2008.
<span class="grey">Duan, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
[<a id="ref-TS46.002">TS46.002</a>] 3GPP, "Half rate speech; Half rate speech processing
functions", 3GPP TS 46.002, June 2007, <<a href="http://www.3gpp.org/ftp/Specs/archive/46_series/46.002/46002-700.zip">http://</a>
<a href="http://www.3gpp.org/ftp/Specs/archive/46_series/46.002/46002-700.zip">www.3gpp.org/ftp/Specs/archive/46_series/46.002/</a>
<a href="http://www.3gpp.org/ftp/Specs/archive/46_series/46.002/46002-700.zip">46002-700.zip</a>>.
[<a id="ref-TS46.020">TS46.020</a>] 3GPP, "Half rate speech; Half rate speech transcoding",
3GPP TS 46.020, June 2007, <<a href="http://www.3gpp.org/ftp/Specs/archive/46_series/46.020/46020-700.zip">http://www.3gpp.org/ftp/</a>
<a href="http://www.3gpp.org/ftp/Specs/archive/46_series/46.020/46020-700.zip">Specs/archive/46_series/46.020/46020-700.zip</a>>.
<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>. Informative References</span>
[<a id="ref-RFC2198">RFC2198</a>] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data",
<a href="./rfc2198">RFC 2198</a>, September 1997.
[<a id="ref-RFC2326">RFC2326</a>] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", <a href="./rfc2326">RFC 2326</a>, April 1998.
[<a id="ref-RFC2974">RFC2974</a>] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", <a href="./rfc2974">RFC 2974</a>, October 2000.
[<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-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-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-RFC4855">RFC4855</a>] Casner, S., "Media Type Registration of RTP Payload
Formats", <a href="./rfc4855">RFC 4855</a>, February 2007.
[<a id="ref-RFC5109">RFC5109</a>] Li, A., "RTP Payload Format for Generic Forward Error
Correction", <a href="./rfc5109">RFC 5109</a>, December 2007.
[<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">Duan, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5993">RFC 5993</a> RTP Payload Format for GSM-HR October 2010</span>
Authors' Addresses
Xiaodong Duan
China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053
P.R. China
EMail: duanxiaodong@chinamobile.com
Shuaiyu Wang
China Mobile Communications Corporation
53A, Xibianmennei Ave., Xuanwu District
Beijing, 100053
P.R. China
EMail: wangshuaiyu@chinamobile.com
Magnus Westerlund
Ericsson AB
Farogatan 6
Stockholm, SE-164 80
Sweden
Phone: +46 8 719 0000
EMail: magnus.westerlund@ericsson.com
Karl Hellwig
Ericsson AB
Ericsson Allee 1
52134 Herzogenrath
Germany
Phone: +49 2407 575-2054
EMail: karl.hellwig@ericsson.com
Ingemar Johansson
Ericsson AB
Laboratoriegrand 11
SE-971 28 Lulea
Sweden
Phone: +46 73 0783289
EMail: ingemar.s.johansson@ericsson.com
Duan, et al. Standards Track [Page 18]
</pre>
|
