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
|
<pre>Network Working Group Q. Xie, Ed.
Request for Comments: 3557 Motorola, Inc.
Category: Standards Track July 2003
<span class="h1">RTP Payload Format for</span>
European Telecommunications Standards Institute (ETSI) European Standard
ES 201 108 Distributed Speech Recognition Encoding
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) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies an RTP payload format for encapsulating
European Telecommunications Standards Institute (ETSI) European
Standard (ES) 201 108 front-end signal processing feature streams for
distributed speech recognition (DSR) systems.
<span class="grey">Xie Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
Table of Contents
<a href="#section-1">1</a>. Conventions and Acronyms . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2.1">2.1</a>. ETSI ES 201 108 DSR Front-end Codec. . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Typical Scenarios for Using DSR Payload Format . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. ES 201 108 DSR RTP Payload Format. . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Consideration on Number of FPs in Each RTP Packet. . . . <a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Support for Discontinuous Transmission . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Frame Pair Formats . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. Format of Speech and Non-speech FPs. . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.2">4.2</a>. Format of Null FP. . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. RTP header usage . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5">5</a>. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5.1">5.1</a>. Mapping MIME Parameters into SDP . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-7">7</a>. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-8">8</a>. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-10">10</a>. IPR Notices. . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-11">11</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-12">12</a>. Editor's Address . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-13">13</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Conventions and Acronyms</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>].
The following acronyms are used in this document:
DSR - Distributed Speech Recognition
ETSI - the European Telecommunications Standards Institute
FP - Frame Pair
DTX - Discontinuous Transmission
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Introduction</span>
Motivated by technology advances in the field of speech recognition,
voice interfaces to services (such as airline information systems,
unified messaging) are becoming more prevalent. In parallel, the
popularity of mobile devices has also increased dramatically.
<span class="grey">Xie Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
However, the voice codecs typically employed in mobile devices were
designed to optimize audible voice quality and not speech recognition
accuracy, and using these codecs with speech recognizers can result
in poor recognition performance. For systems that can be accessed
from heterogeneous networks using multiple speech codecs, recognition
system designers are further challenged to accommodate the
characteristics of these differences in a robust manner. Channel
errors and lost data packets in these networks result in further
degradation of the speech signal.
In traditional systems as described above, the entire speech
recognizer lies on the server. It is forced to use incoming speech
in whatever condition it arrives after the network decodes the
vocoded speech. To address this problem, we use a distributed speech
recognition (DSR) architecture. In such a system, the remote device
acts as a thin client, also known as the front-end, in communication
with a speech recognition server, also called a speech engine. The
remote device processes the speech, compresses the data, and adds
error protection to the bitstream in a manner optimal for speech
recognition. The speech engine then uses this representation
directly, minimizing the signal processing necessary and benefiting
from enhanced error concealment.
To achieve interoperability with different client devices and speech
engines, a common format is needed. Within the "Aurora" DSR working
group of the European Telecommunications Standards Institute (ETSI),
a payload has been defined and was published as a standard [<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>]
in February 2000.
For voice dialogues between a caller and a voice service, low latency
is a high priority along with accurate speech recognition. While
jitter in the speech recognizer input is not particularly important,
many issues related to speech interaction over an IP-based connection
are still relevant. Therefore, it is desirable to use the DSR
payload in an RTP-based session.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> ETSI ES 201 108 DSR Front-end Codec</span>
The ETSI Standard ES 201 108 for DSR [<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>] defines a signal
processing front-end and compression scheme for speech input to a
speech recognition system. Some relevant characteristics of this
ETSI DSR front-end codec are summarized below.
The coding algorithm, a standard mel-cepstral technique common to
many speech recognition systems, supports three raw sampling rates: 8
kHz, 11 kHz, and 16 kHz. The mel-cepstral calculation is a frame-
based scheme that produces an output vector every 10 ms.
<span class="grey">Xie Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
After calculation of the mel-cepstral representation, the
representation is first quantized via split-vector quantization to
reduce the data rate of the encoded stream. Then, the quantized
vectors from two consecutive frames are put into an FP, as described
in more detail in <a href="#section-4.1">Section 4.1</a>.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Typical Scenarios for Using DSR Payload Format</span>
The diagrams in Figure 1 show some typical use scenarios of the ES
201 108 DSR RTP payload format.
+--------+ +----------+
|IP USER | IP/UDP/RTP/DSR |IP SPEECH |
|TERMINAL|-------------------->| ENGINE |
| | | |
+--------+ +----------+
a) IP user terminal to IP speech engine
+--------+ DSR over +-------+ +----------+
| Non-IP | Circuit link | | IP/UDP/RTP/DSR |IP SPEECH |
| USER |:::::::::::::::>|GATEWAY|--------------->| ENGINE |
|TERMINAL| ETSI payload | | | |
+--------+ format +-------+ +----------+
b) non-IP user terminal to IP speech engine via a gateway
+--------+ +-------+ DSR over +----------+
|IP USER | IP/UDP/RTP/DSR | | circuit link | Non-IP |
|TERMINAL|----------------->|GATEWAY|::::::::::::::::>| SPEECH |
| | | | ETSI payload | ENGINE |
+--------+ +-------+ format +----------+
c) IP user terminal to non-IP speech engine via a gateway
Figure 1: Typical Scenarios for Using DSR Payload Format.
For the different scenarios in Figure 1, the speech recognizer always
resides in the speech engine. A DSR front-end encoder inside the
User Terminal performs front-end speech processing and sends the
resultant data to the speech engine in the form of "frame pairs"
(FPs). Each FP contains two sets of encoded speech vectors
representing 20ms of original speech.
<span class="grey">Xie Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. ES 201 108 DSR RTP Payload Format</span>
An ES 201 108 DSR RTP payload datagram consists of a standard RTP
header [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] followed by a DSR payload. The DSR payload itself
is formed by concatenating a series of ES 201 108 DSR FPs (defined in
<a href="#section-4">Section 4</a>).
FPs are always packed bit-contiguously into the payload octets
beginning with the most significant bit. For ES 201 108 front-end,
the size of each FP is 96 bits or 12 octets (see Sections <a href="#section-4.1">4.1</a> and
4.2). This ensures that a DSR payload will always end on an octet
boundary.
The following example shows a DSR RTP datagram carrying a DSR payload
containing three 96-bit-long FPs (bit 0 is the MSB):
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 in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] /
\ \
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ +
| FP #1 (96 bits) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| FP #2 (96 bits) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| FP #3 (96 bits) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. An example of an ES 201 108 DSR RTP payload.
<span class="grey">Xie Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Consideration on Number of FPs in Each RTP Packet</span>
The number of FPs per payload packet should be determined by the
latency and bandwidth requirements of the DSR application using this
payload format. In particular, using a smaller number of FPs per
payload packet in a session will result in lowered bandwidth
efficiency due to the RTP/UDP/IP header overhead, while using a
larger number of FPs per packet will cause longer end-to-end delay
and hence increased recognition latency. Furthermore, carrying a
larger number of FPs per packet will increase the possibility of
catastrophic packet loss; the loss of a large number of consecutive
FPs is a situation most speech recognizers have difficulty dealing
with.
It is therefore RECOMMENDED that the number of FPs per DSR payload
packet be minimized, subject to meeting the application's
requirements on network bandwidth efficiency. RTP header compression
techniques, such as those defined in [<a href="./rfc2508" title=""Compressing IP/UDP/RTP Headers for Low-Speed Serial Links"">RFC2508</a>] and [<a href="./rfc3095" title=""RObust Header Compression (ROHC): Framework and four profiles"">RFC3095</a>], should
be considered to improve network bandwidth efficiency.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Support for Discontinuous Transmission</span>
The DSR RTP payloads may be used to support discontinuous
transmission (DTX) of speech, which allows that DSR FPs are sent only
when speech has been detected at the terminal equipment.
In DTX a set of DSR frames coding an unbroken speech segment
transmitted from the terminal to the server is called a transmission
segment. A DSR frame inside such a transmission segment can be
either a speech frame or a non-speech frame, depending on the nature
of the section of the speech signal it represents.
The end of a transmission segment is determined at the sending end
equipment when the number of consecutive non-speech frames exceeds a
pre-set threshold, called the hangover time. A typical value used
for the hangover time is 1.5 seconds.
After all FPs in a transmission segment are sent, the front-end
SHOULD indicate the end of the current transmission segment by
sending one or more Null FPs (defined in <a href="#section-4.2">Section 4.2</a>).
<span class="grey">Xie Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Frame Pair Formats</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Format of Speech and Non-speech FPs</span>
The following mel-cepstral frame MUST be used, as defined in
[<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>]:
As defined in [<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>], pairs of the quantized 10ms mel-cepstral
frames MUST be grouped together and protected with a 4-bit CRC,
forming a 92-bit long FP:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame #1 (44 bits) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Frame #2 (44 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | CRC |0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of each frame is 44 bits representing 10ms of voice. The
following mel-cepstral frame formats MUST be used when forming an FP:
Frame #1 in FP:
===============
(MSB) (LSB)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(2,3) | idx(0,1) | Octet 1
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(4,5) | idx(2,3) (cont) : Octet 2
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(6,7) |idx(4,5)(cont) Octet 3
+-----+-----+-----+-----+-----+-----+-----+-----+
idx(10,11) | idx(8,9) | Octet 4
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(12,13) | idx(10,11) (cont) : Octet 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(12,13) (cont) : Octet 6/1
+-----+-----+-----+-----+
<span class="grey">Xie Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
Frame #2 in FP:
===============
(MSB) (LSB)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+
: idx(0,1) | Octet 6/2
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(2,3) |idx(0,1)(cont) Octet 7
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(6,7) | idx(4,5) | Octet 8
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(8,9) | idx(6,7) (cont) : Octet 9
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(10,11) |idx(8,9)(cont) Octet 10
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(12,13) | Octet 11
+-----+-----+-----+-----+-----+-----+-----+-----+
Therefore, each FP represents 20ms of original speech. Note, as
shown above, each FP MUST be padded with 4 zeros to the end in order
to make it aligned to the 32-bit word boundary. This makes the size
of an FP 96 bits, or 12 octets. Note, this padding is separate from
padding indicated by the P bit in the RTP header.
The 4-bit CRC MUST be calculated using the formula defined in 6.2.4
in [<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>]. The definition of the indices and the determination of
their value are also described in [<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>].
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> Format of Null FP</span>
A Null FP for the ES 201 108 front-end codec is defined by setting
the content of the first and second frame in the FP to null (i.e.,
filling the first 88 bits of the FP with 0's). The 4-bit CRC MUST be
calculated the same way as described in 6.2.4 in [<a href="#ref-ES201108" title=""Speech Processing, Transmission and Quality Aspects (STQ); Distributed Speech Recognition; Front-end Feature Extraction Algorithm; Compression Algorithms,"">ES201108</a>], and 4
zeros MUST be padded to the end of the Null FP to make it 32-bit word
aligned.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</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 FP in the packet. The timestamp clock
frequency is the same as the sampling frequency, so the timestamp
unit is in samples.
<span class="grey">Xie Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
As defined by ES 201 108 front-end codec, the duration of one FP is
20 ms, corresponding to 160, 220, or 320 encoded samples with
sampling rate of 8, 11, or 16 kHz being used at the front-end,
respectively. Thus, the timestamp is increased by 160, 220, or 320
for each consecutive FP, respectively.
The DSR payload for ES 201 108 front-end codes is always an integral
number of octets. If additional padding is required for some other
purpose, then the P bit in the RTP in the header may be set and
padding appended as specified in [<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>].
The RTP header marker bit (M) should be set following the general
rules defined in [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>].
The assignment of an RTP payload type for this new packet format is
outside the scope of this document, and will not be specified here.
It is expected that the RTP profile under which this payload format
is being used will assign a payload type for this encoding or specify
that the payload type is to be bound dynamically.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
One new MIME subtype registration is required for this payload type,
as defined below.
This section also defines the optional parameters that may be used to
describe a DSR session. The parameters are defined here as part of
the MIME subtype registration. A mapping of the parameters into the
Session Description Protocol (SDP) [<a href="./rfc2327" title=""SDP: Session Description Protocol"">RFC2327</a>] is also provided in 5.1
for those applications that use SDP.
Media Type name: audio
Media subtype name: dsr-es201108
Required parameters: none
Optional parameters:
rate: Indicates the sample rate of the speech. Valid values include:
8000, 11000, and 16000. If this parameter is not present, 8000
sample rate is assumed.
maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time shall be
calculated as the sum of the time the media present in the packet
represents. The time SHOULD be a multiple of the frame pair size
(i.e., one FP <-> 20ms).
<span class="grey">Xie Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
If this parameter is not present, maxptime is assumed to be 80ms.
Note, since the performance of most speech recognizers are
extremely sensitive to consecutive FP losses, if the user of the
payload format expects a high packet loss ratio for the session,
it MAY consider to explicitly choose a maxptime value for the
session that is shorter than the default value.
ptime: see <a href="./rfc2327">RFC2327</a> [<a href="./rfc2327" title=""SDP: Session Description Protocol"">RFC2327</a>].
Encoding considerations : This type is defined for transfer via RTP
[<a href="./rfc3550" title=""RTP: A Transport Protocol for Real-Time Applications"">RFC3550</a>] as described in Sections <a href="#section-3">3</a> and <a href="#section-4">4</a> of <a href="./rfc3557">RFC 3557</a>.
Security considerations : See <a href="./rfc3557#section-6">Section 6 of RFC 3557</a>.
Person & email address to contact for further information:
Qiaobing.Xie@motorola.com
Intended usage: COMMON. It is expected that many VoIP applications
(as well as mobile applications) will use this type.
Author/Change controller:
Qiaobing.Xie@motorola.com
IETF Audio/Video transport working group
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a> Mapping MIME Parameters into SDP</span>
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[<a href="./rfc2327" title=""SDP: Session Description Protocol"">RFC2327</a>], which is commonly used to describe RTP sessions. When SDP
is used to specify sessions employing ES 201 018 DSR codec, the
mapping is as follows:
o The MIME type ("audio") goes in SDP "m=" as the media name.
o The MIME subtype ("dsr-es201108") goes in SDP "a=rtpmap" as the
encoding name.
o The optional parameter "rate" also goes in "a=rtpmap" as clock
rate.
o The optional parameters "ptime" and "maxptime" go in the SDP
"a=ptime" and "a=maxptime" attributes, respectively.
<span class="grey">Xie Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
Example of usage of ES 201 108 DSR:
m=audio 49120 RTP/AVP 101
a=rtpmap:101 dsr-es201108/8000
a=maxptime:40
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Implementations using the payload 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 the RTP profile [<a href="./rfc3551" title=""RTP Profile for Audio and Video Conferences with Minimal Control"">RFC3551</a>]. This payload
does not specify any different security services.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Contributors</span>
The following individuals contributed to the design of this payload
format and the writing of this document: Q. Xie (Motorola), D. Pearce
(Motorola), S. Balasuriya (Motorola), Y. Kim (VerbalTek), S. H. Maes
(IBM), and, Hari Garudadri (Qualcomm).
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The design presented here benefits greatly from an earlier work on
DSR RTP payload design by Jeff Meunier and Priscilla Walther. The
authors also wish to thank Brian Eberman, John Lazzaro, Magnus
Westerlund, Rainu Pierce, Priscilla Walther, and others for their
review and valuable comments on this document.
<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-ES201108">ES201108</a>] European Telecommunications Standards Institute (ETSI)
Standard ES 201 108, "Speech Processing, Transmission
and Quality Aspects (STQ); Distributed Speech
Recognition; Front-end Feature Extraction Algorithm;
Compression Algorithms," Ver. 1.1.2, April 11, 2000.
[<a id="ref-RFC3550">RFC3550</a>] Schulzrinne, H., Casner, S., Jacobson, V. and R.
Frederick, "RTP: A Transport Protocol for Real-Time
Applications", <a href="./rfc3550">RFC 3550</a>, July 2003.
[<a id="ref-RFC2026">RFC2026</a>] Bradner, S., "The Internet Standards Process -- Revision
3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.
[<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.
<span class="grey">Xie Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
[<a id="ref-RFC2327">RFC2327</a>] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", <a href="./rfc2327">RFC 2327</a>, April 1998.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a> Informative References</span>
[<a id="ref-RFC3551">RFC3551</a>] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
and Video Conferences with Minimal Control", <a href="./rfc3551">RFC 3551</a>,
July 2003.
[<a id="ref-RFC2508">RFC2508</a>] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", <a href="./rfc2508">RFC 2508</a>, February
1999.
[<a id="ref-RFC3095">RFC3095</a>] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E, Hakenberg, R., Koren, T.,
Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust
Header Compression (ROHC): Framework and four profiles",
<a href="./rfc3095">RFC 3095</a>, July 2001.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. IPR Notices</span>
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in <a href="https://www.rfc-editor.org/bcp/bcp11">BCP-11</a>. Copies of
claims of rights made be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
<span class="grey">Xie Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Authors' Addresses</span>
David Pearce
Motorola Labs
UK Research Laboratory
Jays Close
Viables Industrial Estate
Basingstoke, HANTS, RG22 4PD
Phone: +44 (0)1256 484 436
EMail: bdp003@motorola.com
Senaka Balasuriya
Motorola, Inc.
600 U.S Highway 45
Libertyville, IL 60048, USA
Phone: +1-847-523-0440
EMail: Senaka.Balasuriya@motorola.com
Yoon Kim
VerbalTek, Inc.
2921 Copper Rd.
Santa Clara, CA 95051
Phone: +1-408-768-4974
EMail: yoonie@verbaltek.com
Stephane H. Maes, PhD,
Oracle
500 Oracle Parkway, M/S 4op634
Redwood City, CA 94065 USA
Phone: +1-650-607-6296.
EMail: stephane.maes@oracle.com
Hari Garudadri
Qualcomm Inc.
5775, Morehouse Dr.
San Diego, CA 92121-1714, USA
Phone: +1-858-651-6383
EMail: hgarudad@qualcomm.com
<span class="grey">Xie Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Editor's Address</span>
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004, USA
Phone: +1-847-632-3028
EMail: Qiaobing.Xie@motorola.com
<span class="grey">Xie Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3557">RFC 3557</a> RTP Payload Format for DSR ES 201 108 July 2003</span>
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Xie Standards Track [Page 15]
</pre>
|
