Supported Codecs

CallMeter workers support a range of audio and video codecs for SIP call testing. This page documents each supported codec with its technical specifications, use cases, and guidance on which codecs to select for different testing scenarios.

Audio Codecs

CallMeter supports seven audio codecs covering narrowband telephony, compressed trunk codecs, wideband voice, and adaptive high-fidelity audio.

PCMA (G.711 A-law)

The ITU-T G.711 A-law codec is the standard narrowband audio codec used in European and international telephone networks. It encodes audio at 8 kHz sampling rate using 8-bit A-law companding, producing a constant 64 kbps bitrate.

Specifications:

• Standard: ITU-T G.711
• RTP Payload Type: 8 (static, assigned by IANA)
• Sample rate: 8000 Hz
• Bit depth: 8 bits per sample
• Bitrate: 64 kbps (constant)
• Frame size: Configurable via ptime (default 20ms = 160 samples per packet)
• Frequency response: 300 Hz to 3400 Hz
• Algorithmic delay: 0.125ms (one sample period)

When to use PCMA in testing:

• Testing European or international SIP infrastructure where A-law is the standard encoding
• Compatibility testing against any SIP endpoint (PCMA is universally supported)
• Baseline quality testing where codec complexity should not be a variable
• Stress testing with high endpoint counts (PCMA has negligible CPU overhead)

PCMU (G.711 u-law)

The ITU-T G.711 u-law (mu-law) codec is the standard narrowband audio codec used in North American and Japanese telephone networks. Functionally identical to PCMA but uses u-law companding, which provides slightly better dynamic range at lower signal levels.

Specifications:

• Standard: ITU-T G.711
• RTP Payload Type: 0 (static, assigned by IANA)
• Sample rate: 8000 Hz
• Bit depth: 8 bits per sample
• Bitrate: 64 kbps (constant)
• Frame size: Configurable via ptime (default 20ms = 160 samples per packet)
• Frequency response: 300 Hz to 3400 Hz
• Algorithmic delay: 0.125ms (one sample period)

When to use PCMU in testing:

• Testing North American SIP infrastructure where u-law is the standard encoding
• Any scenario where PCMA applies but the target system expects u-law
• The default codec choice when no specific regional requirement exists

G.722

The ITU-T G.722 codec provides wideband audio quality at the same 64 kbps bitrate as G.711. By sampling at 16 kHz instead of 8 kHz, G.722 captures audio frequencies up to 7000 Hz, producing noticeably clearer and more natural-sounding voice compared to narrowband codecs. G.722 is widely marketed as "HD Voice" by VoIP service providers and is supported by most modern IP phones and softphones.

Specifications:

• Standard: ITU-T G.722
• RTP Payload Type: 9 (static, assigned by IANA)
• Sample rate: 16000 Hz (note: RTP clock rate is 8000 Hz for historical reasons)
• Bitrate: 64 kbps (constant, three modes: 64/56/48 kbps)
• Frequency response: 50 Hz to 7000 Hz
• Sub-band coding: Audio split into lower (0-4 kHz) and upper (4-8 kHz) sub-bands
• Algorithmic delay: 1.5ms

When to use G.722 in testing:

• Testing HD Voice quality on enterprise IP phone deployments
• Wideband audio quality assessment where G.711's narrowband limitation is insufficient
• Testing SIP infrastructure codec negotiation with wideband preference
• Evaluating the quality improvement of wideband over narrowband on a specific network path

Opus

Opus is a modern, royalty-free audio codec defined in RFC 6716. It is the most versatile audio codec available, supporting sampling rates from 8 kHz to 48 kHz and bitrates from 6 kbps to 510 kbps. Opus can encode narrowband speech, wideband voice, and full-bandwidth music with equal effectiveness. It includes built-in forward error correction (FEC), packet loss concealment, and dynamic bitrate adaptation.

Specifications:

• Standard: RFC 6716 (codec), RFC 7587 (RTP payload format)
• RTP Payload Type: Dynamic (negotiated via SDP, 111)
• RTP clock rate: 48000 Hz. Per RFC 7587 §6.1 this is always 48000 regardless of the internal sampling rate, and the a=rtpmap channel count is always 2 even for mono
• Bitrate: the codec spans 6 to 510 kbps (RFC 6716 §2.1.1); CallMeter encodes at 48 kbps
• Frame size: 20ms. The codec permits 2.5/5/10/20/40/60ms, but CallMeter's encoder is pinned to 20ms, which is what ptime is clamped to
• Features: Built-in FEC, DTX, CBR or VBR modes
• Algorithmic delay: 6.5ms to 26.5ms (depends on frame size)

When to use Opus in testing:

• Testing WebRTC or modern VoIP platforms where Opus is the primary codec
• Quality benchmarking where maximum audio fidelity is desired
• Testing adaptive bitrate behavior under varying network conditions
• Evaluating the built-in FEC performance under packet loss conditions
• Comparing Opus quality against legacy codecs on the same network path

G.726-32

The ITU-T G.726 codec is an ADPCM (adaptive differential pulse-code modulation) codec that carries narrowband voice at half the bitrate of G.711 with only a modest quality cost. The 32 kbps variant is the one PSTN-facing SIP trunks and analog telephone adapters actually run, which makes it the codec to reach for when your test needs to mirror a real trunk rather than an ideal one.

Specifications:

• Standard: ITU-T G.726
• RTP Payload Type: Dynamic (96). RFC 1890 assigned payload type 2 to G721/G726-32, but RFC 3551 marks it RESERVED, so G.726-32 negotiates on a dynamic type
• Sample rate: 8000 Hz
• Bitrate: 32 kbps (constant)
• Frequency response: 300 Hz to 3400 Hz

When to use G.726-32 in testing:

• Reproducing what a PSTN-facing trunk or ATA actually negotiates
• Measuring the quality cost of halving voice bandwidth against a G.711 baseline
• Bandwidth-constrained links where G.711 would saturate the path

GSM (06.10 full rate)

GSM 06.10 full rate is the original digital mobile voice codec. It remains widely implemented in SIP stacks and is useful as a low-bitrate narrowband reference point, particularly when testing gateways that still offer it.

Specifications:

• Standard: ETSI GSM 06.10 full rate
• RTP Payload Type: 3 (static, per RFC 3551 §6)
• Sample rate: 8000 Hz
• Bitrate: 13 kbps (constant)
• Frame size: 20ms (160 samples)
• Frequency response: 300 Hz to 3400 Hz

When to use GSM in testing:

• Testing gateways and SBCs that still advertise GSM in their offer
• Establishing a low-bitrate quality floor to compare higher-rate codecs against
• Verifying that transcoding to and from a legacy mobile codec behaves as expected

Speex (narrowband)

Speex is an open-source, patent-free voice codec designed for VoIP. CallMeter runs its narrowband mode at 8 kHz. It is a useful low-bitrate option when a test target advertises Speex, and a royalty-free alternative for comparison against proprietary compressed codecs.

Specifications:

• Standard: RFC 5574 (RTP payload format)
• RTP Payload Type: Dynamic (97). Speex has no static assignment
• Sample rate: 8000 Hz (narrowband mode)
• Bitrate: approximately 15 kbps. Speex is variable-bitrate; 15 kbps is the narrowband quality-8 operating point CallMeter encodes at, not a spec-fixed value
• Frequency response: 300 Hz to 3400 Hz

When to use Speex in testing:

• Testing endpoints or gateways that advertise Speex
• Comparing an open codec against proprietary compressed codecs on the same path
• Low-bitrate testing where a patent-free codec is preferred

Video Codecs

CallMeter supports four video codecs for SIP video call testing.

H.264 (AVC)

H.264 (also known as AVC, Advanced Video Coding) is the most widely deployed video codec in the world. Standardized jointly by ITU-T and ISO/IEC, H.264 provides excellent compression efficiency and is supported by virtually all video-capable SIP endpoints, hardware encoders, and media servers.

Specifications:

• Standard: ITU-T H.264 / ISO/IEC 14496-10
• RTP Payload Format: RFC 6184
• RTP Payload Type: Dynamic (negotiated via SDP, typically 96-127)
• Supported profile: Constrained Baseline
• Resolutions: Selectable by height — 288p, 360p, 480p, 720p, 1080p
• Frame rates: 15, 24, 30 or 60 fps
• Bitrate: Selectable from 384 kbps to 3072 kbps

Profile details: The Constrained Baseline profile (CBP) is the most widely compatible H.264 profile. It supports I-frames and P-frames (no B-frames), CAVLC entropy coding, and no interlaced encoding. This profile is used by most SIP video endpoints and is the mandatory profile for WebRTC's H.264 support.

When to use H.264 in testing:

• Testing any SIP video endpoint (near-universal support)
• Video quality assessment under varying network conditions
• Stress testing media servers and SBCs with video calls
• Testing codec negotiation with specific profile-level-id parameters

H.265 (HEVC)

H.265, also known as HEVC (High Efficiency Video Coding), is H.264's successor. It delivers comparable perceptual quality at roughly half the bitrate, which makes it the codec of interest wherever video has to cross a constrained link. Support across SIP endpoints is narrower than H.264, so it is worth confirming the far end offers it before building a test suite around it.

