SBC - Session Border Controller (B2BUA)

Die Zunahme der SIP-Trunks und direkte Verbindungen zwischen VoIP-Systemen macht den Einsatz von so genannten Session Border Controllern erforderlich. Sie sind im wesentlichen Vergleichbar mit einem klassischen PSTN Gateways, welche aus der einen Seite mit Lync und den Client per SIP kommuniziert und per RTP/SRTP die Audiodaten überträgt und auf der externen Seite die Daten über z.B. ISDN-Leitungen sendet und empfängt. Es kümmert sich dabei auch im die Umsetzung von Adressen und Rufnummern.

Ein SBC macht eigentlich das gleiche, nur dass auf der externen Seite eben keine analogen oder digitalen Leitungen sind, sondern ebenfalls SIP gesprochen wird. Oft sind Gateways für PSTN-Anbindungen auch als SBC einsetzbar.

Die Hauptfunktionen eine SBC sind:

  • Umsetzung verschiedener SIP-Dialekte und Befehle
    Lync arbeitet z.B. mit Zertifikaten zur Identifizierung aber unterstützt z.B. keine Anmeldung mit Username/Kennwort bei einem SIP-Trunk-Anbieter.
  • RTP-Bridging und ReCODING
    Kaum jemand wird sein internes LAN zum SIP-Provider öffnen bzw. kann dies aufgrund von NAT und Routing auch gar nicht. Dann muss der SBC die Daten als Relay weiterleiten und gegebenenfalls sogar umcodieren, damit der extern verwendete Codec auf den internen Codec der Clients umgesetzt wird.
  • Applikations-"Firewall"
    Klassische Firewall sehen bei SIP/TLS nur noch SSL-Handshakes und bei SRTP auch nicht mehr genau, ob in dem kontinuierlichen Datenstrom wirklich "nur" Audio/Video übertragen wird oder vielleicht doch geheime Daten.

Dazu haben sie meistens zwei oder noch mehr LAN-Ports. Teilweise ist ein Port sogar WAN-Fähig und unterstützt PPoE oder andere spezielle WAN-Funktionen.

SBC im Verbund

Deutlicher wird dies, wenn man eine SBC einfach im "Verbund" darstellt. Hier mal ein Beispiel eines grünen Firmennetzwerks, in dem alle Clients miteinander direkt kommunizieren können, wie dies bei VoIP die Regel ist. Der zentrale Registrar ist ja nur für die SIP-Steuernachrichten relevant während Audio-Daten einer 1:1 Verbindung bevorzugt direkt übermittelt werden. Nun nehmen wir an, dass es kein Gateway zum TK-Netzwerk gibt, welches die RTP/SRTP-Datenströme auf ISDN umsetzt (siehe auch MediaBypass), sondern die Anbindung zum nächsten System ist ebenfalls SIP. Das kann ein SIP Trunk zu einer TK-Anlage sein oder direkt zu einem Provider über eine qualifizierte WAN-Verbindung.

Die Aufgabe eines Session Border Controller ist zum einen die Umsetzung der SIP-Signalisierung, z.B. auch mit Anpassen der Rufnummern, SDP-Einträgen, Header im SIP-Paket und zum anderen die Umsetzung der Audiodaten.

Die Umsetzung ist aus mehreren Aspekten wichtig:

  • SIP-Übersetzung
    SIP ist zwar durch RFCs standardisiert aber wie überall gibt es "Dialekte". Lync unterstützt z.B. nur SIP/TCP oder SIP/TLS und erwartet eine Antwort auf regelmäßige SIP Options-Anfragen oder eine schnelle (<1,5Sek) "100 Trying" Antwort auf einen "INVITE", damit Lync den Call nicht zurück zieht und einen alternativen Weg sucht. Auch könnte es sein, das die Rufnummern zwischen den System angepasst werden müssen. So konnte Cisco lange Zeit nicht mit dem "+" einer E164-Adresse umgehen. Und einige Firmen möchten z.B. die "VIA-Header" im SIP-Paket ähnlich einer Header-Firewall bei SMTP entfernen, um der anderen Seite nicht zu viel über die interne Struktur zu verraten.
  • IP-Erreichbarkeit für RTP
    In der Regel ist das TK-System im roten Providernetzwerk nicht direkt von den Clients im Kundennetzwerk erreichbar. Meist ist es schon einfach das IP-Routing, welches dies nicht erlaubt und natürlich werden sichere unternehmen mit Firewalls schon dafür sorgen, dass Client nicht über Portranges aus fremden Subnetzen erreicht werden können. Ein SBC muss also die beiden RTP-Ströme verbinden.
  • Codec-Umsetzung
    Ein zweiter Punkt ist die Umsetzung der Codecs. Klassischer Voice-Codec ist G711 (Siehe .Codec) während Lync intern natürlich mit RTAudio arbeitet. Es gibt noch weitere Codecs und der SBC kann die Daten auch entsprechend umcodieren, wenn dies z.B. erforderlich ist.

