TheVoĉoTheVoĉo
Platform

What Is SDP in SIP? Media Negotiation Explained Simply

Unravel the mystery of Session Description Protocol (SDP) in SIP. Learn how SDP enables devices to negotiate media parameters like codecs, IP addresses, and ports, making VoIP calls possible. Essential for VoIP engineers and developers.

Product Team
Product Team
•5 min read
Illustration for What Is SDP in SIP? Media Negotiation Explained Simply

What Is SDP in SIP? A Brief Introduction

Session Description Protocol (SDP) isn't the media itself, but rather the blueprint for a multimedia session. Within the context of Session Initiation Protocol (SIP), SDP is a lightweight text-based protocol used to describe the parameters of a media session, such as audio, video, or data. It informs participants about what types of media they can handle, where to send it, and how to decode it, making successful communication possible.

Why SDP Exists: Solving the Media Negotiation Puzzle

Imagine two people trying to talk on the phone, but one only speaks English and the other only Spanish, and they also need to decide which phone line to use. Without a way to agree on a common language and connection, communication is impossible.

This is precisely the problem SDP solves in VoIP. SIP handles the signaling – setting up, managing, and tearing down calls – but it doesn't describe the actual media (audio, video, text) itself. Before any audio or video can flow, the communicating endpoints (e.g., two IP phones) need to agree on several crucial media parameters. These include:

  • Codecs: Which audio/video compression algorithms (e.g., G.711, G.729, Opus, H.264) they both support.
  • IP Addresses and Ports: Where on the network each device will send and receive media (Real-time Transport Protocol or RTP) packets.
  • Directionality: Whether media will be sent, received, or both (e.g., one-way audio scenarios).
  • Security: Whether encryption like SRTP (Secure RTP) is desired and how to establish it.

SDP provides a standardized, interoperable way for SIP devices to exchange this vital information, ensuring that when they finally try to send media, they're both speaking the same language on the correct lines.

How SDP Works: The Offer/Answer Model

SDP operates primarily through an Offer/Answer model. Here's a simplified step-by-step breakdown:

  1. The Offer: When a user initiates a call (e.g., picking up the phone and dialing), their SIP device (User Agent Client or UAC) sends a SIP INVITE message. Crucially, this INVITE contains an SDP Offer within its message body. This offer describes all the media capabilities the UAC is willing or able to use (e.g., "I can send audio using G.711 or G.729, and I'll listen on IP 192.168.1.100 port 10000").

  2. The Answer: The receiving SIP device (User Agent Server or UAS) gets the INVITE and its SDP Offer. It then examines its own capabilities and preferences. It chooses the parameters that are mutually supported and sends back an SDP Answer in a SIP response (typically a 200 OK message). This answer represents the agreed-upon common ground (e.g., "Okay, I also support G.711, and I'll send audio to your 192.168.1.100:10000, and you send to my 192.168.1.101:20000").

  3. Media Flow: Once both devices have exchanged and processed the SDP Offer and Answer, they have successfully negotiated the media parameters. They now know which codec to use, which IP addresses and ports to send RTP packets to, and can begin streaming audio or video.

Key SDP Lines Explained

