SDP — Was es ist, Sitzungsbeschreibungsformat und Rolle in WebRTC

Was ist SDP (Session Description Protocol)?

SDP ist ein Anwendungsschichtprotokoll, das entwickelt wurde, um Multimedia-Sitzungsparameter im Textformat zu beschreiben. Es wurde innerhalb der MMUSIC (Multiparty Multimedia Session Control)-Arbeitsgruppe der IETF entwickelt und erstmals 1998 in RFC 2327 standardisiert. Im Jahr 2021 wurde die aktuelle Spezifikation RFC 8866 veröffentlicht, die die vorherige Version RFC 4566 ersetzte.

Die Hauptaufgabe von SDP besteht darin, den Sitzungsteilnehmern alle notwendigen Informationen zum Aufbau einer Verbindung bereitzustellen: welche Medienströme übertragen werden, welche Codecs unterstützt werden und über welche Netzwerkadressen und Ports die Übertragung erfolgt. SDP überträgt nicht die Mediendaten selbst, sondern beschreibt nur, wie die Verbindung organisiert werden soll.

Laut IETF RFC 8866 besteht das SDP-Format aus einer Reihe von Zeilen, die jeweils mit einem einbuchstabigen Typ beginnen, gefolgt von einem Gleichheitszeichen und einem Wert. Zum Beispiel bedeutet die Zeile m=audio 5004 RTP/AVP 0, dass die Sitzung einen Audiostrom auf Port 5004 mit dem Transportprotokoll RTP/AVP und dem Codec PCMU (Typ 0) enthält.

Geschichte und Standardisierung von SDP

Die erste Version von SDP wurde im April 1998 in RFC 2327 als Ergebnis der Arbeit der MMUSIC-Gruppe veröffentlicht. Das Protokoll wurde ursprünglich zur Ankündigung von Multicast-Sitzungen innerhalb von Mbone (Multicast Backbone) entwickelt. Mit der Entwicklung von VoIP und Videokonferenzen erweiterte sich der Anwendungsbereich von SDP, und 2006 wurde die aktualisierte Spezifikation RFC 4566 veröffentlicht.

Ein echter Durchbruch in der Nutzung von SDP erfolgte mit dem Aufkommen von WebRTC im Jahr 2011. Google integrierte SDP als primären Mechanismus zur Beschreibung von Mediensitzungen in seinem Framework für browserbasierte Echtzeitkommunikation. Seitdem ist SDP zu einem obligatorischen Bestandteil jeder WebRTC-Implementierung geworden — von Browsern bis zu mobilen Anwendungen auf iOS und Android.

Im Jahr 2021 veröffentlichte die IETF-Arbeitsgruppe RFC 8866 — die aktuelle SDP-Spezifikation, die RFC 4566 ersetzte. Die aktualisierte Version präzisierte die ICE (Interactive Connectivity Establishment)-Verarbeitung, die Unterstützung von DTLS (Datagram Transport Layer Security) und erweiterte die Möglichkeiten zur Beschreibung von Gruppensitzungen.

Unterschied zwischen SDP und Transportprotokollen

SDP unterscheidet sich grundlegend von Transportprotokollen dadurch, dass es nicht an der Datenübertragung teilnimmt. Es erfüllt eine rein beschreibende Funktion — ähnlich wie Metadaten einer Multimediadatei. Während RTP (Real-time Transport Protocol) Audio- und Videopakete überträgt und RTCP die Übertragungsqualität kontrolliert, gibt SDP nur an, welche Codecs und Ports zu verwenden sind.

Eine Analogie aus der Webentwicklung: SDP ist wie HTML-Markup, das die Seitenstruktur beschreibt, während RTP die eigentlichen Bilder und Texte sind. Ohne SDP wissen die Sitzungsteilnehmer nicht, wie sie sich miteinander verbinden sollen, selbst wenn die Netzwerkverbindung bereits hergestellt ist. Der NAT-Traversal-Mechanismus (ICE) verlässt sich ebenfalls auf SDP, um Informationen über Netzwerkkandidaten zu übertragen.

Wie ist SDP aufgebaut

Die SDP-Struktur ist als eine Folge von Textzeilen organisiert, die jeweils dem Format type=value folgen. Der einbuchstabige Typ definiert den Zweck der Zeile, und der Wert enthält den entsprechenden Wert. Alle Zeilen sind durch ein CRLF-Zeichen getrennt.

