SDP und SAP (Sitzungsbeschreibung und Ankündigung)

Woher weiß ein Empfänger im Netzwerk-Audio, was in einem Datenstrom steckt — und wie erfährt er überhaupt, dass es ihn gibt?

SDP ist ein Textformat, das eine Medien-Sitzung beschreibt: an welche Adresse und welchen Port ein Strom geht, wie viele Kanäle er hat, welches Format darin steckt und welche Zahl im Paket dieses Format meint. SAP ist einer der Wege, auf denen diese Beschreibung zum Empfänger kommt — der Sender wiederholt sie als Multicast-Paket im Netz, und wer mithört, baut daraus seine Liste verfügbarer Ströme.

Die Trennung ist der ganze Punkt. Die Beschreibung sagt, was ein Strom ist; die Ankündigung sagt, dass es ihn gibt. Beides steht nirgends im Strom selbst, denn ein RTP-Paket enthält für das Format nur eine Zahl, und bei allem Interessanten ist diese Zahl frei vergeben. Wer sie nicht vorher erklärt bekommen hat, empfängt Pakete und weiß nichts damit anzufangen.

Ein Sender schickt Musik als viele kleine Päckchen durchs Netz. In jedem Päckchen steht eine Nummer, die das Format bezeichnet — aber nicht, was diese Nummer bedeutet. Das steht in einer Art Beipackzettel, und den ruft der Sender in regelmäßigen Abständen ins Netz: hier bin ich, so heiße ich, so musst Du mich lesen. Ein Empfänger hört mit, sammelt diese Zettel und zeigt Dir daraus eine Liste zur Auswahl. Wählst Du etwas aus, weiß er, wohin er horchen muss und wie er das Gehörte zu verstehen hat.

Was in einer Sitzungsbeschreibung steht

SDP ist Text, eine Angabe je Zeile, in der Form <Typ>=<Wert>. Der Typ ist genau ein Buchstabe, und die Reihenfolge der Zeilen ist vorgeschrieben. Das Format geht auf Mark Handley am University College London zurück, der es zusammen mit Van Jacobson und Colin Perkins (University of Glasgow) verfasst hat; die heute meist zitierte Fassung stammt von 2006, die aktuelle von 2021.

Die strenge Form ist kein Selbstzweck: Eine Beschreibung soll unterwegs beschädigt werden können, ohne halb verstanden zu werden. Was von der Reihenfolge abweicht, ist erkennbar kaputt und wird verworfen, statt falsch ausgewertet zu werden.

Eine Beschreibung besteht aus einem Sitzungsteil und beliebig vielen Medienteilen. Der Sitzungsteil beginnt mit der Zeile v= und gilt für alles, was folgt; jeder Medienteil beginnt mit einer Zeile m= und darf die Vorgaben von oben überschreiben. Pflicht sind vier Zeilen: die Version, der Urheber mit Sitzungskennung, ein Name und eine Zeitangabe. Die Verbindungsangabe c= mit der Zieladresse muss entweder einmal oben stehen oder in jedem Medienteil einzeln.

Für eine Audioanlage sind drei Zeilen die interessanten:

Zeile	Was sie sagt	Folge für die Planung
`c=`	Netz- und Adresstyp und die Zieladresse; bei einer Multicast-Sitzung ist das die Gruppenadresse	Die Adresse, auf die sich der Empfänger anmeldet. Steht hier eine Gruppe, die das Netz nicht weiterreicht, hilft eine fehlerfreie Beschreibung nichts
`m=`	Medienart, Zielport, Transportprofil und die Liste zulässiger Formatnummern	Port und Profil müssen zum Empfänger passen. Mehrere Nummern in der Liste heißen: Der Sender kann mehreres, ausgehandelt wird anderswo
`a=rtpmap:`	zu einer Formatnummer der Formatname, die Taktrate und die Kanalzahl	Erst hier bekommt die Zahl im Paket ihre Bedeutung. Ohne diese Zeile ist ein frei vergebenes Format nicht auswertbar

Die Zeile, an der die Formatnummer Bedeutung bekommt

Ein Beispiel aus dem Standard: m=audio 49232 RTP/AVP 98 sagt, dass auf Port 49232 ein Audiostrom nach dem Grundprofil läuft und die Formatnummer 98 verwendet. Was 98 bedeutet, sagt erst die Folgezeile a=rtpmap:98 L16/16000/2 — lineares Audio mit 16 Bit, 16 kHz, zwei Kanäle. Dieselbe Nummer kann in der Anlage nebenan etwas völlig anderes meinen; frei vergeben heißt frei vergeben.

Bei fest vergebenen Nummern entfällt die Zeile. m=audio 49232 RTP/AVP 0 kommt ohne rtpmap aus, weil die 0 im Profil verbindlich für G.711 µ-Law mit 8 kHz steht. Das ist Telefonie. Alles, was in einer Musikanlage interessiert — lineares Audio mit 24 Bit und 48 kHz oder mehr —, hat keine feste Nummer und braucht die Zeile immer. Im Netzwerk-Audio ist rtpmap deshalb die Hauptleistung des ganzen Formats und keine Randnotiz darin.

