SDP Offer/Answer in VoIP: How Media Capabilities Are Negotiated

Ever wonder how your phone call with someone on a different system-maybe a Cisco desk phone, a Zoom client, or a mobile app-just works without you having to pick codecs or set ports? It’s not magic. It’s the SDP Offer/Answer model, and it’s the quiet engine behind every successful VoIP call you’ve ever made.

What Exactly Is the SDP Offer/Answer Model?

The Session Description Protocol (SDP) Offer/Answer model is a rulebook, defined in RFC 3264, that tells two VoIP devices how to agree on how to talk to each other. Think of it like two people trying to build a radio station together. One person says, “I can send audio on 100.1 FM with stereo sound.” The other replies, “I can receive that, but I only do mono.” They settle on mono, and now they can communicate. That’s the Offer/Answer model in action.

It’s not about what the devices can do-it’s about what they both can agree on. One side (the offerer) sends an SDP Offer listing all the media options: which audio and video codecs it supports, what IP address and port to use, how much bandwidth it needs, and more. The other side (the answerer) looks at that list and picks what works for them. They send back an SDP Answer with only the matching options. If nothing matches? The call fails. No guesswork. No back-and-forth. Just a clear yes or no.

This model was created in 2002 because SDP, on its own, could describe a session-but couldn’t say how to negotiate one. RFC 3264 fixed that. Today, 99.2% of enterprise SIP-based VoIP systems rely on it, according to Metaswitch’s 2024 survey. Even WebRTC, the technology behind browser-to-browser calls, uses the same logic.

How the Offer and Answer Actually Work

An SDP message looks like a block of text, but every line has meaning. Here’s a simplified version:

v=0
o=- 1234567890 1 IN IP4 192.168.1.10
s=-
c=IN IP4 192.168.1.10
t=0 0
m=audio 5004 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 OPUS/48000

This is an Offer. It says:

• “I’m sending audio on port 5004 using RTP.”
• “I support three codecs: PCMU (G.711 mu-law), PCMA (G.711 A-law), and OPUS.”

The answerer replies:

v=0
o=- 987654321 1 IN IP4 192.168.1.20
s=-
c=IN IP4 192.168.1.20
t=0 0
m=audio 5504 RTP/AVP 8
a=rtpmap:8 PCMA/8000

The answer:

• Keeps the same session time (t=0 0) as the offer.
• Chooses only PCMA (codec 8)-a subset of what was offered.
• Uses a different port (5504), because each side picks its own listening port.

That’s it. No extra back-and-forth. The offerer now knows to send audio using PCMA to port 5504. The answerer listens there. Media flows. Simple. Deterministic.

What Happens When Things Don’t Match?

Not every device supports the same codecs. Maybe one side only has G.711. The other has OPUS and G.729. The answerer can’t add new codecs. They can’t change the bandwidth. They can’t pick a codec that wasn’t offered.

If there’s zero overlap? The answerer must reject the entire media stream by setting the port to zero:

m=audio 0 RTP/AVP 0 8 96

That’s not a mistake. That’s the protocol working as designed. It tells the offerer: “I can’t do audio with you.” The offerer might try another stream, or end the call.

This is where most failures happen. A 2025 Reddit thread on r/VOIP showed 68% of new admins misunderstood this. They thought port=0 meant a technical error. It doesn’t. It’s a deliberate, protocol-compliant rejection.

And it’s not just codecs. If the offer says “ptime=20” (20ms audio packets), the answer must use ptime=20 too. If the offer says “b=AS:128”, the answer can’t say “b=AS:64.” The answer must be a subset, not a modification.

Why This Model Works Better Than Alternatives

You might think symmetric negotiation-where both sides exchange lists and try to find common ground-would be fairer. But it’s risky. What if both sides propose different priorities? You get deadlock. No call. No resolution.

The Offer/Answer model avoids this by making one side the driver. The offerer sets the options. The answerer chooses from them. No ambiguity. No looping. Even if one side has 10 codecs and the other has only one, as long as that one is in the offer, the call works.

That’s why it’s the industry standard. Dr. Jonathan Rosenberg, co-author of RFC 3264 and former CTO of Skype, called the asymmetry “our most significant insight.” It turned SDP from a static description format into a live negotiation tool.

Webex Engineering confirmed in 2023 that without this model, interoperability between vendors like Cisco, Poly, and Microsoft Teams would be nearly impossible. You wouldn’t be able to call from your iPhone to a Zoom room on a Windows PC and expect it to work. But it does-because of SDP Offer/Answer.

