News

News

How Do VoIP Phones Negotiate Codecs? Understanding SDP and Codec Selection

Introduction

When you pick up a VoIP phone and dial a number, the conversation that begins feels instantaneous and natural. But behind that seamless experience lies a complex negotiation process happening in milliseconds: your phone and the remote endpoint must agree on how to encode, transmit, and decode the voice signal. This agreement -- called codec negotiation -- determines everything from audio quality to bandwidth consumption to compatibility between different manufacturers' equipment.

The protocol that enables this negotiation is the Session Description Protocol (SDP), carried within SIP INVITE messages. SDP describes the media capabilities of each endpoint, including supported codecs, sampling rates, packetization intervals, and encryption requirements. The two endpoints compare their capability lists, apply priority rules, and select the highest-quality mutually supported codec. When this process works correctly, callers enjoy crystal-clear audio. When it fails or produces suboptimal results, calls suffer from robotic voices, one-way audio, excessive latency, or complete failure to connect.

This article explains how codec negotiation works step by step, demystifies SDP message structure, covers common pitfalls and troubleshooting techniques, and provides practical guidance for configuring codec preferences that balance quality, bandwidth, and compatibility across diverse VoIP deployments.

What Is a Codec?

A codec (coder-decoder) is an algorithm that converts analog voice signals into digital packets for transmission over IP networks, and back again at the receiving end. Different codecs make different trade-offs among three competing priorities:

  • Audio Quality: Measured by MOS (Mean Opinion Score) from 1.0 (unintelligible) to 5.0 (toll-quality). Higher bitrates generally produce higher MOS scores.
  • Bandwidth Consumption: Measured in kilobits per second (kbps). Lower bitrates conserve network capacity but may sacrifice quality.
  • Processing Complexity: More sophisticated compression requires more CPU power, affecting device cost and battery life for mobile endpoints.

Common VoIP Codecs

Codec Bitrate (kbps) MOS Score Bandwidth with Overhead Notes
G.711 (PCMU/PCMA) 64 4.4 ~87 kbps Toll-quality baseline; no compression; universally supported
G.729 8 4.0 ~31 kbps High compression; good for bandwidth-constrained links
G.722 64 4.5 ~87 kbps Wideband audio; superior clarity; increasingly standard
Opus 6-510 4.5+ Variable Adaptive bitrate; excellent for variable networks; modern standard
iLBC 13.3-15.2 3.8 ~38 kbps Packet loss resilient; designed for unreliable networks
G.726 16-40 3.9-4.2 Variable ADPCM compression; moderate quality and bandwidth

No single codec is optimal for all scenarios. The right choice depends on network conditions, endpoint capabilities, regulatory requirements, and quality expectations.

The Role of SDP in Codec Negotiation

Session Description Protocol (SDP) is defined in RFC 4566 and serves as the metadata language for multimedia sessions. In VoIP, SDP is embedded within SIP INVITE and 200 OK messages to describe media capabilities. A typical SDP body includes:

Key SDP Fields for Codec Negotiation

  • m=audio: Declares the media type (audio) and transport port.
  • a=rtpmap: Maps RTP payload type numbers to specific codecs with sampling rates.
  • a=fmtp: Format parameters providing additional codec-specific configuration (e.g., ptime for packetization interval).
  • c=IN IP4: Connection information specifying the IP address for media streams.
  • a=ptime: Preferred packetization interval in milliseconds (typically 20ms).

Example SDP Offer

v=0
o=1000 1 IN IP4 192.168.1.100
s=-
c=IN IP4 192.168.1.100
m=audio 49170 RTP/AVP 0 8 9 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

This offer declares support for five audio codecs (G.711u, G.711a, G.722, G.729, and RFC 2833 DTMF) plus their respective payload type numbers. The order matters: codecs are listed in preference order, with the most preferred first.

