SIP SDP refers to the pairing of the Session Initiation Protocol (SIP), which signals and manages calls, with the Session Description Protocol (SDP), which negotiates the media details of those calls. SIP carries SDP inside message bodies such as INVITE and 200 OK, and the two protocols use an offer/answer model to agree on codecs, ports, and addresses before RTP media flows. VideoSDK uses this same SIP-SDP foundation to bridge traditional telephony into WebRTC rooms, as described in the VideoSDK telephony docs. Every reliable VoIP and RTC system depends on getting this negotiation right, and this guide explains exactly how it works.
Building a VoIP service that drops calls, sends one-way audio, or fails behind corporate firewalls usually traces back to one root cause: the developer treated SIP and SDP as a black box. SIP handles the signaling, the "who wants to talk to whom" part of a call. SDP handles the media, the "what codec, what port, what address" part. When the two are misunderstood, calls connect but audio never flows, or codecs mismatch and one side hears silence.
This guide walks through both protocols, how they couple inside a SIP INVITE, the offer/answer negotiation model, every major SDP field, the full call setup flow, early media, common pitfalls, and practical debugging techniques. By the end, you will be able to read a raw SIP-SDP exchange and diagnose exactly where a call went wrong.
What Is SIP?
SIP is defined as a text-based application-layer signaling protocol used to create, modify, and terminate multimedia sessions over IP networks. It is standardized in SIP RFC 3261, published by the IETF, and it borrows its request/response structure from HTTP, which makes it comparatively readable when you capture it on the wire.
SIP works by exchanging messages between user agents, the endpoints that place and receive calls, often routed through SIP proxies that handle addressing and forwarding. Core requests include INVITE to start a session, ACK to confirm it, BYE to end it, and CANCEL to abandon a ringing call. Responses use numeric codes: 100 Trying, 180 Ringing, 183 Session Progress, 200 OK, and error classes in the 4xx and 5xx ranges.
The critical thing to understand is that SIP itself knows nothing about audio or video. It is a session management envelope. All media capability information travels inside SIP message bodies, and that body is almost always SDP. This separation of concerns is deliberate: it lets SIP evolve independently of media technology, which is why the same SIP stack can negotiate a plain phone call or a WebRTC session.
What Is SDP?
SDP is defined as a protocol for describing multimedia sessions, conveying the details a receiver needs to participate: media types, transport addresses, ports, transport protocols, and payload formats. It is standardized in SDP RFC 4566, which obsoletes the earlier SDP RFC 2327 that many older systems still reference.
SDP works by providing a structured, line-based description of a session. Each line begins with a single letter followed by an equals sign, and each letter has a fixed meaning: the version line, the origin line, the session name, the connection information, timing, and one or more media descriptions. Because it is plain text, you can read an SDP body directly in a packet capture, which makes debugging far easier than with binary formats.
SDP does not negotiate by itself. It is a description format. The negotiation logic comes from the offer/answer model defined in RFC 3264, where one side proposes a set of capabilities and the other side selects from them. In practice, teams integrating SIP trunks into real-time communication platforms consistently find that most interop failures are SDP failures, not SIP failures: the signaling succeeded, but the media description was unusable.
How SIP and SDP Work Together
SIP and SDP work together through a strict division of labor: SIP establishes and manages the call dialog, while SDP, carried as a message body inside SIP requests and responses, negotiates the media session that the dialog controls. The coupling happens at well-defined points in the call flow, primarily the INVITE and the final response.
The mechanism is the offer/answer model. One party, usually the caller, sends an SDP offer listing every media configuration it is willing to support: which audio codecs, which ports, which transport. The other party examines the offer and returns an SDP answer selecting one option from each offered media stream. Neither side can introduce capabilities the other did not offer, and the answer must match the structure of the offer. Once the answer is delivered, both endpoints know exactly how to send and receive media, and RTP packets begin flowing directly between them, typically bypassing the SIP proxies entirely.
This is the single most important architectural insight for developers: SIP signaling and RTP media travel different paths. Proxies route the SIP messages, but media usually flows peer to peer. When audio fails but signaling works, the problem is almost always in the SDP exchange or the network path it described, not in the SIP routing.
SIP INVITE with SDP Offer
The call begins when the caller's user agent sends an INVITE request toward the callee. The INVITE carries routing headers, the destination address, and a message body containing the SDP offer. The body is marked with a MIME type indicating session description content, which tells the receiver how to parse it.
The SDP offer inside the INVITE contains the essential lines a developer should recognize: the version line marking the SDP format, the origin line with a session identifier and version number, the session name, the connection line giving the IP address where media should be sent, the timing line, and one or more media lines each listing a media type, port, transport protocol, and the payload types the caller supports. Attribute lines add details like codec mappings and direction of media flow.
SDP Answer in 200 OK
When the callee answers, its user agent returns a 200 OK response for the INVITE, and that response carries the SDP answer. The answer mirrors the structure of the offer: for every media line the caller proposed, the answer includes a corresponding media line selecting one payload type from the offered list.
The answer's connection line tells the caller where to send its RTP packets, and its port numbers tell it where to send them. If the callee cannot support a proposed media stream at all, it signals this by answering that media line with a port of zero, which cleanly rejects that stream without failing the whole session. The caller completes the handshake by sending an ACK, and the dialog is fully established with agreed media parameters on both sides.
Key SDP Fields Explained
Reading SDP fluently is the core skill for debugging VoIP systems. Every SDP body is a sequence of single-letter lines, each with a defined purpose. Here is what each major field means in practice.
The version line must always be first and always contain the same value, since there is only one SDP version in widespread use. The origin line provides a globally unique session identifier composed of a username, a session identifier numeric string, a version number, the network type, an address type, and the originating address. The session version number matters: it must be incremented every time the session description changes, and endpoints use it to detect stale or out-of-order descriptions.
The session name line is a human-readable label, often left generic. The information, URI, email, and phone lines are optional descriptive metadata, rarely used in machine-to-machine calls. The connection line specifies the network type, address type, and the IP address where media should be sent. The bandwidth line optionally declares bandwidth limits for the session or a media stream. The timing line gives the start and stop times of the session, and for interactive calls it conventionally uses values meaning "now and unbounded." The repeat and zone lines support scheduled recurring sessions and are irrelevant for calls. The encryption key line is a legacy field, obsolete in modern systems. Attribute lines carry the bulk of the practical detail, and media lines define each media stream.
The SDP Connection Line
The connection line conveys the network type, address type, and the IP address where the remote party should send media. In most calls it appears once at the session level and applies to all media streams, though each media line can override it with its own connection line, which is common in multicast or multi-homed scenarios. For developers, this is the line to check first when audio is missing: if the address in the answer is unreachable, perhaps a private IP behind NAT, RTP will never arrive.
The SDP Media Line
The media line defines one media stream: the media type such as audio or video, the port number where that stream should be received, the transport protocol, typically RTP over UDP or its secure variant, and a list of payload type numbers representing the offered codecs. Each payload type listed here is further described by attribute lines. A media line with a port of zero means the stream is declined. When reading captures, compare the offered and answered media lines side by side: the answer must pick from the offered payload types, and a mismatch here is a classic interop bug.
SDP Attribute Lines
Attribute lines carry everything else. The attribute that maps payload type numbers to actual codec names and clock rates is essential, because the numbers themselves are arbitrary labels. Format-specific parameter attributes refine codec configuration, such as sample rates or channel counts. Direction attributes like sendrecv, sendonly, recvonly, and inactive declare whether media flows both ways, one way, or not at all, and a missing or wrong direction attribute is a frequent cause of one-way audio. In modern WebRTC-adjacent systems, attributes also carry ICE username fragments and passwords, candidate information, and DTLS fingerprint details, which enable secure media establishment across NATs.
SIP Call Flow with SDP
A complete SIP call setup with SDP negotiation follows a predictable sequence. The caller sends an INVITE carrying the SDP offer. The proxy or SIP server routes the INVITE toward the callee and typically sends back a 100 Trying response to stop the caller from retransmitting. When the callee's phone starts ringing, it sends 180 Ringing, which may or may not carry SDP depending on whether early media is in play. When the callee answers, a 200 OK returns carrying the SDP answer. The caller confirms with an ACK, and from that moment RTP media flows directly between the two endpoints while SIP dialog state sits idle until a BYE ends the call.
The following diagram shows the full sequence:
Two details in this flow deserve developer attention. First, the 100 Trying is hop-by-hop, generated by proxies, while the 180 and 200 are end-to-end, generated by the callee's user agent. Second, media can begin flowing before the 200 OK in early media scenarios, which is where many subtle bugs live.
Early Media and SDP
Early media is media that flows before the call is answered, and it is signaled with a 183 Session Progress response carrying an SDP answer. The classic use case is the ringback tone you hear while waiting for someone to pick up: rather than the caller's own phone generating a local ringing sound, the network sends actual audio, which also enables announcements like "the person you are calling is unavailable."
From an SDP perspective, early media means the offer/answer exchange completes at the 183 stage, and RTP starts flowing immediately. The complication is that the final 200 OK may carry a different SDP answer, for example if the call is redirected to voicemail with different codec support, requiring the caller to renegotiate mid-flow. Developers building systems that interconnect SIP trunks with WebRTC rooms, such as routing PSTN callers into a VideoSDK room, must handle both the early media answer and the final answer correctly or callers hear dead air during ringing.
Common Pitfalls When Using SIP and SDP
Most SIP-SDP failures fall into a small set of recurring patterns, and knowing them turns hours of debugging into minutes.
Codec mismatch is the most common: the offer lists payload types the answerer does not support, and instead of selecting a common codec, a buggy implementation answers with an unsupported one, producing silent audio. Missing or malformed connection lines are next: if the answer's connection line is absent or contains an unreachable address, the caller sends RTP into a void. Incorrect port numbers, especially ports that collide with other streams or fall outside allowed ranges, produce one-way or no audio.
NAT traversal is the deepest pitfall. A device behind NAT advertises its private address in the connection line, which is meaningless to the outside world, so media never traverses the NAT. This is precisely the problem ICE and STUN/TURN were designed to solve, and it is why modern SDP bodies carry candidate attributes. Finally, SDP version mismatches cause subtle state bugs: if a re-INVITE updates media but the origin line's session version is not incremented, the remote endpoint may ignore the update entirely.
Best Practices for Reliable SIP-SDP Integration
Reliable integration starts with treating SDP as a contract rather than a formality. Follow these practices and most of the pitfalls above never occur.
Always increment the session version in the origin line whenever the session description changes, including re-INVITEs that change codecs, addresses, or hold state. Include ICE candidates in offers and answers whenever endpoints may sit behind NAT, which in practice means always, and let the ICE framework select a working path rather than trusting the advertised address. Validate media attributes on both sides: confirm that every payload type in an answer was actually offered, that direction attributes match expectations, and that codec mapping attributes are present for every payload type listed.
Handle re-INVITE properly for media changes. Calls on hold, codec changes mid-call, and call transfers all use re-INVITE with updated SDP, and implementations that only handle the initial exchange break on the first hold. When bridging SIP into WebRTC systems, translate SDP media descriptions into the WebRTC media model explicitly, accounting for the fact that WebRTC mandates secure transports while legacy SIP often does not. VideoSDK's telephony and SIP integration handles this translation layer, bridging SIP trunk signaling and SDP negotiation into WebRTC rooms without you writing the gateway logic.
Testing and Debugging Tips
Debugging SIP-SDP issues is a packet capture discipline. Wireshark is the standard tool: it decodes SIP messages and renders SDP bodies in readable form, letting you follow an entire dialog, filter by call identifier, and compare the offer against the answer line by line. SIPp complements it as a traffic generator for load testing and for reproducing specific signaling scenarios against your server.
When examining SDP payloads in a capture, check four things in order: the connection line addresses in both directions, the payload type lists in the offer versus the answer, the direction attributes, and the session version numbers across re-INVITEs. For error responses, read the numeric code and the reason text: a 488 response means the offered media was unacceptable, pointing directly at an SDP problem, while 403 or 404 responses point at routing or authentication instead. If signaling looks perfect but RTP counters show zero packets, you have a network path problem, and the SDP address is your first suspect.
Definitions Glossary
SIP (Session Initiation Protocol): A text-based signaling protocol defined in RFC 3261 that creates, modifies, and terminates multimedia sessions over IP networks. SIP handles call routing and dialog state but carries no media itself.
SDP (Session Description Protocol): A line-based description format defined in RFC 4566 that specifies the media details of a session, including codecs, ports, addresses, and transport protocols. SDP travels inside SIP message bodies.
Offer/Answer Model: The negotiation mechanism defined in RFC 3264 where one endpoint proposes media capabilities in an SDP offer and the other selects from them in an SDP answer. Neither side may introduce unoffered capabilities.
SIP INVITE: The SIP request that initiates a session, typically carrying the SDP offer in its message body. The INVITE begins the call setup dialog between user agents.
Early Media: Media that flows before a call is answered, signaled by a 183 Session Progress response carrying an SDP answer. Commonly used for ringback tones and network announcements.
RTP (Real-time Transport Protocol): The protocol that carries the actual audio and video packets after SDP negotiation completes. RTP typically flows directly between endpoints, bypassing SIP proxies.
Key Takeaways
- SIP manages call signaling while SDP, carried inside SIP message bodies, negotiates the media session, and the two must be understood together to build reliable VoIP systems.
- The offer/answer model is the heart of SIP-SDP negotiation: the INVITE carries the offer, the 200 OK carries the answer, and the answer must select strictly from what was offered.
- Most "connected but silent" calls are SDP failures, not SIP failures, and the connection line, media line, and direction attributes are the first places to look.
- NAT traversal remains the deepest pitfall, and including ICE candidates in SDP is the modern answer to private-address problems.
- VideoSDK bridges SIP-SDP telephony into WebRTC rooms through its built-in SIP integration, handling the gateway translation layer for you.
Conclusion
Mastering SIP SDP means understanding two protocols with one job: SIP gets the call connected, SDP gets the media flowing, and the offer/answer exchange is the handshake between them. Developers who can read an SDP body in a packet capture diagnose in minutes what others chase for days, from codec mismatches to NAT failures to early media edge cases. Apply the best practices here, validate every answer against its offer, and treat session versioning with respect. To see how SIP-SDP telephony bridges into modern WebRTC rooms, explore the VideoSDK telephony documentation or start free at app.videosdk.live. What are you building with SIP and SDP? Drop a comment, I'd love to hear what kind of telephony integration you're working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