Eine zweite Angabe lohnt den Blick: a=ptime: nennt, wie viele Millisekunden Ton in einem Paket stecken. Der Wert ist die Stellschraube zwischen Verzögerung und Paketrate, und die RTP-Seite rechnet vor, was er in beide Richtungen kostet.

Wie die Beschreibung zum Empfänger kommt

SDP beschreibt nur und überträgt nichts. Der Standard sagt das ausdrücklich und zählt die vorgesehenen Wege auf: die Ankündigung per SAP, den Sitzungsaufbau per SIP, die Wiedergabesteuerung per RTSP, dazu E-Mail und HTTP. In der Praxis kommt ein vierter Weg dazu, den kein RFC beschreibt — die Konfiguration von Hand oder über die Verwaltungssoftware des Herstellers.

SAP ist der Weg für den Fall, dass niemand fragt. Ein Sender ruft seine Beschreibung in regelmäßigen Abständen als Multicast-Paket ins Netz, Port 9875, auf einer eigenen Gruppenadresse — für den globalen Bereich 224.2.127.254, für einen verwaltungsbezogenen Bereich die höchste Adresse dieses Bereichs. Empfänger melden sich auf dieser Gruppe an und sammeln, was hereinkommt. Niemand fragt an, niemand antwortet; es gibt keine Verbindung und keinen Server.

Das Verfahren stammt von 2000, ebenfalls von Handley und Perkins, zusammen mit Edmund Whelan. Es ist bis heute als Experimental gekennzeichnet und damit kein verabschiedeter Internet-Standard — die SDP-Fassung von 2021 stellt sogar fest, dass SAP nicht mehr verbreitet im Einsatz sei, und hat die Verweise darauf gestrichen. Für das offene Internet stimmt das. Im professionellen Netzwerk-Audio ist es weiter das gebräuchliche Verfahren, und wer eine Anlage plant, hat es vor sich, gleichgültig was die IETF darüber denkt.

Zwei Eigenschaften, die aus der Wiederholung folgen

Den Abstand zwischen zwei Ankündigungen rechnet der Sender selbst aus. Alle Ankündigungen auf einer Gruppe zusammen sollen eine Bandbreitengrenze einhalten, ohne andere Angabe 4.000 Bit je Sekunde. Aus Grenze, Zahl der Sitzungen und Größe der Beschreibung folgt der Abstand — und er ist nach unten bei 300 Sekunden gedeckelt. Ein neuer Strom kann also fünf Minuten brauchen, bis er in der Liste eines Empfängers steht, der gerade erst zugehört hat. Wer in dieser Zeit auf eine leere Liste sieht, hat keinen Fehler vor sich, sondern das Verfahren.

Umgekehrt gilt: Ein Empfänger wirft eine Sitzung erst aus seiner Liste, wenn zehn Wiederholungsabstände lang nichts mehr kam — mindestens aber eine Stunde. Ein abgeschaltetes Gerät steht deshalb noch lange in der Auswahl, und eine Liste mit Karteileichen ist der Normalzustand, nicht der Defekt. Sauber verschwindet eine Sitzung nur auf zwei Wegen: Der Sender schickt ein ausdrückliches Löschpaket, oder die Beschreibung enthält eine Endzeit, die vorbeigeht.

Ändert der Sender etwas an der Beschreibung, muss er den Prüfwert im Kopf der Ankündigung wechseln. Daran erkennt ein Empfänger, dass er es mit einer neuen Fassung zu tun hat, ohne den Inhalt vergleichen zu müssen.

Häufiges Missverständnis

„SAP findet die Geräte im Netz." Es findet keine Geräte, es kündigt Ströme an. Ob ein Verstärker im Haus erreichbar ist, welche Weboberfläche er hat und wie er heißt, beantwortet die Dienstsuche über Multicast DNS oder SSDP — beschrieben bei UPnP und DLNA. SAP sagt nur: An dieser Adresse läuft dieser Strom in diesem Format. Beide Verfahren nutzen Multicast als Transport und werden deshalb verwechselt, lösen aber verschiedene Aufgaben. In einer Anlage laufen häufig beide nebeneinander, und ein Netz kann das eine durchlassen und das andere nicht.

„Der Strom kommt an, also stimmt die Verbindung." Ein Empfänger, der Pakete zählt und trotzdem stumm bleibt, hat sein Problem meist genau hier: Er kennt die Bedeutung der Formatnummer nicht, weil die Beschreibung ihn nie erreicht hat oder eine andere Belegung nennt als der Sender verwendet. Die Leitung ist dann in Ordnung, und jede Messung an ihr bestätigt das.

„Die Ankündigung läuft schon mit, wenn der Ton läuft." Ankündigung und Audio sind zwei verschiedene Multicast-Gruppen. Ein Netz kann die eine weiterreichen und die andere verwerfen — beim Übergang zwischen zwei Segmenten, bei eingeschalteter Multicast-Filterung ohne zuständigen Abfrager, bei Filterregeln, die nur die Audiogruppen kennen. Der sichtbare Befund ist dann ein Empfänger mit leerer Liste, der einen von Hand eingetragenen Strom einwandfrei spielt.