The Negotiation Process Step by Step

  1. INVITE with SDP Offer: The calling phone sends a SIP INVITE containing its SDP offer listing supported codecs in preference order.
  2. SDP Answer Generation: The receiving phone (or proxy/B2BUA) compares the offered codecs against its own capabilities.
  3. Codec Selection: The answerer selects the highest-priority codec from the offer that it also supports. This becomes the negotiated codec for the call.
  4. 200 OK with SDP Answer: The answerer sends a 200 OK response containing an SDP answer confirming the selected codec (and potentially modifying other parameters like port numbers).
  5. ACK Confirmation: The caller sends ACK, and both endpoints begin transmitting RTP media using the negotiated codec.

Critical insight: the answerer makes the final codec selection, not the offerer. The offerer expresses preference through ordering, but the answerer chooses based on its own capabilities and policies. This prevents situations where the offerer requests an unsupported codec.

Common Codec Negotiation Scenarios

Scenario 1: Direct Endpoint-to-Endpoint

Two IP phones on the same LAN communicate directly. Both typically support G.711 and G.722, so negotiation succeeds quickly with high-quality audio. No transcoding occurs; media flows peer-to-peer.

Scenario 2: Through a SIP Proxy/B2BUA

When calls traverse a PBX or session border controller, the intermediary may terminate and re-originated the SIP session (B2BUA behavior). In this case, two separate negotiations occur:

  • Phone A ↔ PBX: Negotiates codec for leg 1
  • PBX ↔ Phone B: Negotiates codec for leg 2

If the two legs use different codecs, the PBX must transcode -- converting between codecs in real-time. Transcoding consumes CPU resources and introduces slight latency. High-end systems minimize transcoding by maintaining codec consistency across legs when possible.

Scenario 3: Trunk to Service Provider

Enterprise SIP trunks often have specific codec requirements dictated by the provider. Some providers only accept G.711; others prefer G.729 to conserve backbone bandwidth. The enterprise PBX must be configured to offer the provider's required codecs prominently in SDP offers, even if internal endpoints prefer different codecs. This frequently necessitates transcoding at the trunk gateway.

Scenario 4: Cross-Vendor Interoperability

Different manufacturers implement codecs differently. One vendor's G.729 may sound noticeably different from another's due to varying implementation quality. Some vendors support proprietary extensions or non-standard payload type assignments. When interoperability issues arise, administrators may need to force specific codec selections or adjust SDP parameters to achieve acceptable results.

Troubleshooting Codec Negotiation Problems

Problem: One-Way Audio

Symptoms: One party can hear the other, but not vice versa.
Causes:

  • Firewall blocking RTP ports asymmetrically
  • NAT traversal failure causing incorrect IP addresses in SDP
  • Codec mismatch where one direction uses unsupported codec

Solutions: Verify firewall rules allow bidirectional RTP; check SDP c= lines for correct public IPs; enable SIP ALG or use STUN/TURN for NAT traversal; capture SIP traces to confirm negotiated codec.

Problem: Robotic or Choppy Audio

Symptoms: Voice sounds mechanical, broken, or intermittently silent.
Causes:

  • Excessive packet loss (>1%) degrading compressed codecs disproportionately
  • Jitter buffer underruns due to network variability
  • Insufficient bandwidth causing packet drops
  • Incompatible codec implementations between vendors

Solutions: Switch to more robust codec (G.711 instead of G.729); increase jitter buffer size; implement QoS prioritizing voice traffic; verify network capacity; test with different codec to isolate implementation issues.

Problem: Call Fails to Connect

Symptoms: INVITE receives 488 Not Acceptable Here or similar error.
Causes:

  • No mutually supported codecs between endpoints
  • SDP malformed or missing required fields
  • Provider rejecting offered codecs on SIP trunk

Solutions: Verify codec compatibility matrix; check SDP syntax with protocol analyzer; review trunk configuration for required codec settings; add missing codecs to endpoint configuration.

Problem: Poor Audio Quality Despite "Good" Codec