SDP messages consist of several lines, each starting with a single lowercase letter followed by an equals sign (=). While many SDP lines exist, some are fundamental for media negotiation:

  • v=0: Protocol Version. Always 0 for current SDP specifications.
  • o=<username> <sess-id> <sess-version> <nettype> <addrtype> <address>: Originator. Identifies the creator of the session. The sess-id and sess-version are crucial for identifying unique sessions and detecting changes.
  • s=<session name>: Session Name. A human-readable name for the session.
  • c=<nettype> <addrtype> <connection-address>: Connection Information. This line specifies the IP address where the media stream (RTP) should be sent. This is often the most critical line for troubleshooting connectivity, especially with NAT.
  • t=<start-time> <stop-time>: Time Description. For SIP calls, this is typically t=0 0, indicating an unbounded session.
  • m=<media> <port> <proto> <fmt> ...: Media Description. This is the heart of media negotiation. It specifies:
    • <media>: The type of media (e.g., audio, video, text).
    • <port>: The RTP port number the sender wishes to use for this media stream.
    • <proto>: The transport protocol for the media (e.g., RTP/AVP for unencrypted RTP over UDP, RTP/SAVP for SRTP).
    • <fmt>: A space-separated list of payload type numbers, indicating the codecs and other formats the sender supports. These numbers are mapped to specific codecs using a=rtpmap lines.
  • a=<attribute>:<value>: Attributes. These provide additional information about the media. Key attributes for media negotiation include:
    • a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]: Maps a payload type number from the m= line to a specific codec (e.g., a=rtpmap:0 PCMU/8000 maps payload type 0 to G.711 PCMU audio at 8kHz sampling rate). This is essential.
    • a=sendrecv, a=sendonly, a=recvonly, a=inactive: Indicate the directionality of the media stream.
    • a=ptime:<milliseconds>: Preferred packetization time (how much audio/video data in each RTP packet).
    • a=fmtp:<payload type> <format parameters>: Format-specific parameters for a codec (e.g., a=fmtp:101 0-16 for DTMF).

Example: A Minimal SDP Exchange

Here's a simplified SDP offer from a SIP INVITE:

v=0
o=alice 2890844526 2890844526 IN IP4 client.atl.example.com
s=SDP Call
c=IN IP4 192.0.2.1
t=0 0
m=audio 50000 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

Explanation:

  • c=IN IP4 192.0.2.1: Alice wants to receive media on IP address 192.0.2.1.
  • m=audio 50000 RTP/AVP 0 8 101: She proposes an audio stream on UDP port 50000, using RTP/AVP, and offers codecs identified by payload types 0, 8, and 101.
  • a=rtpmap:0 PCMU/8000: Payload type 0 is G.711 PCMU.
  • a=rtpmap:8 PCMA/8000: Payload type 8 is G.711 PCMA.
  • a=rtpmap:101 telephone-event/8000: Payload type 101 is for DTMF tones.
  • a=sendrecv: Alice wants to both send and receive audio.

Now, a corresponding SDP Answer from Bob in a 200 OK:

v=0
o=bob 2890844527 2890844527 IN IP4 server.chicago.example.com
s=SDP Call
c=IN IP4 199.1.1.100
t=0 0
m=audio 60000 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv

Explanation:

  • c=IN IP4 199.1.1.100: Bob will receive media on 199.1.1.100.
  • m=audio 60000 RTP/AVP 8 101: He accepts audio on UDP port 60000. Notice he only lists payload types 8 and 101, as these are the ones he supports from Alice's offer. He explicitly dropped payload type 0 (PCMU) because he might not support it or prefers PCMA.

After this exchange, both parties agree to use G.711 PCMA (payload type 8) and DTMF (payload type 101). Alice will send RTP to 199.1.1.100:60000, and Bob will send RTP to 192.0.2.1:50000.

Diagram: Where SDP Fits in the Call Flow

sequenceDiagram
    participant A as Alice (UAC)
    participant S as SIP Proxy/Registrar
    participant B as Bob (UAS)

    A->>S: SIP INVITE (SDP Offer)
    S->>B: SIP INVITE (SDP Offer)
    Note right of S: SIP routes call to Bob
    B->>S: SIP 200 OK (SDP Answer)
    S->>A: SIP 200 OK (SDP Answer)
    Note left of A: Media parameters negotiated
    A-->>B: RTP Media (using negotiated parameters)
    B-->>A: RTP Media (using negotiated parameters)
    Note over A,B: Voice/Video conversation begins

Common Mistakes and Troubleshooting SDP

SDP issues are a frequent cause of

Tags:sdpsipvoiprtpcodecs
Back to all posts