Specifications:

• Standard: ITU-T H.265 / ISO/IEC 23008-2
• RTP Payload Format: RFC 7798
• RTP Payload Type: Dynamic (negotiated via SDP)
• Supported profile: Main
• Resolutions: Selectable by height — 288p, 360p, 480p, 720p, 1080p
• Frame rates: 15, 24, 30 or 60 fps
• Bitrate: Selectable from 384 kbps to 3072 kbps

When to use H.265 in testing:

• Measuring the bitrate saving against an H.264 baseline on the same path
• Testing endpoints and SBCs that advertise HEVC
• Video testing over bandwidth-constrained links where H.264 would saturate the path
• Verifying transcoding behavior between H.265 and H.264 legs

VP8

VP8 is an open-source, royalty-free video codec developed by Google. It is the original mandatory video codec for WebRTC and remains widely deployed in WebRTC-based communication platforms. VP8 provides competitive compression efficiency compared to H.264 Baseline.

Specifications:

• Standard: RFC 6386 (bitstream), RFC 7741 (RTP payload format)
• RTP Payload Type: Dynamic (negotiated via SDP, typically 96-127)
• Resolutions: Configurable
• Frame rates: Configurable
• Bitrate: Selectable from 384 kbps to 3072 kbps
• Features: Temporal scalability, keyframe-only mode, error resilience partitioning

When to use VP8 in testing:

• Testing WebRTC platforms and gateways
• Royalty-free deployment requirements
• Testing SIP-to-WebRTC gateway interoperability
• Comparing VP8 and H.264 quality on the same network path

VP9

VP9 is an open-source, royalty-free video codec developed by Google as the successor to VP8. VP9 achieves approximately 30-50% better compression efficiency than VP8 at the same visual quality, meaning it requires significantly less bandwidth for equivalent resolution and frame rate. VP9 is widely supported in modern browsers and WebRTC implementations.

Specifications:

• Standard: VP9 bitstream specification
• RTP Payload Format: RFC 9628
• RTP Payload Type: Dynamic (negotiated via SDP, typically 96-127)
• Resolutions: Selectable by height — 288p, 360p, 480p, 720p, 1080p
• Frame rates: 15, 24, 30 or 60 fps
• Bitrate: Selectable from 384 kbps to 3072 kbps
• Features: Spatial and temporal scalability (SVC), superframes, reference frame management, lossless compression mode
• Profiles: Profile 0 (8-bit 4:2:0, the most common)

When to use VP9 in testing:

• Testing modern WebRTC platforms that negotiate VP9 for bandwidth efficiency
• Bandwidth-constrained environments where VP9's superior compression is beneficial
• Comparing VP9 quality against VP8 and H.264 at equivalent bitrates
• Testing SVC (Scalable Video Coding) support on conferencing platforms
• Evaluating video quality on mobile networks where bandwidth savings matter

Bandwidth Requirements

The table below summarizes the network bandwidth consumed by each codec at common configurations. These figures represent the media payload only. Actual network usage is approximately 10-15% higher due to RTP, UDP, and IP header overhead (typically 40-60 bytes per packet).

Audio Bandwidth

For audio, each RTP packet carries 20ms of audio by default (configurable via the ptime attribute). At 50 packets per second, each packet adds approximately 54 bytes of overhead (12 bytes RTP header + 8 bytes UDP header + 20 bytes IPv4 header + optional CSRC and extensions).

Video Bandwidth

Video bandwidth varies significantly based on scene complexity, motion, and encoder settings. The ranges above represent typical values for medium-complexity content (talking head with moderate background detail). High-motion content (screen sharing with scrolling, presentations with animations) will consume bandwidth toward the upper end of each range.

Codec Negotiation in SDP

When CallMeter initiates a SIP call, the SDP offer includes all codecs selected in your test configuration. Codec negotiation follows the SDP offer/answer model defined in RFC 3264.

How It Works

1. SDP Offer: The calling endpoint includes all selected codecs in the m= line of the SDP body, ordered by the preference you set in the test configuration. Each codec is listed by its RTP payload type with corresponding a=rtpmap: and a=fmtp: attributes.

2. SDP Answer: The remote endpoint (your SIP infrastructure under test) responds with the subset of offered codecs it supports, ordered by its own preference. The first codec in the answer is used for the media session.

3. Codec Selection: The negotiated codec is the highest-preference codec that both sides support. If no common codec exists, the call fails with SIP 488 (Not Acceptable Here) and the endpoint's outcome is set to NEGOTIATION_FAILED.

SDP Offer Example

A test configured with Opus, G.722, and PCMA produces an SDP offer like:

m=audio 10000 RTP/AVP 111 9 8
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000