Der Standard RFC 8866 definiert mehrere obligatorische und optionale Felder. Zu den obligatorischen Feldern gehören die Protokollversion (v=), der Sitzungsname (s=) und die Start- und Endzeit der Sitzung (t=). Die übrigen Felder sind optional, aber für WebRTC-Sitzungen sind auch Medienbeschreibungen (m=), Attribute (a=) und Netzwerkinformationen (c=) erforderlich.

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

Das obige Beispiel zeigt ein typisches SDP-Segment für eine WebRTC-Sitzung. Die Zeile v=0 gibt die Protokollversion an. Das Feld o= enthält die Kennung des Sitzungseigentümers und dessen Version. Die Zeile s=- gibt den Sitzungsnamen an (ein Bindestrich bedeutet einen leeren Namen). Das Feld t=0 0 zeigt an, dass die Sitzung nicht zeitlich begrenzt ist.

Das Feld a=group:BUNDLE audio video ist ein Attribut, das mehrere Medienströme in einem Transportkanal gruppiert. Der BUNDLE-Mechanismus ermöglicht es, Netzwerkressourcen zu sparen, indem Audio und Video über eine einzige Verbindung übertragen werden. Dies ist besonders wichtig für mobile Geräte mit begrenzter Bandbreite.

Obligatorische SDP-Felder

Die Spezifikation RFC 8866 definiert eine Reihe von obligatorischen und optionalen Feldern. Zu den obligatorischen Feldern gehören v= (Version), s= (Sitzungsname) und t= (Zeit). Das Feld o= (Eigentümer), obwohl laut RFC nicht streng obligatorisch, ist in realen Implementierungen fast immer vorhanden.

Das Feld m= (media) ist eines der wichtigsten. Es beschreibt einen bestimmten Medienstrom und enthält den Medientyp (audio, video, text, application), Port, Transportprotokoll und die Liste der unterstützten Codecs. In WebRTC sind die am häufigsten verwendeten Typen audio und video mit den Transportprotokollen RTP/SAVPF (Secure Audio/Video Profile with Feedback) oder UDP/TLS/RTP/SAVPF.

Das Feld a= (attribute) ist das flexibelste und erweiterbarste. Es kann rtpmap (Zuordnung der Codec-Nummer zum Namen), fmtp (Codec-Parameter), fingerprint (DTLS-Schlüsselfingerabdruck), ice-ufrag und ice-pwd (ICE-Anmeldeinformationen) und viele andere Attribute enthalten. Über Attribute unterstützt SDP moderne Sicherheitsmechanismen und NAT-Traversal.

Wie SDP in WebRTC funktioniert

In der WebRTC-Architektur dient SDP als Signalisierungsprotokoll zur Beschreibung und Aushandlung von Mediensitzungsparametern zwischen zwei Teilnehmern. SDP selbst definiert nicht den Mechanismus zur Übertragung dieser Beschreibungen — diese Aufgabe wird vom Signalisierungskanal übernommen, den der Entwickler eigenständig über WebSocket, HTTP oder ein anderes Protokoll implementiert.

Der Prozess beginnt, wenn der Initiator (Anrufer) ein SDP-Angebot (Offer) erstellt. Dazu ruft der Browser die Methode createOffer() auf dem RTCPeerConnection-Objekt auf. Die generierte SDP-Beschreibung enthält alle Sitzungsparameter des Initiators: unterstützte Codecs, Netzwerkadressen, ICE-Kandidaten und Sicherheitsanforderungen.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Medienspuren vor createOffer hinzufügen
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// SDP Offer erstellen
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// SDP über Signalisierungskanal an entfernten Peer senden
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Nach der Erstellung des Offer und dem Setzen der lokalen Beschreibung über setLocalDescription() sendet der Initiator die SDP-Zeichenfolge über den Signalisierungskanal an den entfernten Teilnehmer. Der entfernte Teilnehmer, der das SDP Offer erhalten hat, erstellt eine SDP-Antwort (Answer) und sendet sie zurück. Dieser Austausch wird als Signalisierungsaustausch bezeichnet und ist ein obligatorischer Schritt vor dem Aufbau einer Peer-to-Peer-Verbindung.

Laut W3C WebRTC-Spezifikation sollte der SDP-Austausch vor dem Beginn der ICE-Kandidaten erfolgen. In der Praxis senden viele Implementierungen ICE-Kandidaten parallel zum SDP unter Verwendung des ICE trickle-Mechanismus. Dies verkürzt die Verbindungsaufbauzeit, insbesondere für mobile Netzwerke mit hoher Latenz.

