rfc-4298

RTP Payload Format for BroadVoice Speech Codecs

J.-H. Chen, W. Lee, J. Thyssen
date2005-12 streamIETF arearai wgavt statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc4298 doi10.17487/RFC4298
This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). [STANDARDS-TRACK]

Extracted elements (20)

design-rationale §2

Both BV16 and BV32 use a fixed 5 ms frame size with no look-ahead in order to minimize end-to-end delay in real-time two-way communications, enabling packet sizes as small as 5 ms when required.

realtime, voip

design-rationale §3.2

No additional payload header is defined for BV16 or BV32 because the fixed frame sizes (10 and 20 octets respectively) allow the receiver to determine the frame count purely by dividing the payload length, eliminating header overhead.

rtp, realtime, voip

design-rationale §5

The MIME names for BV16 and BV32 are allocated from the IETF tree (rather than vendor or personal trees) because these codecs are expected to be widely used for Voice-over-IP applications, especially Voice over Cable.

realtime, voip

interoperability-note §8

BV16 and BV32 do not have any built-in bandwidth reduction mechanism; congestion control must be achieved at the RTP/application level, such as by packing more frames per packet to reduce header overhead, at the cost of increased delay and reduced packet-loss robustness.

rtp, congestion, realtime, voip

interoperability-note §6.1

No special considerations are needed for using the SDP Offer/Answer model (RFC 3264) with BV16 and BV32 RTP payload formats; standard offer-answer procedures apply without codec-specific extensions.

rtp, realtime, voip

normative-requirement §3 MUST

For BV16 and BV32 applications without silence suppression, the RTP marker bit MUST be set to zero. For applications with silence compression, the first packet after a silence period SHOULD have the marker bit set to one.

rtp, realtime, voip

normative-requirement §3.2 MUST NOT

Senders MUST NOT split a BroadVoice16 frame between RTP packets, and BroadVoice16 frames in an RTP packet MUST be consecutive.

rtp, realtime, voip

normative-requirement §4.2 MUST NOT

Senders MUST NOT split a BroadVoice32 frame between RTP packets, and BroadVoice32 frames in an RTP packet MUST be consecutive.

rtp, realtime, voip

normative-requirement §3.2 SHOULD NOT

Senders SHOULD NOT include more BroadVoice16 frames in a single RTP packet than will fit in the MTU of the RTP transport.

rtp, realtime, voip

normative-requirement §5.1 SHOULD

The maxptime SDP parameter SHOULD be a multiple of the duration of a single codec data frame (5 ms) for both BV16 and BV32.

rtp, realtime, voip

normative-requirement §6 MUST

The RTP clock rate in the SDP a=rtpmap attribute MUST be 8000 for BV16 and 16000 for BV32.

rtp, realtime, voip

normative-requirement §3 MUST

The RTP timestamp for BroadVoice16 MUST be in units of 1/8000 of a second, indicating the sampling instant of the oldest audio sample in the payload.

rtp, realtime, voip

normative-requirement §4 MUST

The RTP timestamp for BroadVoice32 MUST be in units of 1/16000 of a second, indicating the sampling instant of the oldest audio sample in the payload.

rtp, realtime, voip

protocol-element §3.2

For multi-frame RTP packets, the timestamp of a frame N positions after the oldest frame is obtained by adding 5*N ms worth of time units to the RTP packet timestamp, exploiting the fixed 5 ms frame size.

rtp, realtime, voip

protocol-element §3

The BV16 RTP payload consists of one or more consecutive 10-octet BroadVoice16 frames with no additional payload header. The number of frames is determined by dividing the total RTP payload octet count by 10.

rtp, realtime, voip

protocol-element §4

The BV32 RTP payload consists of one or more consecutive 20-octet BroadVoice32 frames with no additional payload header. The number of frames is determined by dividing the total RTP payload octet count by 20.

rtp, realtime, voip

registry §5

This document registers two new MIME subtypes in the IETF tree: audio/BV16 (BroadVoice16 narrowband, 8 kHz, 16 kbit/s) and audio/BV32 (BroadVoice32 wideband, 16 kHz, 32 kbit/s), both with optional ptime and maxptime parameters.

registry, rtp, realtime, voip

security-consideration §7

BV16 and BV32 RTP streams are subject to the general RTP security considerations, including achieving confidentiality via encryption. The document notes that the BroadVoice encodings do not exhibit significant non-uniform computational load, so the pathological-datagram denial-of-service attack (common for some compression codecs) is not a significant concern here.

security, rtp, voip

wire-format §3.1

Each BV16 frame encodes 40 samples (5 ms at 8000 samples/s) into exactly 80 bits (10 octets), octet-aligned with no padding. Parameters packed in big-endian order: Line Spectrum Pairs L0,L1 (7+7=14 bits), Pitch Lag PL (7), Pitch Gain PG (5), Log-Gain LG (4), Excitation Vectors V0-V9 (50 bits total).

rtp, realtime, voip

wire-format §4.1

Each BV32 frame encodes 80 samples (5 ms at 16000 samples/s) into exactly 160 bits (20 octets), octet-aligned with no padding. Parameters packed in big-endian order: Line Spectrum Pairs L0,L1,L2 (17 bits), Pitch Lag PL (8), Pitch Gain PG (5), Log-Gains LG0,LG1 (10 bits), first-subframe excitation vectors VA0-VA9 (60 bits), second-subframe vectors VB0-VB9 (60 bits).

rtp, realtime, voip