# SDP: das Session Description Protocol

> SDP (Session Description Protocol, RFC 4566) ist das Textformat, das SIP trägt, um eine Mediensitzung zu beschreiben — die IP-Adresse, Ports, Medientypen und Codecs, die jede Seite anbietet. Es ist kein Transport; es ist eine Beschreibung. SIP nutzt es in einem Offer/Answer-Austausch (RFC 3264), um die zwischen den Endpunkten über RTP auszutauschenden Medien auszuhandeln.

- Kanonische URL: https://www.broadnet.me/de/reference/sdp-session-description-protocol
- Sprache: de
- Zuletzt aktualisiert: 2026-07-18
- Herausgeber: BroadNet (https://www.broadnet.me)

Wie SDP eine Mediensitzung innerhalb von SIP beschreibt: die Zeilenstruktur v=/o=/s=/c=/t=/m=/a=, das Offer/Answer-Modell (RFC 3264), die Codec-Aushandlung über rtpmap und die Medienrichtungs-Attribute.

## Was SDP ist

SDP ist ein kleines, zeilenbasiertes Textformat, das eine Multimedia-Sitzung beschreibt: welche Medien (Audio, Video), wohin sie zu senden sind (Connection-Adresse und Port), welche Codecs akzeptabel sind und in welche Richtung sie fließen dürfen. SIP interpretiert die Medien selbst nicht; es trägt das SDP im Nachrichten-Body (Content-Type: application/sdp) und lässt die Endpunkte die Parameter vereinbaren. SDP ist rein beschreibend — es übermittelt keine Medien und handelt für sich nichts aus; die Aushandlung ergibt sich daraus, wie SIP zwei SDP-Bodys austauscht.

## Die Zeilenstruktur

Ein SDP-Body ist eine Folge von Ein-Buchstaben-Typzeilen in fester Reihenfolge, aufgeteilt in einen Session-Level-Abschnitt gefolgt von einem oder mehreren Media-Level-Abschnitten, die jeweils mit einer m=-Zeile beginnen. Die wichtigsten sind o= (Origin und Session-ID), c= (Connection-Adresse), m= (Medientyp, Port, Transport und Formate) und die a=-Attributzeilen, die Codec-Maps und Richtung tragen. Die Zeilen sind geordnet und Groß-/Kleinschreibung-abhängig.

*SDP-Zeilentypen*

| Zeile | Name | Überträgt |
|---|---|---|
| v= | Version | SDP-Version (0) |
| o= | Ursprung | Benutzername, Sitzungs-ID/Version, Netzwerk/Adresse |
| s= | Sitzungsname | Eine Bezeichnung für die Sitzung |
| c= | Verbindung | Netzwerktyp, Adresstyp und die Medien-IP-Adresse |
| t= | Timing | Start-/Stoppzeit (0 0 für einen unbegrenzten Anruf) |
| m= | Medien | Medientyp, Port, Transport (RTP/AVP …) und Formate |
| a= | Attribute | rtpmap, fmtp, ptime, direction (sendrecv…) und mehr |

## Das Offer/Answer-Modell

SIP handelt Medien mit dem Offer/Answer-Modell von RFC 3264 aus. Ein Endpunkt sendet ein SDP-Offer (typischerweise im INVITE), das die Medienströme und jeden Codec auflistet, den er zu nutzen bereit ist. Der andere gibt eine SDP-Answer zurück (typischerweise im 200 OK), die aus dem Angebotenen auswählt — nur Codecs behält, die er ebenfalls unterstützt, in seiner bevorzugten Reihenfolge, und die Richtung festlegt. Das Ergebnis ist die Schnittmenge, auf die sich beide Seiten geeinigt haben. Eine Nichtübereinstimmung ohne gemeinsamen Codec erzeugt ein 488 Not Acceptable Here.

*Ein SDP-Offer für einen einzelnen Audiostrom*

```text
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=sendrecv
```

## Codecs und Payload-Typen

Die m=-Zeile listet RTP-Payload-Type-Nummern auf, und jedes a=rtpmap bildet eine Nummer auf einen Codec und eine Taktrate ab. Die Payload-Typen 0–95 umfassen statische Zuweisungen (0 = PCMU/G.711 µ-law, 8 = PCMA/G.711 A-law, 9 = G722, 18 = G729), während 96–127 dynamisch sind und durch ein rtpmap definiert werden müssen. a=fmtp trägt codecspezifische Parameter, und telephone-event (RFC 4733) ist, wie DTMF ausgehandelt wird. Das Auflisten von Codecs in Präferenzreihenfolge lässt den Antwortenden den besten beidseitig unterstützten wählen.

*Gängige Audio-RTP-Payload-Typen*

| PT | Codec | Takt | Hinweis |
|---|---|---|---|
| 0 | PCMU (G.711 µ-law) | 8000 | Statisch; ~64 kbit/s, Telefonqualität (Toll Quality) |
| 8 | PCMA (G.711 A-law) | 8000 | Statisch; ~64 kbit/s, Telefonqualität (Toll Quality) |
| 9 | G722 | 8000 | Breitband (16 kHz Audio) |
| 18 | G729 | 8000 | Statisch; ~8 kbit/s komprimiert |
| 96–127 | Dynamisch (Opus, telephone-event…) | variiert | Definiert durch a=rtpmap |

## Medienrichtungs-Attribute

Ein a=-Richtungsattribut legt fest, wie Medien für einen Strom fließen. sendrecv ist der normale bidirektionale Standard. sendonly und recvonly beschränken den Fluss auf eine Richtung — genutzt für Halten, Ansagen und Einwegmedien. inactive stoppt Medien vollständig, während die Sitzung bestehen bleibt. Das Umschalten dieser Werte (zum Beispiel sendonly ⇄ sendrecv in einem re-INVITE) ist, wie Anruf-Halten, -Fortsetzen und Music-on-Hold umgesetzt werden, ohne den Dialog abzubrechen.

*SDP-Richtungsattribute*

| Attribut | Bedeutung |
|---|---|
| a=sendrecv | Medien senden und empfangen (Standard) |
| a=sendonly | Nur senden (z. B. Ansage oder die gehaltene Partei) |
| a=recvonly | Nur empfangen (z. B. die gehaltene Partei) |
| a=inactive | Keine Medien in beiden Richtungen; die Sitzung bleibt bestehen |

## Häufige Fragen

### Wofür wird SDP in SIP verwendet?

SDP beschreibt die Mediensitzung — die IP-Adresse, Ports, Medientypen und Codecs, die jeder Endpunkt anbietet. SIP trägt zwei SDP-Bodys in einem Offer/Answer-Austausch, um auszuhandeln, welches Audio oder Video die Endpunkte über RTP austauschen. SDP selbst trägt keine Medien.

### Was ist das SIP-Offer/Answer-Modell?

Definiert in RFC 3264, ist es, wie SIP Medien aushandelt: Eine Seite sendet ein SDP-Offer (oft im INVITE), das ihre Medien und Codecs auflistet, und die andere gibt eine SDP-Answer zurück (oft im 200 OK), die die von ihr ebenfalls unterstützte Teilmenge auswählt. Die vereinbarte Schnittmenge ist, was fließt.

### Was bedeutet die m=-Zeile in SDP?

Die m=-Zeile (Media) deklariert einen Medienstrom: seinen Typ (Audio/Video), den Zielport, den Transport (z. B. RTP/AVP oder RTP/SAVP für SRTP) und die Liste der angebotenen RTP-Payload-Type-Nummern. Jeder Payload-Typ wird dann durch eine a=rtpmap-Zeile beschrieben.

### Wie werden Codecs in einem SIP-Anruf gewählt?

Der Anbietende listet akzeptable Codecs in Präferenzreihenfolge im SDP auf. Der Antwortende behält nur die von ihm ebenfalls unterstützten und gibt sie zurück und wählt so effektiv den besten beidseitig unterstützten Codec. Überschneiden sich die Mengen nicht, scheitert die Aushandlung, typischerweise mit einem 488 Not Acceptable Here.

### Wie wird Anruf-Halten mit SDP umgesetzt?

Durch Ändern des Medienrichtungs-Attributs in einem re-INVITE — zum Beispiel a=sendonly setzen (oder historisch eine Null-Connection-Adresse), um die Gegenseite auf Halten zu legen, und a=sendrecv zum Fortsetzen. Der Dialog bleibt bestehen; nur die Medienrichtung ändert sich.

## Quellen

- [IETF RFC 4566 — SDP: Session Description Protocol](https://datatracker.ietf.org/doc/html/rfc4566)
- [IETF RFC 3264 — An Offer/Answer Model with SDP](https://datatracker.ietf.org/doc/html/rfc3264)

## Verwandte Seiten

- [RTP- und SRTP-Medien](https://www.broadnet.me/de/reference/rtp-and-srtp-media)
- [SIP-Anrufverlauf](https://www.broadnet.me/de/reference/sip-call-flow)
- [SIP-Methoden und -Anfragen](https://www.broadnet.me/de/reference/sip-methods-and-requests)
- [SIP-Header](https://www.broadnet.me/de/reference/sip-headers)
- [Programmierbare Sprachdienste (Produkt)](https://www.broadnet.me/de/products/voice)