The answering endpoint selects the codec it prefers from the offered list. If it only supports G.711, it answers with payload type 8 only. If it supports Opus, it may answer with payload type 111.

Testing Codec Negotiation

By including multiple codecs in your test, you can verify:

• Preference ordering: Whether your SIP infrastructure respects your codec priority
• Fallback behavior: Whether calls complete when the preferred codec is unavailable
• Transcoding paths: Whether SBCs correctly transcode between different codecs (e.g., Opus on one side, G.711 on the other)
• Codec compatibility: Whether all endpoints in your infrastructure agree on a common codec

RTP Profiles

CallMeter supports four RTP profiles that determine the security and feedback capabilities of the media session. The RTP profile is negotiated during SDP offer/answer as part of the media line (m= line) protocol field.

AVP (Audio-Visual Profile)

The baseline RTP profile defined in RFC 3551. AVP provides standard RTP transport without encryption or immediate feedback. RTCP reports are sent at regular intervals (typically every 5 seconds). AVP is the default profile for traditional SIP telephony.

AVPF (Audio-Visual Profile with Feedback)

An extended profile defined in RFC 4585 that adds immediate RTCP feedback capabilities. AVPF allows feedback messages (NACK, PLI, FIR, SLI, RPSI) to be sent immediately when a quality event occurs, rather than waiting for the next scheduled RTCP interval. Essential for video calls where timely keyframe requests and packet retransmission improve visual quality.

SAVP (Secure Audio-Visual Profile)

The encrypted variant of AVP using SRTP (RFC 3711). SAVP provides media encryption and authentication. Key exchange is handled via SDP Security Descriptions (SDES, RFC 4568) or DTLS-SRTP (RFC 5764). SAVP is used for encrypted audio calls that do not require immediate feedback.

SAVPF (Secure Audio-Visual Profile with Feedback)

Combines SRTP encryption from SAVP with immediate feedback from AVPF. SAVPF is the mandatory RTP profile for WebRTC and is the recommended profile for any encrypted video call. It provides both media security and optimal error recovery.

Codec Selection Guide

Choosing the right codec and profile for your test depends on what you are testing and what your target infrastructure supports.

Testing Traditional PBX/SBC Systems

Use PCMA or PCMU with the AVP profile. These systems universally support G.711 and basic RTP. This configuration minimizes variables and isolates SIP signaling and capacity as the test focus.

Testing HD Voice Deployments

Use G.722 with AVP. Compare results against a G.711 baseline to quantify the quality improvement of wideband audio on your network. Include both G.722 and G.711 in the codec list to test fallback negotiation.

Testing Modern VoIP Platforms

Use Opus with AVPF or SAVPF. Modern platforms optimize for Opus and benefit from RTCP feedback for quality adaptation. Test with variable bitrate to evaluate adaptive behavior.

Testing Video Conferencing

Use H.264, VP8, or VP9 with AVPF or SAVPF. Video calls require feedback for keyframe requests (PLI/FIR) and packet retransmission (NACK). Configure appropriate bitrate, resolution, and frame rate based on the target system's expected usage. Use VP9 when the conferencing platform supports it and bandwidth efficiency is important.

Testing SIP-to-WebRTC Gateways

Use Opus and VP8 (or VP9) with SAVPF. This matches the WebRTC mandatory codec profile. Compare with PCMA and H.264 on the SIP side to test the gateway's transcoding capabilities.

Testing Bandwidth-Constrained Networks

Use Opus (low bitrate, 12-20 kbps) for audio and VP9 for video. VP9 delivers equivalent visual quality at 30-50% lower bitrate than H.264 or VP8. Combine with the SAVPF profile to enable NACK-based error recovery, which is more bandwidth-efficient than keyframe requests on lossy links.

Codec Configuration in Tests

When creating a test in CallMeter, codec selection is configured per group:

1. Media mode: Choose between Generic (synthetic media generated by the worker) or Custom (uploaded media files)
2. Audio codecs: Select one or more audio codecs from the supported list
3. Video: Optionally enable video and select H.264, H.265, VP8, or VP9 with bitrate, resolution, and frame rate settings

In Generic mode, workers generate synthetic audio or video patterns using the selected codec. In Custom mode, workers play uploaded media files. The platform automatically transcodes uploaded files into all supported codec formats at upload time, ensuring instant availability regardless of which codec the remote endpoint negotiates.

Related Pages

• VoIP Terminology -- Codec and protocol definitions
• Supported Formats -- Media file format requirements
• Creating a Test -- How to configure codecs in a test
• SIP Response Codes -- Understanding 488 and other negotiation failures
• Metrics Reference -- Quality metrics affected by codec choice