What is SDP?
Before two devices can start a WebRTC call, they need to agree on a lot of details: which codecs to use, where to send the media, how to secure it. SDP is the plain-text document they exchange to work all of that out.
The one-sentence version
SDP stands for Session Description Protocol. It is not a way of sending audio or video itself. It is a description, a structured list of facts about a proposed session, that one side sends and the other side reads and responds to. Think of it as the spec sheet for a call, agreed before a single packet of actual voice moves.
What a real SDP looks like
It looks intimidating at first, a dense block of short lines each starting with a single letter, but every line has a specific, learnable job:
v=0 o=- 46117317 2 IN IP4 127.0.0.1 s=- t=0 0 m=audio 9 UDP/TLS/RTP/SAVPF 111 a=ice-ufrag:4hI2 a=fingerprint:sha-256 8B:XX:... a=rtpmap:111 opus/48000/2 a=sendrecv
Read outside in: v= is just the SDP version. o= identifies who created this description. m= announces a media line, in this case audio, and which codec payload types it is willing to use. Everything starting with a= is an attribute, extra detail attached to that media line.
The three attributes that actually matter
Out of the dozens of possible attribute lines, three are doing almost all of the real work:
- a=rtpmap lists which codec goes with which payload number, so both sides agree exactly how the audio is encoded.
- a=ice-ufrag and a=ice-pwd are the credentials the two sides use during ICE negotiation, so a stray packet from someone else cannot get mistaken for part of your call.
- a=fingerprint is a hash of the certificate each side will use to encrypt the media itself. This is what lets a WebRTC call verify it is still talking to the same device it started the handshake with.
Paste a real SDP and see it decoded
The SDP Analyzer takes a real offer or answer and breaks it down line by line into plain English: which codecs, which ICE credentials, which security settings, and what direction the media flows.
Open the SDP Analyzer →Why this matters when a call fails
Most WebRTC connection failures trace back to a mismatch somewhere in these two documents, the offer and the answer. If neither side lists a shared codec, there is nothing to play. If the ICE credentials do not match what actually arrives, the connection is rejected outright. Reading an SDP is how you find out which of these actually happened, instead of just seeing a call that silently never connects.