SIP & SDP Explained: The Complete Practical Guide (With Examples)

SIP (Session Initiation Protocol) is a signaling protocol used to establish, modify, and terminate real-time communication sessions like voice and video calls, messaging, and multimedia conferences over IP networks. Think of it as the traffic controller or the setup crew for your communication. SDP (Session Description Protocol), its indispensable companion, is a text-based format that describes the media characteristics—what kind of audio/video, supported codecs, bandwidth, and where to send it—once a SIP session is established. Together, they form the backbone of modern VoIP.

Before SIP, setting up calls over IP was fragmented, relying on proprietary systems that hindered interoperability. SIP emerged to standardize how communication endpoints (like VoIP phones, softphones, and gateways) discover each other, negotiate session parameters, and manage the entire lifecycle of a call, much like HTTP provides a standard for web browsing. It solved the critical problem of creating an open, extensible, and flexible framework for real-time multimedia communications. SDP then became crucial for handling the complexities of media exchange, allowing diverse devices to agree on how to talk to each other by specifying technical details like codecs and transport addresses. This separation of signaling (SIP) from media description (SDP) is a key strength, allowing for immense flexibility.

Understanding the SIP call flow is fundamental. It's a transaction-based protocol, meaning messages are exchanged in request-response pairs. A typical sip call flow from initiation to termination follows these key steps:

1. Initiation (INVITE): The calling party (User Agent Client - UAC) sends a SIP INVITE request, signaling intent to establish a call. This message, central to sip explained, usually carries an embedded SDP "offer" detailing the UAC's media capabilities (codecs, IP, ports), initiating media negotiation. [/blog/what-is-sip][/blog/sip-invite-explained]

2. Ringing (180 Ringing): The called party's device (User Agent Server - UAS), if available, responds with a 180 Ringing, indicating the callee's device is alerting.

3. Session Progress (183 Session Progress with SDP): Often used for early media (e.g., network-generated ringback tone), this response can include an SDP "answer," allowing preliminary media negotiation to start before the call is officially answered.

4. Acceptance (200 OK with SDP): When the callee answers, the UAS sends a 200 OK. This definitive acceptance must contain the final SDP "answer," indicating accepted capabilities and the UAS's media destination. The sdp offer/answer model is now complete.

5. Acknowledgment (ACK): The UAC acknowledges the 200 OK with an ACK message, finalizing the session establishment handshake. Media (RTP) can now flow directly between endpoints based on negotiated SDP.

6. Termination (BYE): Either party ends the call by sending a BYE request. The other party responds with a 200 OK to confirm termination. [/blog/sip-call-flow-explained][/blog/sip-response-codes]

Let's analyze a simplified SIP INVITE message with its embedded SDP offer, a practical illustration of sdp explained in action. This message initiates a call from [email protected] to [email protected].

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK-abcd-1234
Max-Forwards: 70
From: Alice <sip:[email protected]>;tag=12345
To: Bob <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 172

v=0
o=alice 2890844526 2890844526 IN IP4 192.0.2.1
s=SIP 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

In this real-world example:

• The SIP INVITE method requests to establish a session.
• SIP Headers like Via, From, To, Call-ID, CSeq, and Contact are crucial for routing, identifying parties, managing the transaction, and ensuring responses return correctly. Call-ID uniquely identifies the entire call, while CSeq identifies the specific transaction.
• Content-Type: application/sdp clearly states that the body contains SDP.
• The SDP block (v=0 to a=sendrecv) itself details the media:
  • v=0: SDP version 0.
  • o=alice ...: Originator field, including username, session ID, version, network type (IN=Internet), address type (IP4), and originator's IP.
  • s=SIP Call: Session name.
  • c=IN IP4 192.0.2.1: Connection information, specifying the IP address where media should be sent. This can be at session or media level.
  • t=0 0: Time description, meaning the session is active indefinitely.
  • m=audio 50000 RTP/AVP 0 8 101: Media description line. Specifies an audio stream on UDP port 50000 for RTP, offering payload types 0 (PCMU), 8 (PCMA), and 101 (telephone-event).
  • a=rtpmap...: Attribute lines mapping payload types to specific codecs (e.g., PCMU/8000).
  • a=fmtp:101 0-16: Format parameters for payload type 101, defining DTMF events.
  • a=sendrecv: Attribute indicating Alice can both send and receive media.
    This comprehensive description ensures that Bob's client knows exactly how to communicate with Alice. [/blog/sdp-lines-explained]