Die Rolle von ICE in SDP

ICE (Interactive Connectivity Establishment) ist ein Mechanismus, der SDP-Attribute verwendet, um Informationen über Netzwerkkandidaten zu übertragen. ICE-Kandidaten beschreiben mögliche Verbindungswege: host (lokale Adresse), srflx (Adresse nach NAT, über STUN erhalten) und relay (Adresse des TURN-Servers).

In SDP werden ICE-Kandidaten über a=candidate:-Attribute sowie über die Felder ice-ufrag und ice-pwd zur Authentifizierung des ICE-Datenverkehrs übertragen. Jeder Kandidat enthält das Transportprotokoll (UDP, TCP), die IP-Adresse, den Port und die Priorität. Eine erfolgreiche Verbindung wird über den ersten Kandidaten hergestellt, der die Konnektivitätsprüfungen besteht. Der ICE restart-Mechanismus ermöglicht es, die Verbindung bei Netzwerkwechsel zu aktualisieren.

Für mobile Anwendungen sind ICE-Kandidaten besonders wichtig, da sich Geräte häufig hinter NAT oder Unternehmensfirewalls befinden. Der ICE-Mechanismus ermöglicht es, auch unter komplexen Netzwerkbedingungen einen funktionierenden Weg zu finden, und SDP dient als Transportcontainer für diese Informationen.

SDP-Sicherheit in WebRTC

SDP in WebRTC enthält notwendigerweise Sicherheitsattribute, insbesondere den DTLS-Fingerabdruck und die SRTP-Parameter. Das Feld a=fingerprint:sha-256 enthält den Fingerabdruck des DTLS-Zertifikats, der zur Authentifizierung und Verschlüsselung des Medienstroms verwendet wird. Ohne dieses Attribut wird die WebRTC-Verbindung nicht hergestellt.

Zusätzliche Sicherheitsmechanismen umfassen das Attribut a=setup:, das die DTLS-Handshake-Rolle (active, passive, actpass) definiert, und a=ice-lite: für eine vereinfachte ICE-Implementierung auf der Serverseite. Alle diese Parameter werden innerhalb des SDP übertragen und von beiden Seiten vor Beginn der Medienübertragung überprüft.

SDP-Typen: Offer und Answer

Im WebRTC-Modell gibt es zwei Arten von SDP-Nachrichten: Offer (Angebot) und Answer (Antwort). Das Offer wird vom Verbindungsinitiator erstellt und enthält eine vollständige Beschreibung der gewünschten Mediensitzung. Die Answer wird vom entfernten Teilnehmer als Antwort auf das Offer erstellt und enthält seine Fähigkeiten unter Berücksichtigung der durch das Angebot auferlegten Einschränkungen.

Der Hauptunterschied zwischen Offer und Answer liegt in der Semantik der Attribute. Das Offer listet alle unterstützten Codecs, Transportprotokolle und Netzwerkadressen auf, die der Initiator vorschlagen kann. Die Answer wählt eine Teilmenge dieser Fähigkeiten aus, die die entfernte Seite unterstützt. Wenn das Offer beispielsweise opus, ISAC und PCMU vorschlägt, kann die Answer nur opus als den am meisten bevorzugten Codec auswählen.

Der Austauschprozess wird durch die W3C WebRTC-Spezifikation geregelt und umfasst mehrere Zustände der RTCPeerConnection. Nach der Erstellung des Offer über createOffer() und der Festlegung als lokale Beschreibung wechselt die Verbindung in den Zustand have-local-offer. Nach dem Empfang der Answer und deren Festlegung als entfernte Beschreibung über setRemoteDescription() wechselt die Verbindung in den Zustand stable — den endgültigen Zustand, der für die Medienübertragung bereit ist.

Verwendung von SDP in mobilen SDKs

Mobile SDKs für WebRTC — Google WebRTC für Android und WebRTC.framework für iOS — unterstützen den SDP-Austausch über Offer und Answer vollständig. Auf Android wird die Klasse PeerConnection mit der Methode createOffer() verwendet, um ein Offer zu erstellen, ähnlich der Browser-API. Die resultierende SDP-Beschreibung wird als Zeichenfolge über den Signalisierungskanal übertragen.

