| Audio/Video Transport | Y.H. Hiwasaki |
| Internet-Draft | H.O. Ohmuro |
| Intended status: Standards Track | NTT Corporation |
| Expires: October 31, 2009 | May 2009 |
RTP payload format for mU-law EMbedded Codec for Low-delay IP communication (UEMCLIP) speech codec
This document describes the RTP payload format of a mU-law EMbedded Coder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies the payload format for sending "mU-law EMbedded Coder for Low-delay IP communication" (UEMCLIP) encoded speech using the Real-time Transport Protocol (RTP) [RFC3550]. UEMCLIP is a proprietary codec which enhances u-law ITU-T G.711 [ITU-T G.711], and designed to help the market for smooth transition towards the forthcoming wideband communication environment while achieving a very little media transcoding load with the existing terminals, in which the implementation of G.711 is mandatory.
It should be noted that, generally speaking, codecs are negotiated and changed using an SDP exchange. Also, [RFC3550] defines general RTP mixer and translator models, where media transcoding may not take place at the node. For those cases, the design concept of the embedded structure is not useful. However, there are other cases when costly transcoding is unavoidable in commonly deployed types of Multi-point Control Units (MCUs) which terminates media and RTCP packets [RFC5117], and when narrowband and wideband terminals co-exist. This embedded bitstream structure can reduce the media transcoding to a simple bitstream truncation.
The background and the basic idea of the media format is described in Section 2. The details of the payload format are given in Section 3. The transcoding issues with G.711 are discussed in Section 4, and the considerations for congestion control are in Section 5. In Section 6, the payload format parameters for a media type registration for UEMCLIP RTP payload format and SDP mappings are provided. The security considerations and IANA considerations are dealt in Section 7 and Section 8, respectively.
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 [RFC2119].
UEMCLIP is an enhanced version of u-law ITU-T G.711, otherwise known as PCMU [RFC4856]. It is targeted at Voice over Internet Protocol (VoIP) applications, and its main goal is to provide a wideband communication platform that is highly interoperable with existing terminals equipped with G.711, and to stimulate the market to gradually shift to using wideband communication. In widely deployed multi-point conferencing systems, the packets usually go through RTCP-terminating MCUs, "Topo-RTCP-terminating-MCU" as defined in [RFC5117]. Because the G.711 bitstream is embedded in the bitstream, costly media transcoding can be avoided in this case.
This document does not discuss the implementation details of the encoder and decoder, but only describes the bitstream format.
Because of its scalable nature, there are a number of sub-bitstreams (sub-layer) in a UEMCLIP bitstream. By choosing appropriate sub-layers, the codec can adapt to the following requirements: Table 1. The core layer is u-law G.711 at 64 kbit/s, and other two are quality and bandwidth enhancement layers with bit-rate of 16 kbit/s each.
The UEMCLIP codec operates at 20-ms frame, and includes three sub-coders as shown in
| Layer | Description | Bit-rate | Coding algorithm |
|---|---|---|---|
| a | G.711 core | 64 | u-law PCM |
| b | Lower-band enhancement | 16 | Time domain block quantization |
| c | Higher-band | 16 | MDCT block quantization |
Based on these sub-layers, UEMCLIP codec operates in four modes as shown in Table 2. Here, "Ch" is the number of channels and "Fs" is the sampling frequency in kHz. It should be noted that the current version only supports single channel operation and there might be future extensions with multi-channel capabilities. The absent Modes 2 and 5 are reserved for possible future extension to 32 kHz sampling modes. As the mode definition is expected to grow, any other modes not defined in this table MUST NOT be used for compatibility and interoperability reasons.
| Mode | Ch | Fs | Layer a | Layer b | Layer c | Bit-rate w/o headers [kbps] | Total bit-rate [kbps] |
|---|---|---|---|---|---|---|---|
| 0 | 1 | 8 | x | - | - | 64 | 67.2 |
| 1 | 1 | 16 | x | - | x | 80 | 84.0 |
| 2 | - | - | - | - | - | - | - |
| 3 | 1 | 8 | x | x | - | 80 | 84.0 |
| 4 | 1 | 16 | x | x | x | 96 | 100.8 |
| 5 | - | - | - | - | - | - | - |
UEMCLIP bitstream contains internal headers and other side-information apart from the layer data. This results in total bit-rate larger than the sum of the layers shown in the above table. The detail of the internal headers and auxiliary information are described in Section 3.3.1.
Defining the sampling frequency and the number of channels does not result in a singular mode, i.e., there can be multiple modes for the same sampling frequency or number of channels. The supported modes would differ between implementations, thus the sender and the receiver must negotiate what mode to use for transmission.
As an RTP payload, UEMCLIP bitstream can contain one or more frames as shown in Figure 1.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | one or more frames of UEMCLIP | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
UEMCLIP bitstream has a scalable structure, thus it is possible to reconstruct the signal by decoding a part of it. A UEMCLIP frame is composed of a main header (MH) followed by one or more (up to three) sub-layers (SL) as shown in Figure 2.
+--+-------+//-+
|MH| SL #1 |...|
+--+-------+//-+
As a sub-layer, the core layer, i.e., "Layer a", MUST always be included. It should be noted that the location of the core layer may or may not immediately follow MH field. The decoder MUST always refer to the layer indices for proper decoding because the order of the sub-layers is arbitrary.
The UEMCLIP bitstream does not explicitly include the following information: mode and sampling frequency (Fs). As described before, this information MUST be exchanged while establishing a connection, for example, by means of SDP.
Each RTP packet starts with a fixed RTP header, as explained in [RFC3550]. The following fields of the RTP fixed header used specifically for UEMCLIP streams are emphasized:
More than one UEMCLIP frame may be included in a single RTP packet by a sender. However, senders have the following additional restrictions:
It is RECOMMENDED that the number of frames contained within an RTP packet be consistent with the application. Since UEMCLIP is designed for telephony application where delay has a great impact on the quality, then fewer frames per packet for lower delay, is preferable.
In a UEMCLIP bitstream, all numbers are encoded in a network byte-order.
The main header (MH) is placed at the top of a frame and has size of 6 bytes. The content of the main header is shown in Figure 3.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MX | PC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PC(cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|R|V| PW1 |
|1|1|1| |
+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R2 |V| K |U| P1 |U| P2 | PW2 | |2| |2| |1| |2| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R3 | | | +-+-+-+-+-+-+-+-+
Sub-layer (SL) is a sub-header followed by layer bitstreams, as shown in Figure 6. The sub-header indicates the layer location and the number of bytes.
0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+ |CI |FI |QI |R4 | SB | LD ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+
Table 1, the layer indices are shown in Table 3.
For all the layers shown in
| Layer | CI | FI | QI |
|---|---|---|---|
| a | 0 | 0 | 0 |
| b | 0 | 0 | 1 |
| c | 0 | 1 | 0 |
As given in Section 2, u-law encoded G.711 bitstream (Layer a) is the core layer of a UEMCLIP bitstream, and is always embedded. This means that media transcoding from UEMCLIP bitstream to G.711 does not have to undergo decoding and re-encoding procedures, but simple extraction would suffice. However, this does not apply for the reverse procedure, i.e., transcoding from G.711 to UEMCLIP, because the auxiliary information in the main header (MH) must be assigned separately. It should be noted that this media transcoding is useful for a Media Translator (Topo-Media-Translator) or a Point to Multipoint Using RTCP Terminating MCU (Topo-RTCP-terminating-MCU) in [RFC5117] and all the requirements apply. This means that a transcoding device of this sort MUST rewrite RTCP packets, together with the RTP media packets.
The transcoding from UEMCLIP to u-law G.711 can be done easily by finding an appropriate sub-layer. Within a frame, the transcoder should look for a sub-layer with layer index "0x00", and subsequent LD which has size of SB*8 bits (UEMCLIP has a 20-ms frame thus, SB=160) are the actual G.711 bitstream data. It should be noted that transcoder should not always expect the core layer to be located right after the main header.
On the other hand, the transcoding from G.711 to UEMCLIP is not entirely straight-forward. Since there are no means to generate enhancement sub-layers, a G.711 bitstream can only be converted to UEMCLIP Mode 0 bitstream. If the original G.711 bitstream is encoded in A-law, it should first be converted to u-law to become the core layer. Because a UEMCLIP frame size is 20 ms, u-law encoded G.711 bitstream MUST be a 160-sample chunk to become a core layer. For the main header contents, when the UEMCLIP encoder is not available, it should follow the following guidelines.
For the core layer (i.e., u-law G.711 bitstream), it should have the following sub-layer header:
The general congestion control considerations for transporting RTP data also apply to UEMCLIP over RTP [RFC3550] as well as any applicable RTP profile like AVP [RFC3551].
The bandwidth of a UEMCLIP bitstream can be reduced by changing to lower-bit-rate modes. The embedded layer structure of UEMCLIP may help to control congestion, when dynamic mode changing (see Section 6.2.1) is available, and the range of modes is obtained by offer-answer negotiation as given in Section 6.3. It should be noted that this involves proper RTCP handling when the bit-rate is modified in an RTP translator or a mixer [RFC3550].
Packing more frames in each RTP payload can reduce the number of packets sent, and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay and reduced error robustness against packet losses. It should be treated with care because increased delay means reduced quality.
This registration is done using the template defined in [RFC4288] and following [RFC4855].
The media types audio/UEMCLIP are mapped to fields in the Session Description Protocol (SDP) [RFC4566] as follows:
Since UEMCLIP codec can operate in number of modes (bit-rates), it is desirable to specify the range of modes that an encoder or a decoder can operate at. When exchanging SDP messages, an offerer should specify all possible combination of mode numbers as arguments to "mode=" in "a=fmtp" line, delimited by commas ",". In case of specifying multiple modes, those SHOULD appear in the descending priority order.
Although UEMCLIP decoders SHOULD accept bitstreams in any modes, an implementation may fail to adopt to the dynamic mode changes during a session. For this reason, an application may choose to operate either with one fixed mode or with multiple modes that can be dynamically changed. If the mode is to be fixed and changes are not allowed, this can be indicated by specifying a single mode per payload type.
The mode numbers that can be specified in a payload type as arguments to "mode" are restricted by a combination of a clock rate and a number of audio channels. This is because SDP binds a payload type to a combination of a sampling frequency and a number of audio channels. Table 4 gives selectable mode numbers that attributed with clock rates. When mode specifications are not given at all, a payload type MUST default to a single mode using the default value specified in this table.
| Clock rate | Channels | Selectable modes | Default mode |
|---|---|---|---|
| 8000 | 1 | 0,3 | 0 |
| 16000 | 1 | 0,1,3,4 | 1 |
It should be noted that a mode attributed with a larger sampling frequency (Fs) is not used in conjunction with smaller clock rates specified in "a=rtpmap". This means that Modes 0 and 3 can be specified in a payload type having clock rate of both 8000 and 16000 in "a=rtpmap", but Modes 1 and 4 cannot be specified with one having clock rate of 8000.
The procedures related to exchanging SDP messages MUST follow [RFC3264]. The following is a detalied list on the semantics of using the UEMCLIP payload format in an offer-answer exchange.
v=0 o=john 51050101 51050101 IN IP4 offhost.example.com s=- c=IN IP4 offhost.example.com t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=4,1,3,0
When an offerer indicates that he/she wishes to dynamically switch between modes (0,1,3, and 4) during a session, an example of an offered SDP can be:
v=0 o=lena 549947322 549947322 IN IP4 anshost.example.org s=- c=IN IP4 anshost.example.org t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=1,0
When an answerer can only operate in Modes 1 and 0 but can dynamically switch between those modes during a session, an answerer MUST delete the entries of Mode 3 and 4, and answer back as:
v=0 o=lena 549947322 549947322 IN IP4 anshost.example.org s=- c=IN IP4 anshost.example.org t=0 0 m=audio 5004 RTP/AVP 96 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=1
On the other hand, when the answerer is capable of communicating either in Modes 1 or 0, and cannot switch between modes during a session, an example of such answer is as follows:
v=0 o=john 51050101 51050101 IN IP4 offhost.example.com s=- c=IN IP4 offhost.example.com t=0 0 m=audio 5004 RTP/AVP 96 97 a=rtpmap:96 UEMCLIP/16000/1 a=fmtp:96 mode=4 a=rtpmap:97 UEMCLIP/16000/1 a=fmtp:97 mode=1
v=0 o=lena 549947322 549947322 IN IP4 anshost.example.org s=- c=IN IP4 anshost.example.org t=0 0 m=audio 5004 RTP/AVP 97 a=rtpmap:97 UEMCLIP/16000/1 a=fmtp:97 mode=1
If an offerer does not want a mode change during a session but is capable of receiving either Modes 4 or 1 bitstreams, the SDP should somewhat look like:
v=0 o=kosuke 2890844730 2890844730 IN IP4 anotherhost.example.com s=- c=IN IP4 anotherhost.example.com t=0 0 m=audio 5004 RTP/AVP 96 a=ptime:60 a=rtpmap:96 UEMCLIP/16000/1
The "ptime" attribute is used to denote the desired packetization interval. When not specified, it SHOULD default to 20. Since UEMCLIP uses 20 msec frames, ptime values of multiples of 20 imply multiple frames per packet. In the example below, the ptime is set to 60, and this means that offerer wants to receive 3 frames in each packet. Section 6.2.1).
RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate profiles. This implies that confidentiality of the media streams is achieved by encryption unless the applicable profile specifies other means.
A potential denial-of-service threat exists for data encoding using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream that are complex to decode and cause the receiver output to become overloaded. However, UEMCLIP covered in this document do not exhibit any significant non-uniformity.
Another potential threats are memory attacks by illegal layer indices or byte numbers. The implementor of the decoder should always be aware that the indicated numbers may be corrupted and does not point to the right sub-layer and may force reading beyond the bitstream boundaries. It is advised that a decoder implementation rejects layers such indices.
It is requested that one new media subtype (audio/UEMCLIP) is registered by IANA. For details, see Section 6.1.
| [RFC5117] | Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008. |
| [ITU-T G.711 Appendix 1] | International Telecommunications Union, "Pulse code modulcation (PCM) of Voice Frequencies, Appendix I: A high quality low-complexity algorithm for packet loss concealment with G.711", ITU-T Recommendation G.711 Appendix I, September 1999. |