Zum Autor:

Viele Systemhäuser kennen Herausforderungen aufgrund nicht eindeutiger oder teils unvollständiger Schnittstellenbeschreibungen der Provider. Inzwischen gibt es über 100 RFCs mit Bezug zu SIP mit grundlegenden Eigenschaften und Erweiterungen. Die Provider und Hersteller sind nicht verpflichtet, die Empfehlungen zu befolgen. Für SIP-Trunks gibt es Empfehlungen zur Implementierung in SIPConnect 2.0. Trotz dieser Definition stellt gefühlt jede SIPTrunk-Implementierung die Systemintegratoren vor neue Herausforderungen. Als Beispiel sind unterschiedliche Transportprotokolle (UDP, TCP, TLS über TCP) zu nennen, aber auch die Unterstützung für Fax über T.38 Relay oder die Unterstützung der verschlüsselten Sprache über das Secure Realtime Transport Protocol (SRTP) und die zugehörigen Schlüsselaustauschmethoden.

Durch Tests, Analysen und Troubleshootings braucht es bis zur Fertigstellung der finalen Konfigurationsparameter einiges an Zeit. Dabei lassen sich meist nicht alle Szenarien testen. Insbesondere das Verhalten an Netzübergängen zwischen Providern oder oder an Übergängen in leitungsvermittelnde Netze oder Mobilfunknetze differiert häufig. Dies bedeutet in einigen Fällen mehrere Tage für Troubleshooting auf Kundenseite, aber auch Aufwände beim Provider. Möchte der Kunde den Provider wechseln, beginnt dies von Neuem. Aufgrund der Komplexität bedarf es teils auch eines hohen Skill-Levels auf beiden Seiten. Leider gibt es aktuell keine Spezifikation für den automatisierten Austausch von Eigenschaften in SIP. Diese wäre aber gerade bei harten Migrationen oder Wechsel des Providers nützlich.

Entwurfsstadium und Ziele

Die Arbeitsgruppe »Automatic SIP Trunking and Peering (asap)« der IETF hat sich des Themas angenommen und erste Entwürfe für einen neuen RFC entwickelt. In dem Draft geht es um das Auto-Peering, also einen automatisierten Datenaustausch der Providereigenschaften mit Mappings auf die Konfiguration des E-SBC. Der RFC Draft behandelt die beteiligten Komponenten, den Bezug über eine authentifizierte und verschlüsselte Verbindung sowie ein Datenmodell für das Mapping der Providereigenschaften in einen E-SBC-Konfigurationsblock. SIPConnect2.0 bildet die Grundlage des Austauschs der Eigenschaften im genannten Draft. Die Integration in den E-SBC soll in der Weiterentwicklung sowohl automatisiert als auch zur Wahrung der Datenhoheit beim Kunden über administratives Eingreifen, bzw. Freigabe durch den Integrator, möglich sein. Jedoch werden bisher nur notwendige Informationen für das Peering übertragen. Beispielsweise nur, ob der Provider T.38 Relay unterstützt, aber nicht, ob T38FaxFillBitRemoval auf Providerseite aktiv ist.

Dabei sollte dem IETF-Entwurf zufolge der Austausch zwischen Provider und Kunde basierend auf einem bekannten Protokoll stattfinden. Zusätzlich sollte der Workflow die Flexibilität bieten, um basierend auf der Identität des Unternehmens differierende Antworten zu geben, wie es für unterschiedliche Rufnummernblöcke für Kunden notwendig ist. Die Antwort des Providers auf die Konfigurationsanfrage des Kunden sollte für den E-SBC einfach zu parsen und automatisiert verarbeitbar sein.

Bild 2:  Workflow des Bezugs mit vorheriger Authentifizierung und Autorisierung über das OAuth-2.0-Verfahren und den Resource Owner Credential Grant Type

Konfigurationsworkflow

Als Ergebnis des Entwurfs soll nun der Provider, wie in Bild 1 dargestellt, einen oder mehrere Capability Server als Webserver bereitstellen. Der E-SBC bekommt die Ziel-URL entweder initial konfiguriert oder er ermittelt diese über das Webfinger-Protokoll. Auf die Ziel-URL führt der E-SBC dann einen verschlüsselten GET Request über HTTPS aus, um die Eigenschaften des Providers zu erhalten. Die Antwort erfolgt je nach angegebenem Accept Header im GET Request im XML-(Extensible Markup Language; MIME Type application/peering-info+xml) oder JSON-Format (Javascript Object Notation; MIME Type application/peering-info+json). Darin sind Attribut/Wert-Paare mit den spezifischen Eigenschaften des Providers enthalten. Als Datenmodell kommt das YANG-Datenmodell zum Einsatz, das eine einheitliche herstellerneutrale Datenbasis für die Konfiguration schaffen soll. Der E-SBC parst (s.o.) die Inhalte und erstellt Konfigurationsdaten. Es kann auch eine direkte Integration oder bei mehreren E-SBCs eine automatisierte Verteilung erfolgen.

Bei einer Anschaltung über einen SIP- Transit-Provider muss dies der Provider in den Capabilities berücksichtigen. Wenn also beispielsweise der SIP-Trunk-Provider die Codecs G.711 und G.722 unterstützt, der Transit-Provider aber nur G.711, darf der Capability Server nur G.711 anbieten. Der E-SBC muss zur Absicherung eine clientseitige HTTPS-Authentifizierung und Autorisierung über das OAuth-2.0-Framework beherrschen. Dabei besteht jedoch ein Problem beim Einsatz reiner kommandozeilenbasierter (CLI) E-SBC-Konfigurationslösungen. Über CLI besteht nicht die Option, über OAuth 2.0 eine Authentifizierungsseite anzeigen zu lassen, um nach erfolgreicher Authentifizierung einen Autorisierungscode und in Folge einen Access Token zu erhalten. Über eine grafische Oberfläche für die Konfiguration könnte eine Umleitung auf einen Autorisierungsserver abbildbar sein, um eine Authentifizierung durchführen zu können.

Es kommt somit der sogenannte Resource Owner Credential Grant Type von OAuth 2.0 zum Einsatz. Bei diesem übermittelt der E-SBC eine Benutzername/Kennwort-Authentifizierung zu einem Autorisierungsserver des Providers. Das Verfahren ist vereinfacht in Bild 2 dargestellt. Die benötigten Anmeldeinformationen muss der Provider über E-Mail, auf Basis eines bestehenden Self-Service oder über einen Brief bereitstellen. Es wird empfohlen, den Bezug der Eigenschaften wiederholt alle 24 Stunden durchzuführen.

Fazit

Es handelt sich beim oben beschriebenen automatisierten Datenabgleich zunächst lediglich um einen Entwurf. Jedoch ist die Arbeitsgruppe aktiv und hat bereits  interessante Ansätze hervorgebracht. Der Entwurf hat das Potenzial, die Implementierung von SIPTrunks erheblich zu vereinfachen und Fehler zu vermeiden. Es gibt jedoch auch noch Entwicklungspotenzial, wie beispielsweise für den Einsatz an privaten SIP-Trunks, aber auch bei Peerings zwischen Providern. Auch dort kommt es in einigen Fällen zu Kompatibilitätsproblemen, die sich bei den Kunden negativ auswirken. Jedoch sind diese durch fehlende Sichtbarkeit für die Systemintegratoren sogar häufig noch schwieriger zu entdecken. Auch wenn der Entwurf die SIP-Implementierung bereits in seinem jetzigen Stadium stark vereinfacht und vorantreibt, gibt es für die Arbeitsgruppe auf dem Weg zum Auto-Peering noch genug zu tun.