Die Aufgaben einer SBC sind also durchaus vielfältig und speziell wenn RTP nicht nur 1:1 durch geleitet sondern sogar noch umcodiert werden muss, werden auch Laufzeiten, Latenz, Bandbreiten, QoS etc. ein Thema.

SBC und Media Bypass

Auf der Seite MediaBypass habe ich schon die technischen Details zum Bypass von Medien geschrieben. Es sollte immer ihre Ziel sein so wenig wie möglich Zwischenstationen zwischen den Endpunkten zu betreiben. Relays sind nur dann erforderlich, wenn Sie aufgrund inkompatibler Codec eine Transcodierung durchführen müssen, eine Netzwerktrennung eine direkte Verbindung der Clients verbaut oder Sie bei der SIP-Signalisierung etwas umschreiben müssen.

Im folgenden Beispiel zeige ich eine Anbindung von Lync an eine TK-Anlagen über einen SBC und die verschiedenen Stellen von Media Bypass mit einem SBC. Beachten Sie, dass der Lync Frontend nicht "in der Linie" steht, er dient lediglich der Signalisierung in der Lync-Umgebung.

  1. Szenario 1
    Hier gibt es kein Media Bypass. Der Lync Client sendet die Audio-Daten per RTAUDIO zum Lync Mediation Server, der diese nach G711 umwandelt und zum "Next Hop" sendet. Das ist der SBC, der ebenfalls die Mediendaten terminiert und auf der anderen Seite eine neue SIP-Session mit neuen Kandidaten aufbaut. Die TK-Anlage baut dann eine Verbindung zum Telefon auf. Das kann natürlich eine ISDN, analoge oder proprietäre Schnittstelle sein. Es kann aber auch ein IP-Telefon sein.
  2. Szenario 2
    Wenn innerhalb von Lync "Media Bypass" auf dem Trunk aktiviert wird, dann umgehen Sie damit den Mediation Server. Der Lync Client senden dann selbst G.711-codierte Audiodaten zum Gateway, also hier dem SBC, der die Daten dann weiter gibt. Dieser Weg ist immer noch oft, wenn die TK-Netzwerke und "PC-Netzwerk" nicht per Routing verbunden sind und der SBC daher als Medianbrücke agieren muss. Dies ist auch bei einem SIP-Trunk zu einem Carrier der Normalfall. Sie werden sicher nicht alle Clients mit den privaten Adressen per IP-Routing zum Gateway des Carriers verbinden.
  3. Szenario 3
    Nehmen wir an, dass die IP-Anbindung der TK-Anlage mit dem SDP-Daten von Lync umgehen kann, dann könnte der SBC ebenfalls in Bezug auf Medien umgangen werden. Er würde zwar noch Signalisierung durchreichen und umsetzen aber die SDP-Payload unverändert weitergeben. Der Lync Client würde dann direkt mit der TK-Stelle die Audiodaten z.B. per G.711 übertragen.
  4. Szenario 4
    Hier sind dann die TK-Anlage und deren IP-Telefone gefragt, ob Sie mit den SDP-Daten (Codec, Encryption etc.) kompatibel sind und es eine passende Netzwerkverbindung gibt. Im Idealfall senden sich Lync Client und TK-Client direkt die RTP-Daten. Das geht z.B. mit Cisco, wobei dann oft schon gar kein SBC mehr benötigt wird und die andere VoIP-Anlage direkt für Lync zertifiziert ist.