Nicht zu verwechseln mit

Multicast DNS und SSDP: Dienstsuche. Sie beantworten, welche Geräte und Dienste im Netz erreichbar sind, nicht, welche Ströme laufen.
SIP: der Sitzungsaufbau zwischen zwei Teilnehmern — die Grundlage von Türsprechstellen über IP. SIP ersetzt SDP nicht, es transportiert es: Anrufer und Angerufener tauschen ihre Beschreibungen aus und einigen sich auf ein Format.
RTSP: die Fernbedienung eines Medienservers, verbreitet bei IP-Kameras. Auch RTSP überträgt eine Sitzungsbeschreibung, holt sie aber auf Anfrage, statt sie zu rufen.
RTP: der Strom selbst. SDP beschreibt ihn, SAP kündigt ihn an, RTP ist er.
SAP als Firmenname: dieselben drei Buchstaben, keine Verbindung zur Sache. Im Netzwerkkontext ist SAP das Ankündigungsprotokoll.

In der Planung

Eine Anlage mit sechs Zonen ist verkabelt und eingerichtet, der Netzwerktechniker hat den AV-Verkehr in ein eigenes Segment gelegt. Zwei Zonen spielen, vier zeigen eine leere Auswahlliste. Die Leitungen sind geprüft, die Geräte antworten auf ihren Verwaltungsadressen.

Zu klären ist zuerst etwas, das mit Geräten noch nichts zu tun hat: Sollen Ströme im Netz auffindbar sein, oder wird jeder Empfänger fest auf seine Quelle gesetzt? Beides ist vertretbar. Auffindbar heißt bedienbar und erweiterbar — jemand kann eine Quelle hinzufügen, ohne dass ein Techniker kommt. Fest gesetzt heißt kontrollierbar und störungsärmer, kostet aber bei jeder Änderung einen Eingriff.

Die Antwort bestimmt das Verfahren. Sollen Ströme auffindbar sein, muss die Ankündigungsgruppe denselben Weg nehmen wie die Audiogruppen — im selben Segment ist das umsonst zu haben, über Segmentgrenzen hinweg braucht es eine eingerichtete und abgenommene Multicast-Weiterleitung. Was das vom Netz verlangt, steht bei Multicast und IGMP und VLAN und Subnetz.

Ganz am Ende dieser Kette wählst Du die Geräte aus, und drei Fragen entscheiden darüber: Zeigt das Gerät die empfangenen Sitzungsbeschreibungen im Klartext an, oder nur eine Liste von Namen? Lässt sich ein Strom auch von Hand eintragen, wenn die Ankündigung nicht ankommt? Und schickt es beim Abschalten ein Löschpaket, oder bleibt es eine Stunde lang als Karteileiche in fremden Listen? Die erste Frage entscheidet, wie lange die Fehlersuche im geschilderten Fall dauert.

Verknüpfte Inhalte

Was in einem Paket steht und warum die Formatnummer allein nicht reicht, klärt RTP. Wie eine Gruppe im Netz überhaupt weitergereicht wird, steht bei Multicast und IGMP, die Trennung des AV-Verkehrs bei VLAN und Subnetz und der Vorrang im ausgelasteten Netz bei QoS, DSCP und 802.1p. Die Dienstsuche als die andere Multicast-Anwendung im Haus behandelt UPnP und DLNA, den gemeinsamen Takt Word Clock und PTP. Wie eine Anlage insgesamt aufgebaut ist, steht auf Audio over IP; die beiden verbreiteten Ausprägungen sind AES67 und Dante.

Quellen

Der Zeilenaufbau, die verbindliche Reihenfolge, die Gliederung in Sitzungs- und Medienteile, die Pflichtzeilen sowie die Bedeutung von c=, m=, a=rtpmap und a=ptime samt der beiden Beispiele stehen in RFC 8866 von 2021, das RFC 4566 von 2006 abgelöst hat; beide wurden für diese Seite im Volltext gelesen. Aus RFC 8866 stammt auch die Feststellung, dass SDP kein Transportprotokoll enthält und für SAP, SIP, RTSP, E-Mail und HTTP gedacht ist, ebenso die Angabe im Änderungsverzeichnis, dass SAP nicht mehr verbreitet im Einsatz ist. Die Begründung für die strenge Form — erkennbar fehlerhafte statt halb verstandener Beschreibungen — steht in RFC 4566.

Port 9875, die Gruppenadressen, die Bandbreitengrenze von 4.000 Bit je Sekunde, die Untergrenze von 300 Sekunden für den Wiederholungsabstand, die drei Wege der Löschung mit der Frist aus zehn Abständen oder einer Stunde sowie der Prüfwert der Nachrichtenkennung stehen in RFC 2974 von 2000, ebenfalls im Volltext gelesen. Dass dieses Dokument die Kategorie Experimental hat, steht in seinem Kopf.