VoIP-Telefonie: IETF diskutiert Ablösung des SIP-Standards

Inhaltsverzeichnis

Jahrzehnte lang nutzen Netzbetreiber und Provider das Session Initiation Protocol (SIP), um den Telefoniedienst von der analogen Telefonleitung auf die IP-Netze umzuziehen. Jetzt schickt sich die Internet Engineering Task Force an (IETF), einen Nachfolger für die Voice-over-IP-Standardsuite zu schaffen. Einmal mehr sind es die Verlockungen des Web, denen bisherige SIP-Entwickler folgen.

Jonathan Rosenberg vom US-Cloudanbieter Five9 präsentierte beim virtuellen Treffen der IETF 107 die ersten Entwürfe für das Realtime Internet Peering for Telephony Protocol (RIPT), das auf HTTPS aufsetzen soll. RIPT soll nicht nur SIP ersetzen, sondern auch dem browserbasierten Kommunikationsprotokoll WebRTC Konkurrenz machen.

SIP zu kompliziert, zu alt

Rosenberg, ironischerweise einer der Autoren des über 20 Jahre alten SIP-Standards (anfangs noch als Ingenieur bei Bell Labs) hat für moderne, HTTP-basierte Dienste nur Lob übrig. SIP sei hingegen kompliziert und mittlerweile eine Parallelwelt zu all den HTTP-basierten Anwendungen. Dabei hat SIP sogar Ähnlichkeiten zu HTTP (Einzelheiten finden Sie im Dokument RFC3261). SIP wird nur für den Aufbau, die Steuerung und den Abbau von Verbindungen verwendet. Es ist flexibel und lässt sich nicht nur für die Telefonie nutzen, sondern auch für Videokonferenzen. Auch setzen einige Spiele auf SIP auf. Die Nutzdaten werden je nach Anwendung über andere Protokolle übertragen, bei der Telefonie zum Beispiel über das Real-Time Transport Protocol (RTP).

Doch VoIP-Provider seien durch SIP zu Speziallösungen für die Lastverteilung, Hochverfügbarkeit, das Clustering und die Sicherheit gezwungen, so Rosenberg. Sie könnten dafür nicht wie bei vielen anderen Anwendungen Cloudplattformen nutzen. Ein modernes, grundsätzlich HTTP-basiertes VoIP könne hingegen für AWS, Azure, Google Cloud oder ähnliche Angebote ausgelegt werden. Außerdem ist Rosenberg sicher, dass man mit HTTP die SIP-typischen Hürden wie das NAT-Traversal, Firewalls und Mittelboxen umgehen kann. Auch sei dann für VoIP ein höherer Automatisierungsgrad zu erwarten.

Bei HTTPS-Request: Anruf

Ein HTTP-basierter Anruf, dessen Initiator sich vorher via Oauth bei seinem VoIP-Provider authentifiziert hat, könne laut Rosenbergs Vorschlag künftig so aufgebaut werden:

POST "https://comcast.net/.well-known/ript/v1/providertgs/123/calls
 {     "handler":

      "https://comcast.net/.well-known/ript/v1/providertgs/123/handlers/abc",

      "destination": "+14089529999",

      "passport": "{passport encoding}"

Bei der RIPT-Entwicklung sitzen Cisco, Signalwire/Freeswitch, Comcast und Google mit im Boot. Das verwundert vielleicht auf den ersten Blick, weil mindestens Google zu den großen Treibern von WebRTC gehört, also der Integration der Voice- und Videokommunikation in Browser. Aber selbst bei Festnetz- und DECT-Telefonen der Oberklasse sind Webbrowser eine Ausnahme, sodass diese für WebRTC normalerweise nicht in Frage kommen. Zudem müssten sie für Browser und WebRTC leistungsfähigere Hardware enthalten, die sie wiederum unnötig verteuern würde. Justin Uberti verteidigte RIPT daher auch mit dem Hinweis, dass WebRTC gegenüber einem HTTP-basierten VoIP deutlich komplexer sei.

Reichlich spät

Jiri Kuthan, Vizepräsident des Berliner VoIP-Unternehmens Frafos bewertet die RIPT-Vorschläge als "technisch durchaus interessant" und begrüßt die "Cloud-Motivation". Jedoch warnte Kuthan, selbst viele Jahre aktiv an der SIP-Spezifikation beteiligt, dass Vereinfachung einst auch bei SIP ein Ziel war. Doch vor allem die gewollte Rückwärtskompatibilität mit bestehenden Netzen habe SIP komplexer gemacht als notwendig. Dass es mit RIPT besser werde, sei alles andere als ausgemacht. Und Lösungen für die Cloudanbindung und andere genannte Probleme habe man für SIP durchaus schon. Daher orientieren sich Kuthan und seine Firma am Motto "if it ain‘t broke, don‘t fix it".

Warten auf HTTP3?

Ganz neu ist die Idee mit HTTP als Grundlage für VoIP nicht, sagen sowohl Kuthan als auch Rosenberg. Rosenberg hat aber SIP eingehend mit ersten RIPT-Entwürfen verglichen und findet für RIPT zusätzliche Anreize im kommenden HTTP/3. Bei Vorgängerversionen von HTTP sind die Paketlaufzeiten für Telefonate wegen des TCP-basierten Phänomens Head-of-Line-Blocking zu lang. Diesen Nachteil wird HTTP/3, das auf Quic und damit auf UDP aufsetzt, nicht haben. Allerdings kritisieren manche Fachleute gerade diesen Punkt: Sie mutmaßen, dass ein HTTP/3-basiertes Protokoll wegen seiner Quic-UDP-Basis mit Firewalls und Gateways ebenfalls Probleme haben könnte wie SIP.

Wie aber soll RIPT in den Sattel kommen, wenn HTTP/3 noch längst nicht die Norm im Webverkehr ist, wollte Mark Nottingham wissen (Vorsitzender der Arbeitsgruppen HTTPBIS und Quic). Man kann mutmaßen: Entweder rechnet Rosenberg mit einer längeren RIPT-Standardisierung – oder die Gruppe legt RIPT für eine gegenwärtige Fassung von HTTP/3 aus und nimmt in Kauf, dass Anpassungsarbeiten erforderlich werden, wenn sich HTTP/3 künftig entscheidend anders entwickelt.

Alle Entwürfe für RIPT mitsamt der verschiedenen Erweiterungen finden sich bei der IETF:

• RealTime Internet Peering for Telephony
• RealTime Internet Peering for Single User Endpoints
• Real Time Internet Peering for Telephony (RIPT) Comparison with the Session Initiaton Protocol (SIP)
• RealTime Internet Peering for Telephony (RIPT) Compatibility with webRTC

(dz)