What Is SDP in VoIP? Meaning, Structure, Examples, and Why It Matters

Many people first learn SIP, RTP, WebRTC, or Asterisk — and then suddenly start seeing SDP inside SIP traces, browser console logs, PBX debug output, SBC captures, or Wireshark. That is usually the exact moment VoIP starts feeling confusing. 😅

This article fixes that confusion properly.

We go from absolute beginner → practical engineer → advanced troubleshooting mindset, while keeping the explanation friendly and visual.

🚀 First, the simplest explanation possible

SDP stands for Session Description Protocol.

But the full form alone does not help much.

The practical meaning is this:

In a call, SDP answers questions like:

• what kind of media is being offered: audio, video, application data
• which codecs are supported: Opus, PCMU, PCMA, G.722, H.264, VP8, and so on
• which IP address and port should receive media
• whether the side can send, receive, both, or neither
• what transport/security profile is expected
• which WebRTC details are needed: ICE, DTLS fingerprint, BUNDLE, RTCP mux, candidates

🧠 One mental model that makes SDP easy

Think of a call like this:

The shortest memory trick is: SIP says “let’s talk”, SDP says “here’s how”, RTP says “here is the media”, and RTCP says “here is how well it is going”.

📡 Visual map: SIP controls, SDP describes, RTP carries

🏗️ Which layer does SDP belong to?

This confuses many beginners because SDP talks about IP addresses, ports, codecs, and media transport, so it looks “low-level”. But SDP itself is not a transport-layer protocol like UDP, and it is not a network-layer protocol like IP.

The clean answer is:

In practical terms:
• IP moves packets between hosts
• UDP/TCP/TLS transport application bytes between endpoints
• SIP / HTTP / WebSocket may carry signaling or session-related data
• SDP is the structured media description used by those systems to describe the session

🧱 Layer diagram: where SDP fits

🔗 Which protocols and systems use SDP?

SDP does not usually work alone. It is commonly carried inside another signaling flow.

Important practical point: SDP is often embedded in another message body. That is why engineers usually say “SIP INVITE containing SDP” instead of “SDP packet” in the strict sense.

📦 Is SDP a packet?

Strictly speaking, SDP is not a packetized media protocol like RTP.

RTP has packet headers, timestamps, sequence numbers, payload types, SSRC values, and actual media payloads. SDP is different. SDP is a structured text document.

In SIP, SDP usually appears as the body after headers like:

Content-Type: application/sdp
Content-Length: 245

And then the body contains SDP lines like this:

v=0
o=- 3747 3747 IN IP4 192.168.1.10
s=VoIP Call
c=IN IP4 192.168.1.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

🔍 Read a real SDP body line by line

v=0
o=- 3747 3747 IN IP4 192.168.1.10
s=VoIP Call
c=IN IP4 192.168.1.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

🧾 The most important SDP fields you will keep seeing

When engineers troubleshoot calls, these are the lines they keep coming back to:

🧠 How offer/answer works

The most important real-world model in SDP is offer / answer.

One side sends an offer describing what it can do. The other side replies with an answer describing what it accepts. The final media behavior comes from that negotiation.

That means a call can signal successfully yet still fail in media if the offer/answer result is broken, incomplete, mismatched, or points to the wrong network path.

🪜 Beginner → intermediate → advanced understanding

🆚 SDP vs SIP vs RTP vs RTCP vs HTTP

🛠️ A SIP message carrying SDP

Here is a simplified SIP INVITE showing how SDP appears inside the message body:

INVITE sip:1002@pbx.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.10:5060;branch=z9hG4bK-12345
From: "Alice" <sip:1001@pbx.example.com>;tag=abc123
To: <sip:1002@pbx.example.com>
Call-ID: 9f8e7d6c@example.com
CSeq: 1 INVITE
Contact: <sip:1001@192.168.1.10:5060>
Content-Type: application/sdp
Content-Length: 245

v=0
o=- 3747 3747 IN IP4 192.168.1.10
s=VoIP Call
c=IN IP4 192.168.1.10
t=0 0
m=audio 49170 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

So when people say “SIP call setup”, they are often really looking at SIP + SDP together. SIP manages the session; SDP describes the media plan inside it.

🎙️ How codec negotiation really works

Codec negotiation is not magic. It is basically a matching problem.

Suppose the offer contains:

m=audio 49170 RTP/AVP 111 0 8
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

And the remote side only supports:

m=audio 52000 RTP/AVP 0
a=rtpmap:0 PCMU/8000

Then the negotiated result is usually PCMU, because that is the common codec both sides accept.

If there is no common codec, the signaling may proceed partially, but media can fail, fallback, or be rejected depending on the system.

🔁 Media directions: sendrecv, sendonly, recvonly, inactive

