SDP (Session Description Protocol, RFC 4566) is the text format SIP carries to describe a media session — the IP address, ports, media types and codecs each side offers. It is not a transport; it is a description. SIP uses it in an offer/answer exchange (RFC 3264) to negotiate the media the endpoints will exchange over RTP.
What SDP is
SDP is a small, line-based text format that describes a multimedia session: what media (audio, video), where to send it (connection address and port), which codecs are acceptable, and in which direction it may flow. SIP does not interpret the media itself; it carries the SDP in the message body (Content-Type: application/sdp) and lets the endpoints agree parameters. SDP is purely descriptive — it conveys no media and negotiates nothing on its own; the negotiation comes from how SIP exchanges two SDP bodies.
The line structure
An SDP body is a sequence of single-letter type lines in a fixed order, split into a session-level section followed by one or more media-level sections that each begin with an m= line. The most important are o= (origin and session id), c= (connection address), m= (media type, port, transport and formats) and the a= attribute lines that carry codec maps and direction. Lines are ordered and case-sensitive.
| Line | Name | Carries |
|---|---|---|
| v= | Version | SDP version (0) |
| o= | Origin | Username, session id/version, network/address |
| s= | Session name | A label for the session |
| c= | Connection | Network type, address type and the media IP address |
| t= | Timing | Start/stop time (0 0 for an unbounded call) |
| m= | Media | Media type, port, transport (RTP/AVP…) and formats |
| a= | Attributes | rtpmap, fmtp, ptime, direction (sendrecv…) and more |
The offer/answer model
SIP negotiates media with the offer/answer model of RFC 3264. One endpoint sends an SDP offer (typically in the INVITE) listing the media streams and every codec it is willing to use. The other returns an SDP answer (typically in the 200 OK) selecting from what was offered — keeping only codecs it also supports, in its preferred order, and setting the direction. The result is the intersection both sides agreed on. A mismatch with no common codec is what produces a 488 Not Acceptable Here.
v=0
o=alice 2890844526 2890844526 IN IP4 host.example.com
s=-
c=IN IP4 198.51.100.10
t=0 0
m=audio 49170 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:20
a=sendrecvCodecs and payload types
The m= line lists RTP payload type numbers, and each a=rtpmap maps a number to a codec and clock rate. Payload types 0–95 include static assignments (0 = PCMU/G.711 µ-law, 8 = PCMA/G.711 A-law, 9 = G722, 18 = G729), while 96–127 are dynamic and must be defined by an rtpmap. a=fmtp carries codec-specific parameters, and telephone-event (RFC 4733) is how DTMF is negotiated. Listing codecs in preference order lets the answerer pick the best mutually supported one.
| PT | Codec | Clock | Note |
|---|---|---|---|
| 0 | PCMU (G.711 µ-law) | 8000 | Static; ~64 kbit/s toll quality |
| 8 | PCMA (G.711 A-law) | 8000 | Static; ~64 kbit/s toll quality |
| 9 | G722 | 8000 | Wideband (16 kHz audio) |
| 18 | G729 | 8000 | Static; ~8 kbit/s compressed |
| 96–127 | Dynamic (Opus, telephone-event…) | varies | Defined by a=rtpmap |
Media direction attributes
An a= direction attribute sets how media flows for a stream. sendrecv is the normal bidirectional default. sendonly and recvonly restrict flow to one direction — used for hold, announcements and one-way media. inactive stops media entirely while keeping the session up. Toggling these (for example sendonly ⇄ sendrecv in a re-INVITE) is how call hold, resume and music-on-hold are implemented without dropping the dialog.
| Attribute | Meaning |
|---|---|
| a=sendrecv | Send and receive media (default) |
| a=sendonly | Send only (e.g. announcement, or the held party) |
| a=recvonly | Receive only (e.g. the party placed on hold) |
| a=inactive | No media in either direction; session stays up |
Frequently asked
What is SDP used for in SIP?
SDP describes the media session — the IP address, ports, media types and codecs each endpoint offers. SIP carries two SDP bodies in an offer/answer exchange to negotiate what audio or video the endpoints will exchange over RTP. SDP itself carries no media.
What is the SIP offer/answer model?
Defined in RFC 3264, it is how SIP negotiates media: one side sends an SDP offer (often in the INVITE) listing its media and codecs, and the other returns an SDP answer (often in the 200 OK) selecting the subset it also supports. The agreed intersection is what flows.
What does the m= line mean in SDP?
The m= (media) line declares a media stream: its type (audio/video), the port to send to, the transport (e.g. RTP/AVP or RTP/SAVP for SRTP), and the list of RTP payload-type numbers offered. Each payload type is then described by an a=rtpmap line.
How are codecs chosen in a SIP call?
The offerer lists acceptable codecs in preference order in the SDP. The answerer keeps only those it also supports and returns them, effectively selecting the best mutually supported codec. If the sets do not intersect, negotiation fails, typically with a 488 Not Acceptable Here.
How is call hold done with SDP?
By changing the media direction attribute in a re-INVITE — for example setting a=sendonly (or historically a zero connection address) to place the far party on hold, and a=sendrecv to resume. The dialog stays up; only the media direction changes.
Source specifications
The published standards this page is grounded in. Opens in a new tab.