sequenceDiagram
    participant A as Alice (UAC)
    participant P as SIP Proxy
    participant B as Bob (UAS)

    A->>P: INVITE sip:[email protected] (SDP Offer)
    P->>B: INVITE sip:[email protected] (SDP Offer)
    B-->>P: SIP/2.0 180 Ringing
    P-->>A: SIP/2.0 180 Ringing
    B-->>P: SIP/2.0 200 OK (SDP Answer)
    P-->>A: SIP/2.0 200 OK (SDP Answer)
    A->>P: ACK
    P->>B: ACK
    Note over A,B: RTP Media Flow (Voice/Video)
    B->>P: BYE
    P->>A: BYE
    A-->>P: SIP/2.0 200 OK
    P-->>B: SIP/2.0 200 OK

While SIP and SDP are powerful, several common pitfalls can turn troubleshooting into a nightmare. Understanding these helps in efficient sip call flow management:

• NAT Traversal Issues: The biggest headache in VoIP. IPs and ports in SDP often reflect private addresses when endpoints are behind NATs, preventing external media flow. Solutions involve STUN, TURN, or Session Border Controllers (SBCs) to rewrite SDP headers with public IPs. [/blog/sip-nat-traversal]
• Incorrect Codec Negotiation: Mismatch in supported codecs (e.g., caller offers G.711, G.729; callee only supports G.722, with no common ground) leads to one-way or no audio. Ensure SDP offer/answer results in a mutually supported codec. Wireshark helps verify this.
• Firewall Blocks: SIP signaling (UDP/TCP 5060/5061) and RTP media (dynamic UDP ports, e.g., 10000-20000) must both be allowed bidirectionally through firewalls. Otherwise, calls set up but lack audio.
• Missing or Malformed SDP: An INVITE without properly formed SDP (or with invalid syntax) prevents media negotiation, causing failed call setups. Check Content-Type and Content-Length headers carefully.
• CSeq Mismatch: CSeq numbers must increment for each new transaction within a call. Mismatches confuse proxies and endpoints, leading to transaction failures.
• Call-ID Duplication: Each SIP session (call) needs a unique Call-ID. Reusing Call-ID for different calls causes misrouting or incorrect session management. [/blog/top-sip-errors]

To deepen your understanding of SIP and SDP, explore these related concepts:

• What is SIP?: A foundational explanation of the Session Initiation Protocol. [/blog/what-is-sip]
• SIP INVITE Explained: Detailed dive into the most critical SIP method. [/blog/sip-invite-explained]
• SIP Call Flow Explained: A comprehensive breakdown of a typical call setup and teardown, crucial for understanding sip call flow. [/blog/sip-call-flow-explained]
• SIP Response Codes: Understanding the status and error codes in SIP for effective troubleshooting. [/blog/sip-response-codes]
• What is SDP?: A closer look at the Session Description Protocol, essential for sdp explained. [/blog/what-is-sdp]
• SDP Offer/Answer Model: How media capabilities are negotiated, a core part of sdp explained. [/blog/sdp-offer-answer]
• SDP Lines Explained: Deciphering the various fields in an SDP message for granular control. [/blog/sdp-lines-explained]
• RTP vs. SRTP: Comparing standard and secure real-time transport protocols for media. [/blog/rtp-vs-srtp]
• SIP NAT Traversal: Strategies for overcoming Network Address Translation challenges in VoIP. [/blog/sip-nat-traversal]
• Top SIP Errors: Common issues and their troubleshooting for engineers. [/blog/top-sip-errors]