Network Working Group A. Sollaud
Internet-Draft France Telecom
Intended status: Standards Track April 9, 2008
Expires: October 11, 2008
RTP Payload Format for ITU-T Recommendation G.711.1
draft-ietf-avt-rtp-g711wb-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) G.711.1 audio codec. Two media type registrations are also
included.
Sollaud Expires October 11, 2008 [Page 1]
Internet-Draft RTP Payload Format for G.711.1 April 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . . . 4
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Dynamic Mode Payload Format . . . . . . . . . . . . . . . 5
4.1.1. Payload Header . . . . . . . . . . . . . . . . . . . . 5
4.1.2. Audio Data . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Fixed Mode Payload Format . . . . . . . . . . . . . . . . 6
5. Payload Format Parameters . . . . . . . . . . . . . . . . . . 7
5.1. PCMA-WB Media Type Registration . . . . . . . . . . . . . 7
5.2. PCMU-WB Media Type Registration . . . . . . . . . . . . . 8
5.3. Mapping to SDP Parameters . . . . . . . . . . . . . . . . 9
5.3.1. Offer-Answer Model Considerations . . . . . . . . . . 10
5.3.2. Declarative SDP Considerations . . . . . . . . . . . . 12
6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Sollaud Expires October 11, 2008 [Page 2]
Internet-Draft RTP Payload Format for G.711.1 April 2008
1. Introduction
The International Telecommunication Union (ITU-T) Recommendation
G.711.1 [1] is an embedded wideband extension of the Recommendation
G.711 [9] audio codec. This document specifies a payload format for
packetization of G.711.1 encoded audio signals into the Real-time
Transport Protocol (RTP).
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 RFC 2119 [2].
2. Background
G.711.1 is a G.711 embedded wideband speech and audio coding
algorithm operating at 64, 80, and 96 kbps. At 64 kbps, G.711.1 is
fully interoperable with G.711. Hence, an efficient deployment in
existing G.711 based VoIP infrastructures is foreseen.
The codec operates on 5 ms frames, and the default sampling rate is
16 kHz. Input and output at 8 kHz are also supported for narrowband
modes.
The encoder produces an embedded bitstream structured in three layers
corresponding to three available bit rates: 64, 80, and 96 kbps. The
bitstream can be truncated at the decoder side or by any component of
the communication system to adjust "on the fly" the bit rate to the
desired value.
The following table gives more details on these layers.
+-------+------------------------+---------+
| Layer | Description | Bitrate |
+-------+------------------------+---------+
| L0 | G.711 compatible | 64 kbps |
| L1 | narrowband enhancement | 16 kbps |
| L2 | wideband enhancement | 16 kbps |
+-------+------------------------+---------+
Table 1: Layers description
The combinations of these 3 layers results in the definition of 4
modes, as per the following table.
Sollaud Expires October 11, 2008 [Page 3]
Internet-Draft RTP Payload Format for G.711.1 April 2008
+------+----+----+----+------------+---------+
| Mode | L0 | L1 | L2 | Audio band | Bitrate |
+------+----+----+----+------------+---------+
| R1 | x | | | narrowband | 64 kbps |
| R2a | x | x | | narrowband | 80 kbps |
| R2b | x | | x | wideband | 80 kbps |
| R3 | x | x | x | wideband | 96 kbps |
+------+----+----+----+------------+---------+
Table 2: Modes description
3. RTP Header Usage
The format of the RTP header is specified in RFC 3550 [3]. The
payload format defined in this document uses the fields of the header
in a manner consistent with that specification.
The RTP timestamp clock frequency is the same as the default sampling
frequency: 16 kHz.
G.711.1 has also the capability to operate with 8 kHz sampled input/
output signals. It does not affect the bitstream, and the decoder
does not require a priori knowledge about the sampling rate of the
original signal at the input of the encoder. Therefore, depending on
the implementation and the audio acoustic capabilities of the
devices, the input of the encoder and/or the output of the decoder
can be configured at 8 kHz; however, a 16 kHz RTP clock rate MUST
always be used.
The duration of one frame is 5 ms, corresponding to 80 samples at 16
kHz. Thus the timestamp is increased by 80 for each consecutive
frame.
G.711.1 does not define anything specific regarding Discontinuous
Transmission (DTX), a.k.a. silence suppression. Codec-independant
mechanisms may be used, like the generic comfort noise payload format
defined in RFC 3389 [10]. For applications which send either no
packets or occasional comfort-noise packets during silence, the first
packet of a talkspurt, that is, the first packet after a silence
period during which packets have not been transmitted contiguously,
SHOULD be distinguished by setting the marker bit in the RTP data
header to one. The marker bit in all other packets is zero. The
beginning of a talkspurt MAY be used to adjust the playout delay to
reflect changing network delays. Applications without silence
suppression MUST set the marker bit to zero.
The assignment of an RTP payload type for this packet format is
Sollaud Expires October 11, 2008 [Page 4]
Internet-Draft RTP Payload Format for G.711.1 April 2008
outside the scope of the 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 codec or specify
that the payload type is to be bound dynamically (see Section 5.3).
4. Payload Format
To take into account the foreseen usages of G.711.1, two sub-formats
are defined: dynamic mode and fixed mode. Only one format is allowed
per RTP payload type. See Section 5 for configuration details.
4.1. Dynamic Mode Payload Format
In this configuration, the mode can be changed between payloads, but
not within a payload.
The complete payload consists of a payload header of 1 octet,
followed by one or more consecutive G.711.1 audio frames of the same
mode.
4.1.1. Payload Header
The payload header is illustrated below.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| MI |
+-+-+-+-+-+-+-+-+
The 5 most significant bits are reserved for further extension and
MUST be set to zero.
The MI field (3 bits) gives the mode of the following frame(s) as per
the table:
+------------+--------------+------------+
| Mode Index | G.711.1 mode | Frame size |
+------------+--------------+------------+
| 1 | R1 | 40 octets |
| 2 | R2a | 50 octets |
| 3 | R2b | 50 octets |
| 4 | R3 | 60 octets |
+------------+--------------+------------+
Table 3: Modes in payload header
All other values of MI are reserved for future used and MUST NOT be
Sollaud Expires October 11, 2008 [Page 5]
Internet-Draft RTP Payload Format for G.711.1 April 2008
used.
Payloads received with an undefined MI value MUST be discarded.
4.1.2. Audio Data
After this payload header, the audio frames are packed in order of
time, that is, oldest first. All frames MUST be of the same mode,
indicated by the MI field of the payload header.
Within a frame, layers are always packed in the same order: L0 then
L1 for mode R2a, L0 then L2 for mode R2b, L0 then L1 then L2 for mode
R3. This is illustrated bellow.
+-------------------------------+
R1 | L0 |
+-------------------------------+
+-------------------------------+--------+
R2a | L0 | L1 |
+-------------------------------+--------+
+-------------------------------+--------+
R2b | L0 | L2 |
+-------------------------------+--------+
+-------------------------------+--------+--------+
R3 | L0 | L1 | L2 |
+-------------------------------+--------+--------+
The size of one frame is given by the mode, as per Table 3, and the
actual number of frames is easy to infer from the size of the audio
data part:
nb_frames = (size_of_audio_data) / (size_of_one_frame).
Only full frames must be considered. So if there is a remainder to
the division above, the corresponding remaining bytes in the received
payload MUST be ignored.
4.2. Fixed Mode Payload Format
In this configuration, the G.711.1 mode is fixed by the signaling.
So an RTP payload type is attached to a single mode.
The payload simply consists of one or more consecutive G.711.1 audio
frames of the fixed mode. There is no payload header.
Sollaud Expires October 11, 2008 [Page 6]
Internet-Draft RTP Payload Format for G.711.1 April 2008
The audio frames are packed in order of time, that is, oldest first.
The layer packing within a frame, and the frame count considerations,
are the same as in Section 4.2
5. Payload Format Parameters
This section defines the parameters that may be used to configure
optional features in the G.711.1 RTP transmission.
Both A-law and mu-law G.711 are supported in the core layer L0, but
there is no interoperability between A-law and mu-law. So two media
types with the same parameters will be defined: audio/PCMA-WB for
A-law core, and audio/PCMU-WB for mu-law core. This is consistent
with the audio/PCMA and audio/PCMU media types separation for G.711
audio.
The parameters are defined here as part of the media subtype
registrations for the G.711.1 codec. A mapping of the parameters
into the Session Description Protocol (SDP) [5] is also provided for
those applications that use SDP. In control protocols that do not
use MIME or SDP, the media type parameters must be mapped to the
appropriate format used with that control protocol.
5.1. PCMA-WB Media Type Registration
[Note to RFC Editor: Please replace all occurrences of RFC XXXX by
the RFC number assigned to this document]
This registration is done using the template defined in RFC 4288 [6]
and following RFC 4855 [7].
Type name: audio
Subtype name: PCMA-WB
Required parameters: none
Optional parameters:
fixed-mode: the fixed mode of the stream. Possible values are 1, 2,
3, or 4 (see Table 3 of RFC XXXX). If fixed-mode is specified,
the fixed mode payload format MUST be used (see Section 4.2 of RFC
XXXX), and frames encoded with other modes than fixed-mode MUST
NOT be sent in any payload. If fixed-mode is not present, the
dynamic mode payload format (see Section 4.1 of RFC XXXX) MUST be
used.
Sollaud Expires October 11, 2008 [Page 7]
Internet-Draft RTP Payload Format for G.711.1 April 2008
ptime: the recommended length of time (in milliseconds) represented
by the media in a packet. See Section 6 of RFC 4566.
maxptime: the maximum length of time (in milliseconds) that can be
encapsulated in a packet. See Section 6 of RFC 4566.
Encoding considerations: This media type is framed and contains
binary data; see Section 4.8 of RFC 4288.
Security considerations: See Section 7 of RFC XXXX
Interoperability considerations: none
Published specification: RFC XXXX
Applications which use this media type: Audio and video conferencing
tools.
Additional information: none
Person & email address to contact for further information: Aurelien
Sollaud, aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP.
Author: Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
5.2. PCMU-WB Media Type Registration
This registration is done using the template defined in RFC 4288 [6]
and following RFC 4855 [7].
Type name: audio
Subtype name: PCMU-WB
Required parameters: none
Optional parameters:
Sollaud Expires October 11, 2008 [Page 8]
Internet-Draft RTP Payload Format for G.711.1 April 2008
fixed-mode: the fixed mode of the stream. Possible values are 1, 2,
3, or 4 (see Table 3 of RFC XXXX). If fixed-mode is specified,
the fixed mode payload format MUST be used (see Section 4.2 of RFC
XXXX), and frames encoded with other modes than fixed-mode MUST
NOT be sent in any payload. If fixed-mode is not present, the
dynamic mode payload format (see Section 4.1 of RFC XXXX) MUST be
used.
ptime: the recommended length of time (in milliseconds) represented
by the media in a packet. See Section 6 of RFC 4566.
maxptime: the maximum length of time (in milliseconds) that can be
encapsulated in a packet. See Section 6 of RFC 4566.
Encoding considerations: This media type is framed and contains
binary data; see Section 4.8 of RFC 4288.
Security considerations: See Section 7 of RFC XXXX
Interoperability considerations: none
Published specification: RFC XXXX
Applications which use this media type: Audio and video conferencing
tools.
Additional information: none
Person & email address to contact for further information: Aurelien
Sollaud, aurelien.sollaud@orange-ftgroup.com
Intended usage: COMMON
Restrictions on usage: This media type depends on RTP framing, and
hence is only defined for transfer via RTP.
Author: Aurelien Sollaud
Change controller: IETF Audio/Video Transport working group delegated
from the IESG
5.3. Mapping to SDP Parameters
The information carried in the 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 the G.711.1 codec, the mapping is
as follows:
Sollaud Expires October 11, 2008 [Page 9]
Internet-Draft RTP Payload Format for G.711.1 April 2008
o The media type ("audio") goes in SDP "m=" as the media name.
o The media subtype ("PCMA-WB" or "PCMU-WB") goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
16000 for G.711.1.
o The parameter "fixed-mode" goes in the SDP "a=fmtp" attribute by
copying it as a "fixed-mode=<value>" string.
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
"a=maxptime" attributes, respectively.
5.3.1. Offer-Answer Model Considerations
The following considerations apply when using SDP offer-answer
procedures [8] to negotiate the use of G.711.1 payload in RTP:
o Since G.711.1 is an extension of G.711, the offerer SHOULD
announce G.711 support in its "m=audio" line, with G.711.1
preferred. This will allow interoperability with both G.711.1 and
G.711-only capable parties.
Below is an example part of such an offer:
m=audio 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
As a reminder, the payload format for G.711 is defined in Section
4.5.14 of RFC 3551 [4].
o The parameter "fixed-mode" is bi-directional, i.e., the restricted
mode applies to media both to be received and sent by the
declaring entity. If a mode is supplied in the offer, the
answerer MUST return the same mode or remove the payload type. If
"fixed-mode" is not present in the offer, the anwerer may return a
"fixed-mode" to restrict the possible mode. In any cases, the
mode in the answer then applies for both offerer and answerer.
The offerer MUST NOT send frames of a mode (i.e. a payload type)
that has been removed by the answerer.
For multicast sessions, if "fixed-mode" is supplied in the offer,
the answerer SHALL only participate in the session if it supports
the offered mode.
o The parameters "ptime" and "maxptime" will in most cases not
affect interoperability. The SDP offer-answer handling of the
"ptime" parameter is described in RFC 3264 [8]. The "maxptime"
Sollaud Expires October 11, 2008 [Page 10]
Internet-Draft RTP Payload Format for G.711.1 April 2008
parameter MUST be handled in the same way.
o Any unknown parameter in an offer MUST be ignored by the receiver
and MUST NOT be included in the answer.
Below are some example parts of SDP offer-answer exchanges.
o Example 1
Offer: dynamic mode
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
Answer: dynamic mode accepted
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
o Example 2
Offer: dynamic mode
m=audio 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
Answer: wants only mode R3
m=audio 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 fixed-mode=4
o Example 3
Offer: two fixed modes, R2b and R3, with R3 preferred
m=audio 54874 RTP/AVP 96 97
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 fixed-mode=4
a=rtpmap:97 PCMA-WB/16000
a=fmtp:97 fixed-mode=3
Answer: accepted
m=audio 59452 RTP/AVP 96 97
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 fixed-mode=4
a=rtpmap:97 PCMA-WB/16000
Sollaud Expires October 11, 2008 [Page 11]
Internet-Draft RTP Payload Format for G.711.1 April 2008
a=fmtp:97 fixed-mode=3
If the answerer wanted to restrict to one mode, it would have
removed the unwanted payload type.
5.3.2. Declarative SDP Considerations
For declarative use of SDP, nothing specific is defined for this
payload format. The configuration given by the SDP MUST be used when
sending and/or receiving media in the session.
6. Congestion Control
Congestion control for RTP SHALL be used in accordance with RFC 3550
[3] and any appropriate profile (for example, RFC 3551 [4]).
The embedded nature of G.711.1 audio data can be helpful for
congestion control, since a coding mode with a lower bit rate can be
selected when needed. When using the dynamic mode payload format, it
is can be done directly. When using the fixed mode payload format,
it can be done by switching to another payload type, if several modes
were negociated.
The number of frames encapsulated in each RTP payload influences the
overall bandwidth of the RTP stream, due to the header overhead.
Packing 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.
7. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in the
RTP specification [3] and any appropriate profile (for example, RFC
3551 [4]).
As this format transports encoded speech/audio, the main security
issues include confidentiality, integrity protection, and
authentication of the speech/audio itself. The payload format itself
does not have any built-in security mechanisms. Any suitable
external mechanisms, such as SRTP [11], MAY be used.
This payload format and the G.711.1 encoding do not exhibit any
significant non-uniformity in the receiver-end computational load and
thus are unlikely to pose a denial-of-service threat due to the
Sollaud Expires October 11, 2008 [Page 12]
Internet-Draft RTP Payload Format for G.711.1 April 2008
receipt of pathological datagrams.
8. IANA Considerations
It is requested that two new media subtype (audio/PCMA-WB and audio/
PCMU-WB) are registered by IANA, see Section 5.1 and Section 5.2.
9. References
9.1. Normative References
[1] International Telecommunications Union, "Wideband embedded
extension for G.711 pulse code modulation", ITU-
T Recommendation G.711.1, March 2008.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[6] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[7] Casner, S., "Media Type Registration of RTP Payload Formats",
RFC 4855, February 2007.
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
9.2. Informative References
[9] International Telecommunications Union, "Pulse code modulation
(PCM) of voice frequencies", ITU-T Recommendation G.711,
November 1988.
[10] Zopf, R., "Real-time Transport Protocol (RTP) Payload for
Comfort Noise (CN)", RFC 3389, September 2002.
Sollaud Expires October 11, 2008 [Page 13]
Internet-Draft RTP Payload Format for G.711.1 April 2008
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
Author's Address
Aurelien Sollaud
France Telecom
2 avenue Pierre Marzin
Lannion Cedex 22307
France
Phone: +33 2 96 05 15 06
Email: aurelien.sollaud@orange-ftgroup.com
Sollaud Expires October 11, 2008 [Page 14]
Internet-Draft RTP Payload Format for G.711.1 April 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Sollaud Expires October 11, 2008 [Page 15]