Auf iOS erfolgt die Arbeit mit SDP über die Klasse RTCSessionDescription aus dem WebRTC-Framework. Bei der Initialisierung werden der Typ (RTCSdpTypeOffer oder RTCSdpTypeAnswer) und die SDP-Zeichenfolge angegeben. Die Plattform analysiert automatisch das SDP und konfiguriert die Verbindung gemäß den übergebenen Parametern.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// SDP Offer auf Android erstellen
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // SDP-Zeichenfolge an entfernten Peer senden
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

Die Möglichkeit, direkt mit der SDP-Zeichenfolge zu arbeiten, gibt Entwicklern Flexibilität: Sie können das SDP vor dem Senden modifizieren, bestimmte Codecs hinzufügen oder entfernen, ICE-Parameter konfigurieren oder benutzerdefinierte Attribute hinzufügen. Für Android-Anwendungen ist es oft erforderlich, Video im SDP bei niedriger Netzwerkbandbreite zu deaktivieren — dies geschieht durch Entfernen der entsprechenden m=-Zeilen aus der SDP-Beschreibung.

SDP in der mobilen Entwicklung

In der mobilen Entwicklung wird SDP hauptsächlich im Kontext von WebRTC verwendet — zur Erstellung von Anwendungen mit Videoanrufen, Sprachchats und Streaming. Mobile Anwendungen auf Android und iOS können sowohl als Initiator als auch als Empfänger von SDP-Nachrichten fungieren, was symmetrische Peer-to-Peer-Verbindungen ermöglicht.

Eine Besonderheit mobiler Anwendungen ist die Notwendigkeit, mit SDP unter variablen Netzwerkqualitätsbedingungen zu arbeiten. Beim Wechsel zwischen Wi-Fi und mobilem Internet sowie bei Änderung der Bandbreite kann die Generierung einer neuen SDP-Beschreibung erforderlich sein. Dies erfolgt über den Renegotiation-Mechanismus — einen wiederholten SDP-Austausch über createOffer() und setLocalDescription().

Laut Google WebRTC-Team (2023) umfasst die Optimierung des SDP-Austauschs für mobile Geräte die Verwendung von ICE restart bei Netzwerkwechseln, die Priorisierung von Codecs mit niedriger Bitrate (opus für Audio, VP8 für Video) und die Minimierung der SDP-Zeichenfolgengröße durch Ausschluss unnötiger Medienströme. Der Hauptvorteil ist die reduzierte Latenz beim Aufbau einer Verbindung unter Mobilfunknetzbedingungen.

Optimierung von SDP für mobile Netzwerke

Eine der Hauptaufgaben bei der Arbeit mit SDP auf mobilen Geräten ist die Minimierung der SDP-Beschreibungsgröße. Ein vollständiges SDP für eine typische WebRTC-Sitzung mit Audio und Video kann 2–5 KB belegen, was für langsame Netzwerke erheblich ist. Die Optimierung umfasst die Verwendung von BUNDLE (Strommultiplexing), das Entfernen nicht unterstützter Codecs und die Komprimierung von ICE-Kandidaten.

Ein zusätzliches Problem für mobile Geräte ist die begrenzte Lebensdauer von SDP. Bei instabilen Verbindungsbedingungen kann das SDP veralten, bevor der entfernte Teilnehmer es verarbeiten kann. Die Lösung ist die Verwendung kurzer Timeouts für den Empfang der Answer und das erneute Senden von SDP bei Bedarf. Der ICE restart-Mechanismus ermöglicht es, die Verbindung zu aktualisieren, ohne die RTCPeerConnection vollständig neu zu erstellen. Das Attribut a=ice-lite vereinfacht die ICE-Implementierung auf der Serverseite.

Beliebte Bibliotheken für die Arbeit mit SDP

Entwicklern mobiler Anwendungen stehen fertige Bibliotheken zur Verfügung, die die Arbeit mit SDP vereinfachen. libjingle_peerconnection (Google WebRTC) ist die Hauptbibliothek für Android und bietet eine vollständige API zur Verwaltung von SDP. Für iOS wird WebRTC.framework mit ähnlicher Funktionalität verwendet. Beide Bibliotheken generieren und parsen SDP automatisch, bieten aber bei Bedarf Zugriff auf die rohe SDP-Zeichenfolge.

Für eine feinere Kontrolle über SDP gibt es Drittanbieterlösungen: sdp-transform (JavaScript oder Node.js) zum Parsen und Modifizieren von SDP, NICENICE (Java) für die Arbeit mit ICE-Kandidaten und fertige SDKs von WebRTC-Infrastrukturanbietern, die den gesamten Signalisierungsaustausch einschließlich SDP übernehmen.