Ich habe bei den Szenarien nun immer von Links nach Rechts den Bypass erweitert. Natürlich kann jede Zwischenstation individuell per Bypass umgangen werden, wenn die beiden benachbarten Stationen direkt miteinander kommunizieren können.

Produkte

Es gibt verschiedene Hersteller und Lösungen, um eine SBC aufzusetzen. So gibt es reine Softwarelösungen die auf Unix oder Windows installiert werden. Zum Teil können diese auch virtuell laufen, wobei Sie damit Hardware sparen und die Verfügbarkeit durch Nutzung der Virtualisierung erhöhen können. Beachten Sie aber, dass gerade VoIP besondere Anforderungen an Latenzzeiten stellt. für kleinere Callvolumen kann eine kleine virtuelle Box schon ausreichend sein. für größere Volumen oder wenn auch eine richtige Netztrennung erforderlich ist, kann ein Device seine Vorteile ausspielen.

Schauen wir uns einfach mal ein paar Produkte (und Kosten) an. (Basierend auf vom Hersteller genannten Listenpreisen April 2013). Die Auswahl darf nicht als Empfehlung verstanden werden. Nutzen Sie die Microsoft Zertifizierungsliste.

Hersteller Produkt Einzelkomponenten

Microsoft

Auch der Lync Mediation Server ist ein SBC, der zwischen den Lync Clients intern und über den zweiten Pfad zum Gateway die Verbindung herstellt. Wenn sie MediaBypass abschalten, dann wird auch RTP durch den Mediation Server geroutet und zwei Netzwerkkarten sind für einen Windows Server auch kein Problem.

Nur mit "Lync Zertifizierten Gegenstellen" nutzbar

Hardware: Windows Server (Physik/VM)
Software: Kostenfrei

Audiocodes

Mediant 1000 mit entsprechenden EBSG-Lizenzen

Mediant 1000 (1265€ ) zzgl.
Lizenz: 1697€ (30 Sessions)

Mediant 500 (incl 5 SBC Sessions, ca. 725€

+5 SBC Sessions 344€

TE-Systems

anynode
SoftwareLösung für Windows oder Unix, kann auch virtuell betrieben werden.

Hardware: Windows Server (Physik/VM)

Software: 2500€

Ferrari Electronic

Office Master Gate mit SIP2SIP Lizenz. Sie haben die Wahl, ob sie ein echtes physikalisches Gateway oder das virtuelle Gateway mit der entsprechenden Lizenz einsetzen.

SIP2SIP: 250€ (pro 2 Kanäle)

Virtuelles Gateway (ca. 850€)

Gateway-Karte (ca. 1200€) zzgl. PC

Komplett Server mit Karte (ca. 2180€)

Sonus

Auch die Gateways von Sonus (Ehemals NET) können mit der passenden Lizenz als SBC eingesetzt werden.

Keine Preise

ACME Packet

Wohl schon länger ein "Platzhirsch" für SBC, aber hatte ich noch nie im Projekt. Wurden im Feb 2013 von Oracle gekauft.

Keine Preise

Dialogic

Border Net Controller (Aktuell wohl nicht Lync/Exchange qualified)
http://www.dialogic.com/en/products/session-border-controllers.aspx

Keine Preise

Hinweis zu Kosten
Ich habe absichtlich keine "Summe" oder einen "Vergleich" aufgeführt, da die Produkte nicht allein am Preis zu vergleichen sind. Ich kann nicht für Sie einschätzen, welche Einkaufspreise sie haben, wie viele "Kosten" sie für virtuelle oder eigene Hardware Server und Betriebssystemlizenzen ansetzen und wie sie ihre Betriebskosten berechnen.
Zudem unterscheiden sich die interne Umsetzung und Funktionsumfang erheblich.

Bei der Kalkulation werden sehr oft die Kosten für den Betrieb der Lösung vergessen. Bei einer Hardwarebox gibt es eher selten „SicherheitsUpdates“ und das Backup ist meist eine einzelne Konfigurationsdatei, die gesichert wird. Bei einer Softwarelösung hingegen müssen Sie z.B. Windows immer mal wieder wegen Updates neu starten. Das kenne ich z.B. von einem Gateway (Ferrari, Audiocodes etc.) nicht. Die laufen teils Monate ohne Unterbrechung.

Weitere Links