aus dem Netzwerk Insider April 2023
Sprechen Sie schon SIP? Zumindest im Bereich der Sprachkommunikation geht kein Weg am Session Initiation Protocol (SIP) vorbei. Einerseits wird SIP als Signalisierungsprotokoll bei IP-basierten Telefonanlagen und UC-Lösungen sowie bei SIP-Trunks zwischen verschiedenen, IP-basierten Anlagen eingesetzt. Zum anderen stellen die Provider seit Jahren die Amtsanschlüsse von klassischen, ISDN-basierten Anschlüssen auf IP-basierte Anschlüsse um. Diese Umstellung ist zwar schon sehr weit fortgeschritten, jedoch sind noch längst nicht alle Amtsanbindungen als SIP-Trunk realisiert. Daher stehen einige Unternehmen auch heute noch vor einer Migration der ISDN-basierten Amtsanbindungen. Hierbei gibt es einige Punkte zu beachten: angefangen von der grundsätzlichen Architektur, also der Frage, ob ein zentraler SIP-Trunk oder mehrere, dezentrale SIP-Trunks genutzt werden sollen, über die Absicherung mittels Session Border Controler (SBC) bis hin zum physikalischen Anschluss an das Providernetz. Diese und weitere Themen rund um das SIP-Trunking wollen wir im folgenden Artikel genauer betrachten.
Änderungen bei Umstellung von ISDN auf SIP-Trunks
Zunächst schauen wir auf typische Architekturen, die bei ISDN-basierten Amtsanschlüssen bei Unternehmen mit verteilten Standorten anzutreffen sind. Hier ist jeder Standort mit einem dedizierten ISDN-basierten Anschluss an das öffentliche Telefonnetz angebunden. Am Hauptstandort ist eine zentrale Telefonanlage (PBX, Private Branch Exchange) vorhanden, die sämtliche Teilnehmer mit den entsprechenden Leistungsmerkmalen versorgt. Die weiteren Standorte sind über ein Weitverkehrsnetz (WAN, Wide Area Network) mit dem Hauptstandort verbunden. Jeder Standort hat in der Regel eine lokale Rufnummer mit eigenem Rufnummernblock. Die Anzahl der Sprachkanäle ist abhängig von der Anschlussart, angefangen mit kleinen ISDN-Basisanschlüssen und ISDN-Mehrgeräteanschlüssen, die in der Regel 2 ISDN-Kanäle bereitstellen, bis hin zum Primärmultiplex-Anschluss (PMX-Anschluss), dessen Kanalanzahl ein Vielfaches von 30 ist. Die Abbildung 1 zeigt ein Beispielunternehmen mit mehreren dezentralen Standorten. Die Telefonanlage ist hier schon eine IP-basierte Anlage, die somit über ein ISDN-IP-Gateway an den ISDN-Trunk angeschlossen ist. Als ISDN-Trunk wird hier die Anbindung an den Provider bezeichnet.
Mit der Umstellung auf IP-basierte Anschlüsse ergeben sich für das Beispielszenario Änderungen in Bezug auf folgende Themen:
- Realisierung der Provider-Anbindung
- Verteilung der SIP-Trunks
- Dimensionierung des SIP-Trunks
- Notwendigkeit eines SBC im eigenen Netz
Realisierung der Provider-Anbindung
Zuerst schauen wir uns den grundsätzlichen Aufbau eines SIP-Trunks an (siehe Abbildung 2). Die Provider haben jeweils lokale Points of Presence (POP) sowie eigene SBCs, die jedoch für die Absicherung des eigenen Netzes sorgen. Aufseiten des SIP-Providers erfolgt der Übergang ins öffentliche Telefonnetz (PSTN, Public Switched Telephone Network, oder NGN = Next Generation Network). Hierzu hat jeder Provider entsprechende Peerings mit weiteren Providern, damit auch eine Provider-übergreifende Kommunikation möglich ist. Weiterhin stellt der Provider einen Datenanschluss sowie einen Abschluss-Router, oft Customer Edge Router (CER) genannt, zur Verfügung. Hinter diesem Router befindet sich der Leistungsübergabepunkt (LÜP) in das Unternehmensnetz. An diesen schließt sich in der Regel eine DMZ mit Firewalls sowie Unternehmens-SBCs an. Die Positionierung eines SBC werden wir später noch genauer betrachten. Hinter dem Edge Router und der DMZ wird oft ein sogenanntes Transfernetz aufgebaut, um bei redundanten Anschlüssen ein Routing zwischen den Anschlüssen zu ermöglichen.
Sofern ein solcher SIP-Trunk als Ablösung für einen ISDN-basierten Anschluss aufgebaut wird, ist zunächst die Verkabelung zwischen dem physikalischen Anschlusspunkt und dem Standort des Edge-Routers aufzubauen. Hierfür sollte im Vorfeld mit dem Provider ein entsprechendes Konzept erarbeitet und die Verkabelung (zum Beispiel per Glasfaser- oder Kupfer-Kabel) gemäß dem Konzept realisiert werden. Gegebenenfalls sind hierfür auch Baumaßnahmen notwendig. Daher sollte für die Planung und Realisierung ausreichend Zeit eingeplant werden. Nach der Projekterfahrung der ComConsult kann dies bis zu 6 Monate, in einigen Fällen sogar länger, in Anspruch nehmen. Zudem ist die Verkabelung für jeden Standort, an dem ein SIP-Trunk aufgebaut werden soll, separat zu prüfen und ggf. neu aufzubauen. Natürlich tritt dieser Aufwand nur bei einer erstmaligen SIP-Migration auf, sobald ein Wechsel von SIP-Provider A auf SIP-Provider B durchgeführt werden muss, fällt der Aufwand wesentlich geringer aus. Es muss dann überprüft werden, ob die Verkabelung für die geplante Anbindung ausreichend dimensioniert ist. Für diese Überprüfung und etwaige Anpassungen sollte trotzdem ein Zeitraum von 4 bis 8 Wochen zur Verfügung stehen.
Ein SIP-Trunk ist immer mit einem Datenanschluss verbunden und kann auf zwei Arten realisiert werden:
- Variante 1: Nutzung des bestehenden Datenanschlusses / der Internetverbindung (siehe Abbildung 3)
Hierbei wird der SIP-Trunk über einen bestehenden Datenanschluss realisiert, wodurch über diesen Anschluss sowohl der Internet-Datenverkehr als auch der SIP-Datenverkehr verläuft. In dem Fall ist keine zusätzliche physikalische Anbindung an den SIP-Provider notwendig, was den hier oben beschriebenen Aufwand zur Realisierung der Verkabelung stark reduziert. Außerdem kann der SIP-Provider unabhängig von eigenen Leitungen ausgewählt werden. Jedoch ist die Nutzung des bestehenden Datenanschlusses mit einigen Risiken verbunden. Zunächst ist festzuhalten, dass grundsätzlich eine Internetverbindung für die Telefonie genutzt wird, es somit keine garantierte Verfügbarkeit sowie Qualität für die Anbindung gibt. Zudem sind sowohl die Konfiguration des SIP-Trunks als auch die Fehlersuche erschwert, da über den Datenanschluss mehrere Dienste (SIP-Dienste und Internet-Datenverkehr) genutzt werden.
- Variante 2: Nutzung eines dedizierten Datenanschlusses (siehe Abbildung 4)
Bei dieser Variante wird ein dedizierter Datenanschluss für den SIP-Trunk genutzt. Dies bietet den Vorteil, dass über diesen Datenanschluss kein Internet-Datenverkehr geroutet wird und somit der Anschluss exklusiv für den SIP-Trunk zur Verfügung steht. Durch die direkte Anbindung an den Provider sind sowohl Verfügbarkeits- als auch Qualitäts-Garantien möglich. Zudem ist der Aufwand für Konfiguration des SIP-Trunks und die Fehlersuche gegenüber der Nutzung eines bestehenden Datenanschlusses deutlich reduziert. Es ist zwar gegebenenfalls ein weiterer, dedizierter Anschluss und damit eine dedizierte Verkabelung aufzubauen, jedoch entspricht diese Variante eher der Ablösung der ISDN-basierten Anschlüsse, bei denen ebenfalls ein dedizierter Anschluss verfügbar war. Darüber hinaus wird die Variante mit einem dedizierten Anschluss von den Providern auch favorisiert. Folglich ist in Migrationsprojekten der ComConsult diese Variante deutlich häufiger anzutreffen als die Variante 1.
In diesem Zusammenhang wird oft die Frage nach der Providerwahl gestellt. Sollte für einen SIP-Trunk nicht am besten der Internet-Provider gewählt werden? Dieser hat doch schon sämtliche Kabel gelegt und auch die Verkabelung zur DMZ bzw. zum Rechenzentrum ist in einem solchen Fall schon vorhanden. Überdies besteht ein SIP-Trunk doch immer aus einem Datenanschluss, sodass bei getrennten Providern zusätzliche Kosten für den weiteren Datenanschluss entstehen. So zumindest vielfach die Argumentation unserer Kunden. Doch in der Praxis sehen wir eher getrennte Provider für die Bereitstellung von Internetzugängen und SIP-Trunks. Es gibt zwar einige Synergieeffekte, wenn hier ein einheitlicher Provider beauftragt wird, jedoch können im Rahmen von Ausschreibungen oder Verhandlungen oft bessere Konditionen erreicht werden, wenn die Wahl der Provider unabhängig voneinander durchgeführt wird. Die zusätzlichen Kosten, die für den weiteren Datenanschluss aufzubringen sind, fallen in der Gesamtkostenrechnung dann ebenfalls nicht ins Gewicht.
Verteilung der SIP-Trunks
Mit der Umstellung auf IP-basierte Anschlüsse für die Telefonie stellt sich auch die Frage, ob die klassischen Standort-Konzepte, insbesondere die Anbindung jedes Standortes über eine dedizierte Anbindung, weiterhin so verfolgt werden sollen. Grundsätzlich sind die folgenden drei Varianten möglich:
- Ausschließlich zentraler SIP-Trunk am Hauptstandort
- Zentraler SIP-Trunk am Hauptstandort, dezentrale SIP-Trunks an ausgewählten Standorten
- Dezentrale SIP-Trunks an jedem Standort
Betrachten wir zunächst die Option, lediglich am Hauptstandort einen SIP-Trunk aufzubauen. Die Abbildung 5 zeigt diese Option für das Beispielszenario.
Die einzelnen Standorte erhalten keinen dedizierten SIP-Trunk, können jedoch weiterhin lokale Rufnummern erhalten. Vom SIP-Provider werden alle eingehenden Anrufe auf den zentralen SIP-Trunk geroutet. Die Verteilung auf die einzelnen Standorte erfolgt entweder über den SBC oder die TK-Anlage des Unternehmens. Dies ist abhängig davon, in welcher Komponente die Routing-Entscheidung getroffen werden soll. Ausgehende Gespräche werden ebenso über den zentralen SIP-Trunk geroutet. Falls für die einzelnen Standorte lokale Rufnummern genutzt werden, werden diese auch bei einem zentralen SIP-Trunk signalisiert. Die Medienströme sowie die Signalisierung werden über das WAN zu den einzelnen Standorten verteilt. Dies bedeutet, dass für sämtliche Gespräche, die nicht innerhalb von Standorten durchgeführt werden, dass WAN genutzt wird und somit entsprechende Bandbreiten zur Verfügung stehen müssen. Außerdem ist die Verfügbarkeit des WAN ausschlaggebend für die Verfügbarkeit von Telefonie-Diensten.
Beim zentralen SIP-Trunk ist noch der Notrufaspekt zu beachten. Für Notrufe muss geprüft werden, wie der Anruf zur jeweils zuständigen Leitstelle gelangt. Dies sollte im Rahmen der Migration gemeinsam mit dem Provider getestet werden. Die Zuordnung kann bei der Nutzung von lokalen Rufnummern zum Beispiel anhand der zu signalisierenden Teilnehmerrufnummer vorgenommen werden. Sofern jedoch für alle Standorte eine zentrale Rufnummer genutzt wird, müssen für jede Rufnummer Informationen zum geographischen Standort an den Provider übermittelt werden, damit die Anrufe zur korrekten Leitstelle geroutet werden können.
Mithilfe des SIP-Protokolls können dazu Informationen zum geographischen Ort hinterlegt werden. Hierzu ist von der Internet Engineering Task Force (IETF) mit dem RFC 4119 (siehe [1]) das im RFC 3863 (siehe [2]) definierte Presence Information Data Format (PIDF) um die Möglichkeit zur Übermittlung von geographischen Ortsinformationen erweitert worden. Das PIDF wurde ursprünglich als Erweiterung des Common Profiles for Instant Messaging (CPIM) entwickelt, um Präsenzinformationen zwischen verschiedenen Lösungen ohne Modifikation übertragen zu können. Im RFC 5139 (siehe [3]) sowie RFC 5491 (siehe [4]) ist eine zusätzliche Erweiterung, das Presence Information Data Format Location Object (PIDF-LO), definiert. Über verschiedene Parameter, wie Straße, Straßenkreuzung oder Name, kann so der jeweilige Ort bestimmt werden. Allerdings müssen solche Informationen auch stets korrekt und aktuell gehalten werden. Zudem sollte geprüft werden, ob diese Informationen auch vom Provider verarbeitet werden können. Die Nutzung von PIDF-LO stößt insbesondere in Zusammenhang mit mobilem Arbeiten und der Nutzung von Softphones an Grenzen. Denn Nutzer mit PC- oder Smartphone-basierten Softphones sind typischerweise nicht immer an einem festgelegten Ort, sondern können sich sowohl innerhalb des Unternehmensgeländes als auch an anderen Orten außerhalb des Unternehmensgeländes aufhalten. In diesen Fällen ist eine starre Konfiguration der übermittelten Ortsinformationen nicht sinnvoll, und es sollte daher für Notrufe auf andere Kommunikationswege wie Mobilfunk zurückgegriffen werden.
Für die SIP-Anbindung können neben einem zentralen SIP-Trunk noch weitere, dezentrale SIP-Trunks genutzt werden (siehe Abbildung 6).
Bei dieser Option werden neben dem Hauptstandort weitere Standorte mit SIP-Trunks ausgestattet. Hierbei müssen bei der erstmaligen Migration von ISDN-basierten Anschlüssen auf SIP-Trunks ebenfalls die oben beschriebenen Voraussetzungen hinsichtlich Verkabelung geschaffen werden. Außerdem ist eine Entscheidung bezüglich des Datenanschlusses an den Standorten mit zusätzlichen SIP-Trunks zu treffen. Ein Vorteil gegenüber lediglich einem zentralen SIP-Trunk besteht darin, dass im Falle eines Ausfalls eines der SIP-Trunks die Gespräche über einen der anderen SIP-Trunks geführt werden können. Die Entscheidung, welche der Standorte über einen eigenen SIP-Trunk verfügen sollen, ist in der Regel von verschiedenen Faktoren abhängig und wird projekt- bzw. kundenspezifisch getroffen.
Als letzte Option können sämtliche Standorte mit dedizierten SIP-Trunks ausgestattet werden (siehe Abbildung 7). Dieses Szenario wird nach der Projekterfahrung der ComConsult nur in Ausnahmefällen gewählt, in der Regel werden lediglich ausgewählte Standorte sowie der Hauptstandort mit einem SIP-Trunk an das öffentliche Telefonnetz angeschlossen. Dies ist unter anderem darin begründet, dass für einen SIP-Trunk nicht nur der Anschluss an den Provider realisiert werden muss, sondern oft auch ein SBC eingesetzt wird. Im Falle von dezentralen SIP-Trunks wären somit auch dezentrale SBCs notwendig, die je nach Anforderung sehr kostenintensiv sein können. Darüber hinaus steigen mit der Anzahl der SIP-Trunks auch die Betriebsaufwände und die Kosten je Standort.
Dimensionierung des SIP-Trunks
Eine andere Entscheidung, die im Rahmen einer SIP-Migration getroffen werden muss, ist die Frage nach der Dimensionierung der SIP-Trunks. Durch den Technologiewechsel können wesentlich flexiblere Kanalanzahlen gebucht werden. Bei der ISDN-basierten Amtsanbindung waren die Kanalanzahlen entweder im einstelligen Bereich oder auf ein Vielfaches von 30 beschränkt. Bei SIP-Trunks wird stattdessen eine Bandbreite für den Anschluss (beispielsweise 100 Mbit/s) festgelegt. Die Bandbreite kann anhand der benötigten gleichzeitigen Sprachverbindungen bestimmt werden. Dafür sollte man jedoch einen ausreichenden Puffer einplanen. Im Rahmen einer SIP-Migration kann in der Regel eine Reduktion der Gesamtzahl an Sprachkanälen erreicht werden. Allerdings sollte man dabei beachten, dass, wie auch bei ISDN-basierten Amtsanschlüssen, bei der Nutzung von Funktionen wie Rufumleitung auf externe Ziele zwei Kanäle für ein Gespräch benötigt werden.
Bei der Bestimmung der notwendigen Bandbreite sollten mögliche Redundanzen berücksichtigt werden. Sollen beispielsweise im Fehlerfall Gespräche über einen weiteren SIP-Trunk geroutet werden, muss dieser SIP-Trunk auch entsprechend dimensioniert sein und somit über eine ausreichende nutzbare Bandbreite verfügen. Die Dimensionierung des SIP-Trunks hat ebenfalls Auswirkungen auf die oben beschriebene Verkabelung von Anschlusspunkt und Edge Router.
Neben der reinen Dimensionierung der Datenanschlüsse sollten mit dem SIP-Provider weitere Qualitäts- und Service-Parameter unter Berücksichtigung der mindestens folgenden Aspekte festgelegt werden:
- Verfügbarkeit des Datenanschlusses
- Wiederherstellungszeiten im Fehlerfall
- Alternative Routings im Falle der Nichterreichbarkeit einzelner Standorte (im Falle von mindestens zwei physikalisch getrennten SIP-Trunks)
Entgegen der landläufigen Meinung, dass IP-basierte Anschlüsse öfter ausfallen, beträgt die Verfügbarkeit, die von den SIP-Providern angeboten wird, oft 99,9 % oder mehr. Dies liegt deutlich über der Verfügbarkeit von klassischen ISDN-basierten Anschlüssen, die oft nur bei 98,5 % lag. Somit hat zumindest rechnerisch ein IP-basierter Anschluss eine wesentlich höhere Verfügbarkeit. Zudem gibt es bei SIP-Trunks deutlich flexiblere Möglichkeiten, um Redundanzen zu schaffen und somit die Gesamt-Verfügbarkeit der Telefonie zu steigern.
Notwendigkeit eines SBC im eigenen Netz
Ein sehr wichtiges Element des SIP-Trunks ist der SBC im eigenen Netz. Die SIP-Provider setzten zwar ihrerseits ebenfalls SBCs ein, diese sind jedoch zum Schutz des jeweiligen Provider-Netzes. Um das Unternehmens-Netz abzusichern, sollte daher im eigenen Netz ein SBC eingesetzt werden. Ein SBC kann grundsätzlich verschiedene Aufgaben erfüllen:
- Absicherung
Ein SBC schützt sowohl die aktuelle Kommunikationsbeziehung als auch das eigene Netz. Zum Schutz der Kommunikationsbeziehung wird geprüft, ob Signalisierung und Medienstrom mittels TLS (Transport Layer Security) und SRTP (Secure Realtime Transport Protocol) verschlüsselt übertragen werden. Hierbei ist jedoch zu beachten, dass zur Verschlüsselung der Kommunikation in Richtung Provider einige Voraussetzungen erfüllt werden müssen (siehe hierzu [5]) und dass eine übergreifende Verschlüsselung der Medienströme über das öffentliche Telefonnetz in der Regel nicht erreicht werden kann. Dennoch prüft der SBC, ob zumindest innerhalb des eigenen Netzes die Signalisierung und die Medienströme verschlüsselt übertragen werden.
Zum Schutz des eigenen Netzes verbirgt der SBC die interne Netz-Topologie. Die Medienströme, die aus externen Netzen kommen, terminieren am SBC, sodass ein externer Kommunikationspartner keine Kenntnis über das Netz hinter dem SBC benötigt.
Darüber hinaus kann ein SBC auch Denial of Service (DoS) entgegenwirken, indem beispielsweise in kurzen Zeitabständen wiederholte Verbindungsanfragen blockiert werden.
- Konnektivität
Ein SBC stellt die Verbindung zwischen internen und externen Netzen hier. Hierbei kann eine Konvertierung und Normalisierung der Signalisierung erfolgen. Zum einen übersetzt der SBC zwischen der Signalisierung per SIP und einer Signalisierung per H.323, wobei letzteres Signalisierungsprotokoll noch aus der ISDN-Welt stammt und sukzessive durch SIP abgelöst wird. Doch auch wenn sowohl Sender als auch Empfänger per SIP kommunizieren, kann es hierbei unterschiedliche Ausprägungen und Umsetzungen des SIP-Standards geben. Jeder Hersteller von TK- und UC-Anlagen sowie jeder Provider nutzt gegebenenfalls spezifische Methoden innerhalb des SIP-Protokolls, die durch einen SBC entsprechend so übersetzt werden müssen, dass die jeweilige Gegenseite hiermit umgehen kann.
- Quality of Service
Ein SBC stellt die Service-Qualität sicher, indem beispielsweise die Datenpakete klassifiziert und in die richtige Class of Service eingeteilt werden. Dies gewährleistet, dass Sprachpakete auch in die Voice-Klasse eingeordnet und somit innerhalb der IP-Netze priorisiert übertragen werden. Zudem kann mithilfe von Call Admission Control (CAC) eine maximale Anzahl an Verbindungen oder eine maximale Datenrate je SIP-Trunk festgelegt werden. Bei Überschreitung der Grenzwerte können Gespräche entweder umgeleitet oder vor Verbindungsaufbau unterbunden werden.
- Regulatorische Funktionen
Als regulatorisches Element stellt der SBC sicher, dass zum Beispiel Notrufe trotz bestehender Gespräche durchgeführt werden. Ist eine Verbindung schon ausgelastet, können zum Aufbau einer Notrufverbindung bestehende Verbindungen getrennt werden. Außerdem kann ein SBC eine Überwachung der Kommunikation im Sinne der Strafverfolgung oder Gefahrenabwehr sicherstellen.
- Umgang mit Medien-Diensten
Ein SBC ist auf die Nutzung von Audio- und Video-Streams spezialisiert. Dies bedeutet, dass ein SBC umfangreiche Transcoding-Funktionen bietet und eine Umwandlung zwischen den verschiedenen Audio- und Video-Codecs übernehmen kann. Denn nicht immer unterstützten die beteiligten Endpunkte die gleichen Codecs. Dann muss eine Übersetzung der Codecs erfolgen. Darüber hinaus kann ein SBC Ansagen und Töne, beispielsweise für Music on hold, bereitstellen.
- Statistiken
Ein SBC liefert eine ganze Reihe von Statistiken. Hier sind zunächst Nutzungsstatistiken in Form von Call Detail Records zu nennen. Durch die vorliegenden Informationen zu getätigten Anrufen zum Provider können Abrechnungsinformationen erstellt und zur Weiterverarbeitung exportiert werden. Solche Abrechnungsinformationen werden zum Beispiel zur Gebührenverrechnung im Hotel- oder Krankenhausumfeld genutzt.
Zudem werden Statistiken zur Auslastung der Systeme und Leitungen durch einen SBC zur Verfügung gestellt. So kann beispielsweise Engpässen vorgebeugt und gegebenenfalls die Parameter, die für CAC genutzt werden, angepasst werden.
Insgesamt übernimmt ein SBC somit einige wichtige Aufgaben bei der Durchführung von Sprachanrufen und kann als die Firewall für den Audio- und Video-Verkehr betrachtet werden. Damit stellt sich jedoch direkt die Frage, wo ein SBC in Verbindung mit einer Firewall-Infrastruktur eingesetzt werden sollte. Hier gibt es verschiedene Varianten, die in Abbildung 8 dargestellt sind. Zu beachten ist, dass hier lediglich der SIP-Datenanschluss gezeigt wird, ein Internet- oder WAN-Anschluss ist in der Regel noch zusätzlich vorhanden. Im Folgenden wollen wir die verschiedenen Varianten genauer betrachten.
- Variante 1: kein SBC
Bei dieser Variante wird kein SBC eingesetzt. Somit muss die Firewall-Infrastruktur sämtliche Aufgaben zur Absicherung der Kommunikation übernehmen. Dies ist in einem begrenzten Umfang möglich, jedoch ist eine Firewall nicht auf den Umgang mit Audio- und Videodaten spezialisiert und kann so zum Beispiel kein Transcoding durchführen. Folglich wird diese Variante auch nicht häufig genutzt.
- Variante 2: SBC zwischen zwei Firewalls
Dies ist die klassische DMZ-Konfiguration und findet in der Praxis häufig Anwendung. Der SBC ist in einer DMZ positioniert. Sowohl zwischen Provider-Netz und DMZ als auch zwischen DMZ und internem Netz befindet sich eine Firewall. Hierbei können zwei getrennte Firewalls oder eine Firewall, die die Datenströme zweimal passieren müssen, genutzt werden. An der ersten Firewall müssen jedoch die für die SIP-Kommunikation relevanten Ports freigeschaltet werden. Diese sind für die Signalisierung zum Beispiel die Ports 5060 für SIP und 5061 für SIP over TLS. Für die Übertragung der Medienströme per RTP bzw. SRTP müssen ebenfalls entsprechende Portbereiche freigeschaltet werden.
Der Vorteil bei Variante 2 ist, dass die Sprachdaten sowohl durch einen SBC als auch durch die Firewall-Infrastruktur überprüft werden. Außerdem ist durch die Zweistufigkeit der Firewall sichergestellt, dass das interne Netz gut vom externen Provider-Netz separiert wird. Jedoch gibt es hier auch Nachteile: Das Zusammenspiel zwischen Firewall und SBC kann sehr komplex sein und hängt unter anderem vom individuellen Regelwerk innerhalb der Firewall-Infrastruktur ab. Daher erfordert die Einrichtung eine gute Planung und Harmonisierung der jeweiligen Konfigurationen. Hierfür ist eine Abstimmung mit verschiedenen Abteilungen sowie dem Provider notwendig. Darüber hinaus müssen die Firewalls ausreichend dimensioniert sein und gegebenenfalls für die Nutzung im Rahmen eines SIP-Trunks ausgebaut werden.
- Variante 3: SBC direkt am Provider-Anschluss mit anschließender Firewall
Bei dieser Variante ist der SBC direkt mit dem Provider-Anschluss verbunden. Lediglich beim Übergang zum internen Unternehmensnetz wird eine Firewall genutzt. Beim Zusammenspiel zwischen SBC und Firewall sind ähnliche Aspekte wie bei Variante 2 zu beachten. Die Konfiguration ist hier weniger komplex, da keine vorgeschaltete Firewall vorliegt. Dafür muss der SBC speziell für den Einsatz direkt am Provider-Netz gehärtet sein. Sofern der Provider eine ausreichende Trennung zwischen Sprach- und Internetverkehr gewährleistet, kann diese Variante angewendet werden. Dies ist beispielsweise bei der Nutzung eines separaten Datenanschlusses für den SIP-Trunk der Fall. Hier ist grundsätzlich ein Datenanschluss vorhanden, es werden jedoch ausschließlich Sprachdaten über diesen Anschluss übertragen.
- Variante 4: SBC ohne Firewall
Bei dieser Variante wird keine zusätzliche Firewall eingesetzt und ausschließlich der SBC zur Absicherung des internen Netzes genutzt. Dies ist neben Variante 1 eine eher unsichere Variante, da die Daten lediglich mithilfe des SBC geprüft werden. Da ein SBC zwar Sprachdaten jedoch keine allgemeinen Anwendungsdaten verarbeiten kann, können hier keine komplexen Vorgaben und Firewall-Policies umgesetzt werden. Darüber hinaus sollte für diese Variante ein separater Datenanschluss für den SIP-Trunk vorliegen.
In der Projekterfahrung der ComConsult liegen die Varianten 2 und 3 in einem Großteil der Fälle vor. Die Variante 3 wird hierbei fast ausschließlich bei eigenständigen Datenanschlüssen für den SIP-Trunk genutzt. Welche Variante für einen SIP-Trunk genutzt wird, sollte daher in enger Abstimmung mit den Vorgaben hinsichtlich Netzarchitektur und Informationssicherheit evaluiert werden.
Problemfall: Sonderanschaltungen
Neben der technischen Realisierung des SIP-Trunks und der Positionierung von Netzkomponenten im eigenen Netz bilden heute genutzte Sonderanschaltungen eine nicht zu unterschätzende Problemquelle. Insbesondere die Übertragung von Fax ist innerhalb von IP-Netzen durch die verschiedenen Protokolle, die von den Providern genutzt werden, mit Problemen verbunden (siehe [6]). Daher sollte die Übertragung von Fax-Daten gemeinsam mit dem Provider geprüft und spezifische Konfigurationen gegebenenfalls angepasst werden. Weitere Sonderanschaltungen, die jedoch oft über dedizierte Amtsanbindungen realisiert werden, sind beispielsweise Brandmeldeanlagen (BMA) oder Einbruchmeldeanlagen (EMA). Bei solchen Anschaltungen sind gegebenenfalls zusätzliche Vorgaben des jeweiligen Konzessionärs sowie von zuständigen Leitstellen zu berücksichtigen. Teilweise ist zusätzlich zur IP-basierten Anbindung ein Ersatzweg z.B. über Mobilfunk notwendig.
Grundsätzlich sollten genutzte Sonderanschaltungen im Vorfeld einer Migration analysiert und auf die Umsetzbarkeit mit einem SIP-Trunk hin überprüft werden.
Fazit
SIP-Trunks haben sich sowohl bei der Kopplung verschiedener IP-basierte Kommunikationslösungen als auch bei der Anbindung an Telefonie-Provider durchgesetzt. Mithilfe IP-basierter Anbindungen lassen sich neue Architekturen umsetzen und bisherige dezentrale Strukturen konsolidieren. Trotz weit fortgeschrittener Umstellung sind noch nicht alle Amtsanbindungen vollständig auf SIP-Trunks umgestellt, wodurch Unternehmen weiterhin vor einer solchen Umstellung stehen. Eine Migration von ISDN-basierten Amtsanschlüssen auf SIP-Trunks ist jedoch vielfach komplex, und es sind einige Aspekte zu betrachten:
- Konkrete Realisierung der Provider-Anbindung
- Zentrale oder dezentrale SIP-Trunks
- Dimensionierung des SIP-Trunks
- Positionierung eines SBC im eigenen Netz
- Bestehende Sonderanschaltungen wie Fax-Nutzung
Aufgrund der Komplexität der einzelnen Punkte ist aus Sicht der ComConsult eine solche Migration als Projekt zu betrachten und dauert 9 bis 12 Monate. Dies hängt natürlich von verschiedenen Faktoren und individuellen Gegebenheiten ab. Der Wechsel des SIP-Providers nimmt hingegen weniger Zeit in Anspruch, sollte aber ebenso mit einer guten Planung durchgeführt werden.
Verweise
[1] https://www.rfc-editor.org/rfc/rfc4119
[2] https://www.rfc-editor.org/rfc/rfc3863.html
[3] https://www.rfc-editor.org/rfc/rfc5139
[4] https://www.rfc-editor.org/rfc/rfc5491
[5] https://www.comconsult.com/vom-sinn-und-unsinn-der-sip-trunk-verschluesselung/
[6] https://www.comconsult.com/fax-was-war-was-ist-was-kommt/