Where It Breaks Down

The model is robust-but not perfect. It was designed for simple, one-to-one calls. Modern systems are more complex.

• Multiple codecs, multiple options: What if you want to offer both OPUS and G.722, but prefer OPUS? The basic model doesn’t let you say “I prefer this.” That’s why RFC 5939 (2010) added “capability negotiation,” letting you list multiple sets of options. The answerer can pick a whole group.
• Bandwidth changes mid-call: If network conditions drop, you can’t renegotiate bandwidth in the original answer. You need a new offer. That’s called a re-INVITE.
• Legacy systems: Some older SIP phones don’t handle port=0 correctly. They crash. Or they ignore it. That’s why 34.2% of enterprise VoIP systems still have known SDP parsing flaws, according to CyberCX’s January 2025 report.
• Security: Malformed SDP can crash SIP servers. A 2024 Black Hat study found 17.3% of public SIP servers were vulnerable to buffer overflow attacks triggered by bad SDP.

A network engineer on Spiceworks shared that his Cisco CUCM system had random call drops for weeks-until they realized the answer was sending ptime=30 when the offer said ptime=20. The call worked… until the audio buffer filled up and crashed. It took three weeks to find. That’s the kind of detail that kills deployments.

Real-World Impact: From Call Success to Business Outcomes

This isn’t just technical trivia. It affects your business.

A telecom consultant, Maria Rodriguez, reported that after enforcing strict RFC 3264 compliance in her company’s Session Border Controller (SBC), call setup success rates jumped from 73% to 98.2% with 15 different SIP providers. That’s not a 25% improvement-it’s a 35% reduction in failed calls. That’s lost productivity. Lost customer trust.

On the flip side, products with built-in SDP debugging tools-like Oracle’s SBC-get 4.6/5 ratings from users. Why? Because when an offer/answer fails, you need to see the raw SDP. Not a log saying “call failed.” You need to see:

• What codecs were offered?
• What was accepted?
• Was a port set to zero?
• Did the ptime match?

Wireshark’s SDP dissector is a free tool that shows this. Most IT teams don’t use it until something breaks. Then it’s too late.

Best Practices for Implementation

If you’re deploying VoIP systems, here’s what you need to do:

1. Validate every SDP message. Reject offers with invalid syntax. Don’t try to guess what was meant.
2. Log full SDP exchanges. Save the raw Offer and Answer. You’ll need them when calls fail.
3. Test with real devices. Don’t just test with your own system. Use a Poly phone, a Yealink, a softphone, and a WebRTC client.
4. Watch for port=0. Understand that it’s not an error-it’s a feature. Build alerts for it.
5. Use tools. GitHub has open-source SDP validators like “sdp-validator” (2,843 stars). Use them.

Cisco’s Unified Communications documentation is rated 4.2/5 for its clear examples of SDP negotiation. Smaller vendors? Often silent. Don’t assume they got it right.

The Future: AI, 5G, and Beyond

The model isn’t going away. Frost & Sullivan predicts it’ll dominate until at least 2030. But it’s evolving.

Cisco’s Unified Communications Manager 15.0 (Sept 2024) now uses AI to pick codecs based on network conditions-reducing bandwidth use by 23.7% on WAN links. That’s not changing the Offer/Answer model. It’s making the offer smarter.

3GPP’s Release 18 (2024) lets 5G networks influence SDP offers based on real-time radio quality. If your phone is in a weak signal area, the network can nudge the offer toward lower-bandwidth codecs before the call even starts.

And yes-WebRTC implementations still vary. 37.5% don’t follow RFC 3264 perfectly. That’s why interoperability between browsers and SIP systems sometimes fails. But the core model remains the anchor.

Final Thought: Simplicity Is the Strength

The SDP Offer/Answer model isn’t flashy. It doesn’t have a marketing team. But it’s the reason your video call doesn’t drop when you switch from Wi-Fi to cellular. It’s why your office phone works with your Zoom client. It’s why VoIP scales across the globe.

It works because it’s simple. One side speaks. The other listens. They find common ground. No drama. No guesswork. Just rules.

If you’re building, managing, or troubleshooting VoIP systems, understand this model. Not just the theory-know the ports, the codecs, the ptime, the zero. Because when a call fails, it’s not a network issue. It’s an SDP issue. And you’ll be the one who fixes it.