Inhalt:

• Was ist RIPT und wie unterscheidet es sich von SIP?
• Eine URI für einen Call
• Transport mit QUIC
• Fazit

Die Telekommunikation basiert inzwischen fast durchgängig auf dem Internetprotokoll, ISDN wurde von vielen Netzanbietern abgeschaltet. Die Zusammenschaltung von IP-TK-Anlagen mit den Netzbetreibern über SIP-Trunks macht allerdings immer wieder Probleme. Obwohl es SIP-Trunks schon seit einigen Jahren gibt, ist die Zusammenschaltung einer TK-Anlage X mit einem Provider Y oft noch Pionierarbeit. Das Session Initiation Protocol (SIP) ist in diesem Bereich erst in der Einführung. Das Protokoll selbst ist dabei aber schon einige Jahre alt, die Arbeiten an SIP hatten bereits 1996 in der IETF begonnen. Die Autoren Mark Handley, Henning Schulzrinne, Eve Schooler und Jonathan Rosenberg arbeiteten bis 1999 an der Version 1, und schon 2002 wurde der RFC 3261 mit der bis heute immer noch gültigen Version 2.0 von der IETF veröffentlicht. Kein Wunder also, dass nach ca. 20 Jahren bereits am Nachfolger von SIP gearbeitet wird.

Anfang 2020 wurden einige Internet-Drafts von der IETF zum Thema »Real Time Internet Peering for Telephony Protocol (RIPT)« veröffentlicht. Einer der Autoren ist Jonathan Rosenberg, der bereits maßgeblich an SIP mitgearbeitet hatte. In diesen Dokumenten wird RIPT als Alternative für SIP, SDP und RTP definiert. Speziell wird auch der Anwendungsfall für die Anschaltung von IP-basierten TK-Anlagen an Provider angesprochen. Hier werden auch die gegenwärtigen Probleme von SIP-Trunks bei der Anschaltung an öffentliche Netze angesprochen. SIP wird nach [Ros20-1] als zu kompliziert eingeordnet, sodass die Bereitstellung von SIP-Trunks Wochen umfassen kann.

Was ist RIPT und wie unterscheidet es sich von SIP?

SIP ist ein Protokoll, das sich gleichberechtigt mit HTTP auf einer Ebene oberhalb von Schicht 4 befindet, aus Sicht des Internets also auf Anwendungsebene (Bild 1). Auf der gleichen Ebene standen auch File Transfer (FTP) und E-Mail (Simple Mail Transfer Protocol – SMTP), inzwischen laufen allerdings immer mehr Applikationen auf der Basis von HTTP, die dann in einheitliche Anwendungsoberflächen sowie Sicherheitskonzepte eingebunden werden können. Beispiele dafür liefern Cloud-Konzepte sowie containerbasierte Ansätze (z. B. Kubernetes, eine Software zur Bereitstellung ­und Verwaltung von Containern) oder auch Lambda (Funktionen in einem Programm, die über eine Referenz aufgerufen werden). Mit SIP sind diese integrierten Ansätze nicht möglich, wären teilweise aber sehr erwünscht.

Jonathan Rosenberg schreibt im Jahr 2019 [Ros19] zu den SIP-Problemen und der Planung für den Nachfolger RIPP (woraus ab 2020 dann RIPT wurde):

»RIPP is used to provide telephony peering between a trunking provider (such as a telco), and a trunking consumer (such as an enterprise, cloud PBX provider, cloud contact center provider, and so on). RIPP is an alternative to SIP, SDP and RTP for this use case, and is designed as a web application using HTTP/3.«

und

»In addition, SIP trunking has suffered from complex provisioning operations, oftentimes requiring the exchange of static IPs and ports. These operations are almost never self-service and consequently, SIP trunk turnups can take weeks.«

Bild 1: Vergleich der Einordnung von SIP und RIPT im OSI-Referenzmodell

Von J. Rosenberg wurde vor dem Hintergrund der mit SIP verbundenen Schwierigkeiten und Beschränkungen in der IETF ein Vorschlag für einen SIP-Nachfolger vorgelegt, der die Signalisierung über HTTP überträgt. SIP steht mit HTTP auf einer Ebene und das vorgeschlagene Protokoll basiert auf HTTP. Dieses neue Protokoll wird als Real Time Internet Peering for Telephony Protocol (RIPT) bezeichnet, und da es auf HTTP basiert, ist es eine Webapplikation. RIPT ersetzt damit nicht nur SIP, SDP und RTP, sondern auch die Kommunikationsprotokolle zu WebRTC.

