Kommentar: SIP-Kommunikation
Eine Kommunikationsbeziehung braucht mehr als nur SIP
Will man ein Gespräch zwischen zwei oder mehreren Teilnehmern übermitteln, dann müssen die Mechanismen der Signalisierung, der Medien und der Kontrolle zusammenarbeiten. Das Problem besteht jedoch darin, dass die jeweiligen Protokolle unabhängig voneinander arbeiten.
Wer sich mit VoIP, Video über IP oder WebRTC beschäftigt, der lernt sehr schnell die Unterschiede zwischen SIP-Befehlen, den Funktionen von SIP-Trunks und den unterschiedlichen Realisierungsmöglichkeiten von bestimmten Leistungsmerkmalen. Wer die technischen Aspekte des SIP-Protokolls versteht, wird VoIP, Video und WebRTC erfolgreich umsetzen können. Die Grundlage für die Echtzeitübertragung basieren auf einer Reihe unterschiedlicher Protokolle, die beim Auf- und Abbau von Kommunikationsbeziehungen und der Übermittlung der eigentlichen Echtzeitdaten eine wichtige Rolle spielen.
Protokolle innerhalb von Protokollen
Das Session-Initiation-Protocol (SIP) ist ein Netzprotokoll zum Aufbau, zur Steuerung und zum Abbau einer Kommunikationssession zwischen zwei und mehr Teilnehmern.
SIP baut Sessions auf, beendet oder manipuliert diese. Mit einer INVITE-Anfrage wird eine neue Session aufgebaut und diese mit BYE beendet. Der REFER-Befehl verschiebt (beispielsweise beim verbinden) eine aktive Sitzung von einem Endpunkt zum anderen. UPDATE ändert die Merkmale aktiver Sitzungen.
SIP arbeitet auf der Signalisierungsebene und steht zu jedem Moment im Lebenszyklus einer Sitzung zur Verfügung. SIP ist kein Medien-Protokoll und stellt außer ein paar Headern für die Bereitstellung von Media-Strömen nichts für die eigentliche Übermittlung der Echtzeitinformationen zur Verfügung. SIP hat auch nichts mit der Auswahl von SIP-Codecs, der Paketraten, der IP-Adressen, der Kommunikations-Ports oder irgendwelchen anderen Merkmalen des Medienstroms zu tun. SIP baut Kommunikationssitzungen auf, hat jedoch nicht die geringste Ahnung, welche Art von Information (Gespräch) damit übermittelt wird.
Session-Description-Protocol
Um Medien einer Sitzung hinzufügen nutzt das SIP ein anderes Protokoll. Mit dem Session-Description-Protocol (SDP) werden die Eigenschaften von Multimediadatenströmen beschrieben. Es dient dazu, Kommunikationssitzungen zu verwalten, und wird beispielsweise zusammen mit SIP bei der Aushandlung von Codecs, Transportprotokollen und -adressen und zur Übertragung von Metadaten eingesetzt. SDP selbst bietet keinen eigenen Aushandlungsmechanismus, sondern nur eine Beschreibung der Datenströme. Beispielsweise schlägt der SDP-Mechanismus für eine SIP-Telefonverbindung die Unterstützung der Codecs G.711, G.729, G.722, der IP-Adresse 10.100.10.23 und den Port 5000 vor. Die Datensätze im SDP-Format können mit verschiedenen Transportprotokollen übertragen werden, beispielsweise auch mit dem Session-Announcement-Protocol (SAP).
Das Session-Description-Protocol ist ein ziemlich kryptisches Protokoll mit einer Reihe von Parametern, die für VoIP-Neulinge oft verwirrend wirken. Zum Glück gibt es wirklich nur ein paar Dinge, die einen zu einem SDP-Experten machen:
- c = Die Konversationszeile identifiziert die IP-Adresse des Endpunkts der Medienquelle.
- m = Eine Reihe von Medienbeschreibungen und dem zugehörigen Attribut (a =) beschreiben die Codecs und die Codec-Parameter die ein Endpunkt unterstützt.
Beispielsweise übermittelt mit der folgenden SDP-Sequenz ein Endpunkt einem anderen Endpunkt, dass dieser den G.711– (gekennzeichnet durch PCMU (Pulse-Code-Modulation U-Law) und PCMA (Pulse-Code-Modulation A-Law)) und den iLBC-Codec (Internet-Low-Bandwidth-Codec) auf der IP-Adresse 10.100.10.23 über Port 49170 nutzen will:
c = IN IP4 10.100.10.23
m = audio 49170 RTP / AVP 0 8 97
a = rtpmap: 0 PCMU / 8000
a = rtpmap: 8 PCMA / 8000
a = rtpmap: 97 iLBC / 8000
Die Zeile c = definiert die zu nutzende IP-Adresse.
Die Zeile m = informiert darüber, dass das RTP Protokoll zum Transport der Medienströme zu und von Port 49170 verwendet wird.
Dieser Endpunkt unterstützt drei Codecs (0, 8 und 97). Für jeden dieser Codecs steht eine eigene Attributzeile (zur weiteren Definition der Codecs) bereit. In unserem Beispiel werden alle Codecs mit 8000 Hz codiert.
Die SDP-Informationen werden innerhalb einer SIP-Mitteilung übermittelt. Trotzdem agieren die beiden Protokolle völlig unabhängig voneinander. Für beide Protokolle existieren auch separate Spezifikationen: RFC 3261 für SIP und RFC 4566 für SDP. Die SDP-Mechanismen werden auch bei WebRTC intensiv genutzt. Trotzdem gibt es viele Menschen, die behaupten, dass SIP und WebRTC über wenige Gemeinsamkeiten verfügen.
Das SDP ist ein Beschreibungsprotokoll und es handelt keine Medienströme aus. Die Aushandlung der zu nutzenden Medienströme und deren Merkmale obliegt den eigentlichen VoIP-, Video-, beziehungsweise WebRTC-Anwendungen. Diese übermitteln die Media-Informationen per SDP.
Das SDP-Protokoll beschreibt die Medien und das Real-Time-Protocol (RTP) transportiert die von den ausgewählten Codec bereitgestellten Medienströme. Das Real-Time-Transport-Protocol (RTP) ist ein Protokoll zur kontinuierlichen Übertragung von audiovisuellen Daten über IP-basierte Netzwerke. Es dient dazu, Multimedia-Datenströme (Audio, Video, Text, etc.) bidirektional über Netzwerke zu transportieren, sprich die Daten zu kodieren, zu paketieren und zu versenden. Dabei sendet jeder Endpunkt per RTP seinen eigenen Medien-Stream. Mit einem Analysator (beispielsweise Wireshark) kann ein Anrufverlauf aufgezeichnet werden und die beiden Seiten der Kommunikation beziehungsweise die beiden Medienströme lassen sich separat darstellen.
RTP ist ein Paket-basierter Übertragungsmechanismus und die erzeugten Pakete werden normalerweise über das User-Datagram- Protocol (UDP) übermittelt. RTP kann sowohl für Unicast-Verbindungen als auch für Multicast-Kommunikation eingesetzt werden. Das UDP-Protokoll sorgt für keine Sendewiederholungen beim Verlust von Paketen und lebt mit der Hoffnung, dass jedes Paket in Ordnung und unbeschädigt zum Empfänger gelangt. Tritt ein Fehler auf, muss der Empfänger eigenständig mit diesem Fehler umgehen. Die Echtzeit-Charakteristik der Sprach- und der Videokommunikation erfordert deshalb von den Endpunkten bei empfangenen Fehlern, dass diese mit den Fehlern so gut wie möglich umgehen. In neueren Codecs (beispielsweise Opus) wurden eine Reihe Fehlerbehebungstechniken implementiert, um die Auswirkungen von Paketverlusten zu minimieren. Das RTP-Protokoll wurde im RFC 3550 definiert.
Das Real-Time-Control-Protocol (RTCP) ist die Schwester des RTP-Protokolls und wird zur Qualitätsbewertung der Media-Ströme genutzt. Das Real-Time (RTCP) tauscht auf Basis von Steuerungsdaten die Quality-of-Service-Parametern (QoS) periodisch zwischen Sender und Empfänger aus. Hierbei erfolgt eine
- Rückmeldung der bisher erbrachten Dienstqualität, wodurch eine Anpassung der Übertragungsrate erfolgen kann;
- Identifikation aller Sitzungsteilnehmer, wodurch semantisch zusammenhängende aber getrennt gesendete Medienströme synchronisiert werden können;
- Steuerung der für RTCP-Pakete verwendeten Bandbreite, damit der Austausch von RTCP-Nachrichten nicht die Übertragung behindert, was bei vielen Sitzungsteilnehmern passieren könnte.
Das Real-Time-Control-Protocol wird zusammen mit dem Real-Time- Streaming-Protocol (RTSP), das für die Steuerung der Übertragung zuständig ist, und dem Real-Time-Transport-Protocol (RTP) verwendet, das die eigentliche Übertragung übernimmt.
Das RTP-Protokoll verwendet immer eine gerade Port-Nummer, während RTCP immer die nachfolgende ungerade Port-Nummer verwendet. Im obigen Beispiel wurde die Port-Nummer 49170 für die Kommunikation mit dem RTP-Protokoll verwendet. Dies bedeutet, dass das zugehörige RTCP die Port-Nummer 49171 verwendet.
Fazit
In jeder SIP-Telefon- oder jeder Videoverbindung findet man drei Informationsströme: die Signalisierung, die Mediendaten und die Kontrollinformationen. Diese arbeiten eng zusammen, um einen oder mehrere Kommunikationsströme zwischen Gesprächspartnern zu übermitteln. Wobei jedes der genutzten Protokolle (SIP, SDP, RTP und RTCP) als eigenständiger Mechanismus agiert.
Lesen Sie mehr zum Thema