One of the most important beginner-to-advanced concepts is media direction. The direction attributes decide whether a stream is active for sending, receiving, both, or neither.

This is why a call can “connect” but one side hears nothing: the negotiated direction may not actually allow two-way audio.

🌐 Why IP address and port details are such a big deal

Many “audio problems” are actually address/port problems.

The SDP might say:

c=IN IP4 192.168.1.10
m=audio 49170 RTP/AVP 0 8 101

That means: “send audio to 192.168.1.10 port 49170”.

But if the remote party is outside your LAN, and that private IP is not reachable from outside, the remote side may send RTP into a black hole. The SIP call itself may still look fine.

🔐 How SDP becomes more advanced in WebRTC

In classic SIP telephony, SDP may look fairly small. In WebRTC, SDP becomes much richer because the browser needs far more detail to establish secure media across NATs and changing networks.

WebRTC SDP often contains:

• ICE usernames and passwords
• ICE candidates
• DTLS fingerprints
• setup roles like actpass
• rtcp-mux
• BUNDLE group and media IDs
• secure transport profiles like UDP/TLS/RTP/SAVPF
• richer codec and header-extension attributes

m=audio 9 UDP/TLS/RTP/SAVPF 111 0 8
a=mid:0
a=sendrecv
a=rtcp-mux
a=ice-ufrag:8hY2
a=ice-pwd:Qm8sLk2jP0mYx2c1
a=fingerprint:sha-256 12:34:56:78:...
a=setup:actpass
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=candidate:1 1 UDP 2130706431 192.168.1.10 54400 typ host

So if classic SIP SDP feels like a media address card, WebRTC SDP feels more like a full connection workbook. 📘

🧊 SDP and NAT traversal: why WebRTC depends so much on ICE

In simple LAN voice systems, an IP and port may be enough. But on the public internet, endpoints are often behind NAT, firewalls, VPNs, home routers, or mobile carrier networks.

That is where ICE comes in. ICE allows a side to advertise multiple possible network candidates and then test which path actually works.

This is why a WebRTC call may “signal fine” but still have no audio: the SDP exchange succeeded, but ICE never found a usable media path.

⚠️ Common real-world problems caused by SDP

🧪 How engineers troubleshoot SDP in real systems

When a call fails, experienced engineers often go through this checklist:

🔄 Re-INVITE, UPDATE, and mid-call changes

A common beginner mistake is thinking SDP only matters at the start of the call. In reality, SDP may change during the session too.

Mid-call SDP changes can be used for:

• hold and resume
• changing codecs or adding/removing streams
• switching media endpoints or proxies
• upgrading or modifying security state
• enabling video after audio already started

That is why “it worked for 20 seconds and then audio died” can still be an SDP problem: the initial negotiation was okay, but the later one was not.

🧩 What SDP commonly describes in real systems

In practical deployments, SDP commonly describes these things:

🎙️ Media type
audio / video / application

🎚️ Codec support
Opus, PCMU, PCMA, G.722, AMR, H.264, VP8, telephone-event, and more

🌐 Media destination
which IP address or candidates are associated with media

🚪 Port information
which UDP port is expected for RTP or SRTP

🔁 Direction
sendrecv / sendonly / recvonly / inactive

🔐 Security information
DTLS fingerprint, SRTP transport profile, setup role, secure media expectations

🧊 NAT traversal data
ICE credentials, candidates, bundle groups, mids, multiplexing data

📞 Telephone-event / DTMF
how keypad events are transmitted during the call

📚 A practical glossary of important SDP terms

🧪 Mini troubleshooting examples

❓ Quick FAQ

📝 Beginner-to-expert summary

Here is the clean progression to remember:

Beginner 🔹
SDP is the text that says how media should happen in a call.

Intermediate 🔹
SIP often carries SDP. SDP lists codecs, IPs, ports, media types, and direction. RTP then sends the actual audio or video using that agreed information.

Advanced 🔹
SDP is an application-layer session description payload used in offer/answer negotiation. It affects codec selection, media routing, hold state, NAT traversal, secure media, and mid-call changes.

Expert 🔹
In real troubleshooting, you must validate the final negotiated SDP, not just the signaling success. The true question is: what media path was actually negotiated, and was that path truly usable?

✅ Final takeaway

If SIP is the conversation about starting a call, and RTP is the real sound of the call, then SDP is the agreement sheet that tells both sides how that sound should be exchanged.

It is not “just a full form”. It is one of the most practical concepts in VoIP, SIP, WebRTC, Asterisk, FreePBX, SBCs, gateways, cloud calling, and AI voice systems.

Once you truly understand SDP, many telecom problems stop looking random. They become traceable: codec issue, IP issue, port issue, direction issue, ICE issue, DTLS issue, or negotiation issue. 🎯