Mit RIPT ist die Telekommunikation also nicht mehr nur IP-basiert, sondern auch ein Teil des World Wide Web. VoIP wird eine App basierend auf HTTP, so wie viele andere Applikationen. Durch die Festlegungen mit HTTP/3 wurden auch webbasierte Echtzeitanwendungen möglich.

Mit diesem neuen Ansatz und der Webbasis hofft man vielen Problemen der Konfiguration von Netzelementen und der Verwendung von Parametern in RTP und SIP aus dem Wege zu gehen. Bei SIP und RTP spielen viele Komponenten (Firewall, Proxy auf der Seite des Netzbetreibers, Proxy auf der Seite des Privatnetzes, SBC, DNS, NAT usw.) mit ihren jeweiligen Konfigurationen eine wichtige Rolle. In allen Komponenten muss die Einstellung korrekt sein, damit es durchgängig funktioniert. In der Praxis stellte und stellt sich das oft als sehr problematisch dar, weil entweder SIP-Parameter unterschiedlich verwendet oder interpretiert werden oder Konfigurationen für eines der notwendigen Netzelemente nicht passen.

Als SIP Ende der 1990er-Jahre festgelegt wurde, gab es oberhalb der Schicht 4 noch viele verschiedene Anwendungen. FTP, Mail, Telnet usw. standen – so wie SIP – mit HTTP parallel auf einer Ebene. Inzwischen haben viele spezielle und hergebrachte Anwendungen ihre Bedeutung im Internet verloren. Viele neue Anwendungen und Funktionen wurden inzwischen webbasiert realisiert oder ein Bestandteil von HTTP. Für viele neuere Entwicklungen und Dienste spielte und spielt weiterhin das Web eine zentrale Rolle. Aus diesem Grund könnte eine Webbasis für die Steuerung von Sprache und die Übertragung der Nutzinformationen einige Vorteile haben. Wie für andere Webanwendungen können beispielsweise Load Balancer Kubernetes (webbasierte Applikationen in Containern wie Docker mit Load Balancing und Skalierung) auch für RIPT ein­gesetzt werden. Dieser Trend und die Verfügbarkeit von HTTP/3 für die Echtzeitkommunikation bildeten damit die Grundlagen für RIPT. In den SIP-Architekturen wurde zwischen Call Control (SIP) und Medienübertragung (RTP) unterschieden. Mit RIPT kann beides gemeinsam mit HTTP/3 basierend auf QUIC übertragen werden, eine Trennung zwischen Call Control und Medienübertragung gibt es hier nicht mehr.

Eine URI für einen Call

Die Verbindungen sind nicht mehr durch IP-Adressen und TCP / UDP-Ports gekennzeichnet, sondern unabhängig von diesen durch eine spezielle Call-URI oberhalb der UDP-Ebene. Damit kann eine Trennung zwischen dem Call (z. B. einer Voice-Verbindung) und der Netzverbindung (Adresse und Port) erreicht werden. Dieses ermöglicht wiederum, dass das Netz und die Netzadresse für eine bestehende Verbindung gewechselt werden können (netzübergreifendes Handover).

Transport mit QUIC

Für den Transport der Nachrichten, d. h. den Austausch der Nutzinformationen, und für die Signalisierung verwendet RIPT das UDP-basierte Protokoll QUIC (Bild 2). In der IETF will man QUIC als den Namen dieses Protokolls und keine umständlichen Abkürzungen wie etwa Quick UDP Internet Connections [Iye20]. QUIC unterstützt:

• Eine schnellere Übertragung durch UDP mit einem verkürzten Verbindungsaufbau.
• Eine Fehlerkorrektur (Forward Error Correction – FEC), das erspart wiederholtes Senden fehlerhafter Pakete.
• Verbindungs-ID: Eine Verbindung wird durch die Verbindungs-ID identifiziert, nicht durch eine bestimmte IP-Adresse. Dadurch kann das Netz und damit die IP-Adresse unter Beibehaltung der Verbindungs-ID geändert werden.
• Multiplexing: Mehrere Anfragen zwischen dem Endsystem und dem Server werden gemeinsam über eine Verbindung übertragen und müssen nicht mehr sequenziell beantwortet werden.
• Sicherung der Übertragung mit Authentifizierung und Verschlüsselung der Daten und von Teilen des Headers.

