| 0 | 0 | 0 | 0 | PC-CRC |Cidx2|Cidx1| Octet 14
+-----+-----+-----+-----+-----+-----+-----+-----+
The 4-bit CRC and the 2-bit PC-CRC in the FP MUST be calculated using
the formula (including the bit-order rules) defined in 6.2.4 in [2].
Therefore, each FP represents 20ms of original speech. Note, as
shown above, each FP MUST be padded with 4 zeros to the MSB 4 bits of
the last octet in order to make the FP aligned to the octet boundary.
This makes the total size of an FP 112 bits, or 14 octets. Note,
this padding is separate from padding indicated by the P bit in the
RTP header.
3.3.1.2. Format of Null FP
A Null FP for the ES 202 211 front-end codec is defined by setting
all the 112 bits of the FP with zeros. Null FPs are sent to mark the
end of a transmission segment. Details on transmission segment and
the use of Null FPs can be found in RFC 3557 [10].
3.4. Payload Format for ES 202 212 DSR
Similar to other ETSI DSR front-end encoding schemes, the encoded DSR
feature stream of ES 202 212 is transmitted in a sequence of FPs,
where each FP represents two consecutive original voice frames.
An ES 202 212 DSR RTP payload datagram is very similar to that
defined in Section 3 of RFC 3557 [10], i.e., a standard RTP header
followed by a DSR payload containing a series of DSR FPs.
The size of each ES 202 212 FP is 112 bits or 14 octets, as defined
in the following sections. This ensures that an ES 202 212 DSR RTP
payload will always end on an octet boundary.
3.4.1. Frame Pair Formats
3.4.1.1. Format of Speech and Non-speech FPs
The following mel-cepstral frame MUST be used, as defined in Section
7.2.4 of [3]:
Immediately following two frames (Frame #1 and Frame #2) worth of
codebook indices (or 88 bits), there is a 4-bit CRC calculated on
these 88 bits. The pitch indices of the first frame (Pidx1: 7 bits)
and the second frame (Pidx2: 5 bits) of the frame pair then follow.
The class indices of the two frames in the frame pair worth 1 bit
each next follow (Cidx1 and Cidx2). Finally, a 2-bit CRC (PC-CRC)
calculated on the pitch and class bits (total: 14 bits) of the frame
pair is included. The total number of bits in frame pair packet is
therefore 44 + 44 + 4 + 7 + 5 + 1 + 1 + 2 = 108. At the end, each FP
MUST be padded with 4 zeros to the MSB 4 bits of the last octet in
order to make the FP aligned to the octet boundary. The padding
brings the total size of a FP to 112 bits, or 14 octets. Note that
this padding is separate from padding indicated by the P bit in the
RTP header.
The following diagram shows a complete ES 202 212 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)| VAD | idx(8,9) | Octet 4
+-----+-----+-----+-----+-----+-----+-----+-----+
: idx(12,13) | idx(10,11) (cont) : Octet 5
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(12,13) (cont) : Octet 6/1
+-----+-----+-----+-----+
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) | VAD |idx(8,9)(cont) Octet 10
+-----+-----+-----+-----+-----+-----+-----+-----+
| idx(12,13) | Octet 11
+-----+-----+-----+-----+-----+-----+-----+-----+
CRC for Frame #1 and Frame #2 in FP:
====================================
(MSB) (LSB)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+
| CRC | Octet 12/1
+-----+-----+-----+-----+
Extension information and padding in FP:
========================================
(MSB) (LSB)
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+
: Pidx1 | Octet 12/2
+-----+-----+-----+-----+-----+-----+-----+-----+
| Pidx2 | Pidx1 (cont) : Octet 13
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 0 | 0 | 0 | PC-CRC |Cidx2|Cidx1| Octet 14
+-----+-----+-----+-----+-----+-----+-----+-----+
The codebook indices, VAD flag, pitch index, and class index are
specified in Section 6 of [3]. The 4-bit CRC and the 2-bit PC-CRC in
the FP MUST be calculated using the formula (including the bit-order
rules) defined in 7.2.4 in [3].
3.4.1.2. Format of Null FP
A Null FP for the ES 202 212 front-end codec is defined by setting
all 112 bits of the FP with zeros. Null FPs are sent to mark the end
of a transmission segment. Details on transmission segments and the
use of Null FPs can be found in RFC 3557 [10].
4. IANA Considerations
For each of the three ETSI DSR front-end codecs covered in this
document, a new MIME subtype registration has been registered by the
IANA for the corresponding payload type, as described below.
Media Type name: audio
Media subtype names:
dsr-es202050 (for ES 202 050 front-end)
dsr-es202211 (for ES 202 211 front-end)
dsr-es202212 (for ES 202 212 front-end)
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: see RFC 3267 [7]. 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 RFC 2327 [5].
Encoding considerations: These types are defined for transfer via RTP
[8] as described in Section 3 of RFC 4060.
Security considerations: See Section 5 of RFC 4060.
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: Qiaobing.Xie@motorola.com
Change controller: IETF Audio/Video transport working group
4.1. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[5], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing ES 202 050, ES 202 211, or ES 202
212 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-es202050", "dsr-es202211", or
"dsr-es202212") goes in SDP "a=rtpmap" as the encoding name.
o The optional parameter "rate" also goes in "a=rtpmap" as clock
rate. If no rate is given, then the default value (i.e., 8000) is
used in SDP.
o The optional parameters "ptime" and "maxptime" go in the SDP
"a=ptime" and "a=maxptime" attributes, respectively.
Example of usage of ES 202 050 DSR:
m=audio 49120 RTP/AVP 101
a=rtpmap:101 dsr-es202050/8000
a=maxptime:40
Example of usage of ES 202 211 DSR:
m=audio 49120 RTP/AVP 101
a=rtpmap:101 dsr-es202211/8000
a=maxptime:40
Example of usage of ES 202 212 DSR:
m=audio 49120 RTP/AVP 101
a=rtpmap:101 dsr-es202212/8000
a=maxptime:40
4.2. Usage in Offer/Answer
All SDP parameters in this payload format are declarative, and all
reasonable values are expected to be supported. Thus, the standard
usage of Offer/Answer as described in RFC 3264 [6] should be
followed.
4.3. Congestion Control
Congestion control for RTP MUST be used in accordance with RFC 3550
[8], and in any applicable RTP profile, e.g., RFC 3551 [9].
5. Security Considerations
Implementations using the payload defined in this specification are
subject to the security considerations discussed in the RTP
specification RFC 3550 [8] and any RTP profile, e.g., RFC 3551 [9].
This payload does not specify any different security services.
6. Acknowledgments
The design presented here is based on that of RFC 3557 [10]. The
authors wish to thank Magnus Westerlund and others for their reviews
and comments.
7. References
7.1. Normative References
[1] European Telecommunications Standards Institute (ETSI) Standard
ES 202 050, "Speech Processing, Transmission and Quality
Aspects (STQ); Distributed Speech Recognition; Advanced Front-
end Feature Extraction Algorithm; Compression Algorithms",
http://pda.etsi.org/pda/.
[2] European Telecommunications Standards Institute (ETSI) Standard
ES 202 211, "Speech Processing, Transmission and Quality
Aspects (STQ); Distributed Speech Recognition; Extended front-
end feature extraction algorithm; Compression algorithms; Back-
end speech reconstruction algorithm", http://pda.etsi.org/pda/.
[3] European Telecommunications Standards Institute (ETSI) Standard
ES 202 212, "Speech Processing, Transmission and Quality
aspects (STQ); Distributed speech recognition; Extended
advanced front-end feature extraction algorithm; Compression
algorithms; Back-end speech reconstruction algorithm",
http://pda.etsi.org/pda/.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"Real-Time Transport Protocol (RTP) Payload Format and File
Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267,
June 2002.
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[9] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[10] Xie, Q., "RTP Payload Format for European Telecommunications
Standards Institute (ETSI) European Standard ES 201 108
Distributed Speech Recognition Encoding", RFC 3557, July 2003.
7.2. Informative References
[11] 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",
http://pda.etsi.org/pda/.
Authors’ Addresses
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004
US
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
David Pearce
Motorola Labs
UK Research Laboratory
Jays Close
Viables Industrial Estate
Basingstoke, HANTS RG22 4PD
UK
Phone: +44 (0)1256 484 436
EMail: bdp003@motorola.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.