Symptoms: G.711 call still sounds bad.
Causes:

  • Network congestion causing delay and jitter
  • Echo from acoustic coupling or hybrid circuits
  • Incorrect sample rate or packetization interval
  • Faulty handset or headset hardware

Solutions: Run network quality tests (ping, jitter, MOS); enable echo cancellation; verify ptime settings match endpoint capabilities; test with different hardware.

Best Practices for Codec Configuration

Establish Clear Codec Preference Lists

Configure endpoints with explicit codec priority orders reflecting your organization's priorities:

  • Quality-first environments (call centers, executive offices): G.722 > G.711 > G.729
  • Bandwidth-constrained environments (branch offices, remote workers): G.729 > G.711 > G.722
  • Modern adaptive environments: Opus > G.722 > G.711 > G.729

Document these policies and apply consistently across device provisioning templates.

Minimize Unnecessary Transcoding

Transcoding wastes CPU cycles and adds latency. Strategies to reduce it:

  • Standardize on common codecs across all endpoints
  • Configure SIP trunks to accept the same codecs used internally
  • Use direct media (re-INVITE) for intra-site calls bypassing PBX media path
  • Deploy distributed SBCs at branch offices to localize media

Monitor and Audit Codec Usage

Regularly analyze call detail records to understand actual codec utilization:

  • Identify calls using suboptimal codecs despite better options being available
  • Detect trunk segments forcing unwanted transcoding
  • Track MOS scores correlated with codec types to validate quality assumptions
  • Adjust configurations based on empirical data rather than theoretical preferences

Plan for Future Codec Evolution

The industry is gradually migrating toward wideband and adaptive codecs:

  • G.722 adoption continues growing as default for new deployments
  • Opus gains traction for its adaptability and open licensing
  • Legacy narrowband codecs (G.729, iLBC) persist for compatibility but decline in new designs
  • Ensure new equipment purchases support modern codecs while maintaining backward compatibility

How New Rock Technologies Handles Codec Negotiation

New Rock Technologies builds intelligent codec negotiation directly into its IP PBX platforms and gateway products. The company's systems automatically detect endpoint capabilities during registration and optimize codec selection based on configurable policies that balance quality, bandwidth, and compatibility. Administrators can define site-specific codec preference lists through an intuitive web interface, and the system applies these policies dynamically during call setup without requiring manual intervention per call.

New Rock's gateways include hardware-accelerated DSP resources for efficient transcoding when necessary, supporting simultaneous conversion between multiple codec types without degrading overall system performance. The platforms provide detailed call analytics showing negotiated codecs per call, transcoding events, and associated quality metrics -- enabling administrators to identify optimization opportunities and troubleshoot issues proactively. For SIP trunk connectivity, New Rock systems support flexible trunk-side codec configuration independent of endpoint preferences, ensuring seamless integration with diverse service providers while maintaining optimal internal call quality.

Beyond basic negotiation, New Rock implements advanced features like dynamic codec switching during active calls when network conditions change, automatic fallback to robust codecs when packet loss exceeds thresholds, and comprehensive SDP validation preventing malformed offers from causing call failures. These capabilities -- combined with regular firmware updates incorporating community feedback and emerging standards -- ensure that New Rock deployments maintain optimal audio quality across evolving network environments and endpoint ecosystems.

Conclusion

Codec negotiation is one of those invisible infrastructure processes that users never think about -- until it goes wrong. Understanding how SDP facilitates this negotiation, recognizing common failure modes, and implementing thoughtful configuration policies transforms codec selection from a source of mysterious problems into a predictable, optimized component of your VoIP architecture. Whether you manage a small office deployment or a multinational enterprise network, mastering codec negotiation pays dividends in call quality, network efficiency, and user satisfaction. Platforms like those from New Rock Technologies automate much of this complexity while providing the visibility and control needed for fine-tuning -- letting you focus on business outcomes rather than protocol minutiae.

Customer-centric, focus on customer value

Consult now

Copyright © New Rock Technologies, Inc. All Rights Reserved. 沪ICP备15008515号-1