QUIC wurde bereits 2013 von Google vorgestellt und basiert auf dem verbindungslosen UDP. Es soll eine vergleichbare Sicherheit wie TCP, HTTP/2 und TLS / SSL anbieten. Gleichzeitig soll es einen schnelleren und gesicherten Nachrichtenaustausch ermöglichen. Die Übertragung von HTTP über QUIC wird auch als HTTP-over-QUIC oder HTTP/3 bezeichnet. Für die Festlegungen von RIPT ist QUIC oder HTTP/3 eine wichtige Voraussetzung. Für den Transport der Nutzinformationen – des Medienstroms – werden für jedes Paket typischerweise 30-ms-Sprachproben des Senders zusammengefasst (Media Chunks). Diese Informationen werden mit einer Sequenznummer und einer Time Stamp, wie mit RTP, versehen. In RIPT werden die Nutzdaten grundsätzlich verschlüsselt übertragen. Wie in RTP wird in jedem Datenpaket (Media Chunk) der verwendete Codec angezeigt (hier allerdings mit 32 bit statt mit 7 bit bei RTP).

Bild 2: Austausch von Nutzinformationen mit QUIC       Quelle: [Ros20-4]

Wenn die HTTP-Verbindung einen direkten, bidirektionalen Medienaustausch unterstützt, werden die Datenpakete als Datagramm direkt zwischen Client und Server ausgetauscht. Wird ein wechselseitiger Austausch nicht unterstützt, muss der Client mit einem HTTP-PUT den Datentransport von der Call-URI anfordern. Um Daten zu empfangen (Bild 2), sendet der Client einen GET-Request an die Call-URI und erhält dann in der Response (200 OK) die Nutzdaten. Die Übertragung vom Server zum Client ist komplexer, weil ein Standard-HTTP-Server keinen Request sendet. Daher sendet der Client eine PUT-Nachricht zum Server, dieser antwortet mit einer 200-OK-Nachricht mit Mediendaten. Im Gegensatz zu dem Austausch der Mediendaten auf Basis von RTP werden hier Pakete mit Mediendaten bestätigt, damit können gleichzeitig Rückkopplungen zu den Empfangseigenschaften (Paketverlust, Jitter usw.) an den Sender gegeben werden (das entspricht RTCP). Diese Bestätigungen bedeuten aber auch, dass doppelt so viele Pakete wie auf der Basis von RTP übertragen werden.

Fazit

Keine Panik! SIP ist nicht veraltet und RIPT wird nicht schon morgen in den TK-Anlagen der verschiedenen Hersteller auftauchen. Die Veröffentlichungen zu RIPT sind alle relativ jung und viele Dokumente haben noch offene Punkte. Die Zukunft wird zeigen, wie sich diese Protokolle und diese Architekturen durchsetzen werden. Auch wenn sich die Spezifikationen einmal stabilisiert haben, wird es sicher noch einige Zeit dauern, bis erste Systeme mit diesen Protokollen arbeiten. Dennoch: RIPT ist direkt als SIP-Nachfolger konzipiert. RIPT basiert auf HTTP/3 (QUIC over HTTP) und soll SIP, SDP, RTP und WebRTC ersetzen. Anders als in SIP werden Architekturen und Protokollabläufe für den Anschluss von privaten Telekommunikationsanlagen definiert. Auf alle Fälle wird RIPT eine Relevanz für die Telekommunikation haben und man sollte die weiteren Entwicklungen von RIPT im Auge behalten.

Prof. Dr.-Ing. Gerd Siegmund, Technische Hochschule Nürnberg Georg Simon Ohm
Er ist Verfasser des Standardwerks »Technik der Netze«. Für den VAF schreibt Gerd Siegmund regelmäßig Fachartikel, hält Vorträge auf Fachtagungen, übernimmt die wissenschaftliche Betreuung von Projekten und schult Mitglieder zu Themen in den Bereichen SIP, NGN, VoIP-Netze und Netzarchitekturen.