Audiocodes SBC

Die Anzahl der Lync Installationen mit Telefonie-Funktion nimmt zu. Aber immer häufiger werden diese Installationen gar nicht mehr per ISDN (S0 oder S2M) an eine Telefonanlage oder zum Amt verbunden, sondern auch Firmen können heute per SIP-Trunk angeschlossen werden. Im Bereich der Privatanschlüsse vermarkten die Telekom und andere schon länger "IP-Anschlüsse". Technisch sind das auch nur DSL-Anschlüsse mit einem DSL-Moden, welches auch ein paar ab-Anschlüsse für eine Telefon hat. Die Sprache ist damit schon auf IP und schneller und vor allem günstiger weiter zu leiten als mit einer ISDN-Vermittlungsstelle.

VoIP als Trunk

Für Firmen gilt das auch aber hier kommen natürlich andere WAN-Verbindungen zum Einsatz, damit die Qualität auch garantiert werden kann. Aber beim SIP-Trunk müssen Sie natürlich auch den Audio-Datenstrom (RTP) beachten. Wenn Sie ohne MediaBypass in Lync arbeiten, dann gehen externe Gespräche über den Mediation Server und von dort weiter. Dies ist ratsam, wenn der Lync Server dirkt per SIP mit ihrem Provider spricht und damit nur die IP-Adresse des Lync Mediation-Server mit der Gegenstelle kommuniziert. Wenn ihr Lync Server aber intern steht und sie an der Grenze zum externen Netzwerk eine VoIP-Firewall haben wollen oder aufgrund von privaten IP-Adressen haben müssen, dann ist ein Session Border Controller erforderlich, der zumindest die IP-Endpunkte und gegebenenfalls noch den Codec der Audio-Verbindungen umsetzt. Je nach Provider muss der SBC aber auch die SIP-Pakete umbauen, z.B. weil die Empfänger und Absenderadressen umgesetzt werden müssen oder bestimmte SIP-Funktionen übersetzt werden müssen, z.B. Session Timeout und uPDATE-Handling.

Mediant 1000 MSBG als IP-Gateway

Wenn Sie den Mediant MSBG einsetzen, dann müssen Sie sich überlegen, welche der Betriebsarten Sie für die IP zu IP-Verbindung nutzen wollen.

Neben dem SBC-Bereich gib es auch immer noch den schon länger vorhandenen "GW and IP to IP" bereich

  • SBC
    Der klassische Betrieb als Session Border Controller benötigt eine entsprechende Lizenz aber ist nach heutigen Maßstäben die beste und flexibelste Lösung. Wann immer Sie zwei SIP-Trunks verbinden wollen, sollten Sie den SBC-Weg gehen. Entsprechende Lizenzen für die Anzahl gleichzeitiger Verbindungen sind zu erwerben.
  • IP zu IP Gateway
    Parallel gibt es die Funktion "IP zu IP-Gateway". Auch hierzu benötigen Sie eine Lizenz. Transcoding geht über DSPs. Media wird also beim Gateway neu aufgesetzt aber die SIP-Session wird durchgereicht. Es ist also kein "Ende zu Ende-Proxy" für die Signalisierung.
  • IP via TK zu IP
    In der Anfangszeit, als es noch keine SBC-Funktion gab und man vielleicht keine "IP to IP"-Lizenz hatte, konnte man mit entsprechenden Komponenten aber auch eine Lösung über ISDN-Kanäle bauen. Wer also z.B. einem 4xBRI-Karte eingebaut hat, konnte z.B. über Port 1 und 2 sich selbst auf Port 3 und 4 anrufen und so bis zu 4 "Telefonate" vermitteln. Das war ein Trick um z.B. einen SIP-Trunk zu testen oder wenige interne Geräte per IP anzubinden.

Relevant für die weitere Betrachtung sind aber nur die SBC und "IP zu IP"-Betriebsart. Wobei der Mediant gar nicht zwischen beiden Betriebsarten wechseln muss, sondern beide auch parallel genutzt werden können. Die Funktionen müssen einfach nur aktiviert werden

Vorarbeiten: IP-Group, Coder-Group, SRD und Co

Ehe Sie sich auf die Konfiguration von Interface, "Routing" und "Normalisierung" stürzen, sollten Sie ein paar Dinge vorab klären. Ein SBC wird vielleicht für die Verbindung von genau zwei Systemen per IP verwendet, aber dennoch werden nicht alle Parameter dann an einer Stelle eingetragen, sondern vorab als " Template" erzeugt und dann nur verknüpft. Das erleichtert immens die Konfiguration, wenn z.B. mehrere SIP-Trunks die gleiche Coder-Konfiguration nutzen oder sie statt einer Gegenstelle eine Gruppen von Gegenstellen bedienen wollen. Daher sollten Sie vorher folgende Einstellungen definieren.:

  • Proxy Set
    Mehrere Proxy-Server (z.B. die verschiedenen Mediation Server in einem Lync Pool) sollten in einem ProxySet zusammen gefasst werden. Das ProxySet 0 ist das "Default Proxy Set" und sollte nicht genutzt werden. Schon hier sollten sie auch ein SRD hinterlegen, der später verwendet wird. Idealerweise pflegt man alle IP-Partner über ProxySets und weist jedem Proxy Set auch eine eigene SRD zu.
  • IP-Group
    Nun erstellen wir analog eine IP-Group, die auf das ProxySet und den SRD verweist. Diese werden später beim Routing benötigt
  • SRD (Signaling Routing Domain)
    Nun aktualisieren wir die SRD-Tabelle, indem wir zu den bereits vergebenen Nummern entsprechend sprechende Namen definieren.

    In der "IP Group Status Table" sollte schon das ProxySet erscheinen.
  • Coders
    Die meisten SIP-Trunks werden mit G711 als Codec konfiguriert, weil dies immer noch der Standard-Codec aus der ISDN-Welt ist und dann der Carrier keine DSPs für die Transcodierung einsetzen muss. Sie können aber einen SBC auch nutzen, um die Codierung zu ändern. Bei Lync ist dies aber nur erforderlich, wenn der SIP-Trunk gerade nicht G711 spricht. Der Lync Mediation Server aber auch ein Lync Client mit MediaBypass nutzen G.711. Die verwendeten bzw. angebotenen Coder werden in einer Gruppen zusammen gefasst und später in der Konfiguration verwendet.

    Die Liste hier ist nicht repräsentativ. Sie sollten nur die Coder anbieten, die Sie auch annehmen wollten.
  • IP Profile ID
    Wenn Sie schon im Bereich der Coders sind, können Sie auch gleich die "IP Profile" angeben. Auch hier bietet sich eine 1:1 Zuordnung der Nummern an. Die Parameter umfassen Einstellungen zu DiffServ, Fax Signalisierung, DTMF, Media Security und ganz viele SBC Einstellungen

Tabellen und deren Verwendung

Da ich selbst auch immer wieder nachschlagen muss, an welcher Stelle welche Tabellen zum Einsatz kommen, habe ich basierend auf einem Audiocodes Mediant 1000 MSBG (Firmware 6.80) erfasst, wo welche Werte verwendet werden. Nur drei der Tabellen stehen wirklich "eigenständig"

 

Schon die nächsten Tabellen verweisen auf diese drei Basistabellen und die "IP Group" ist auch untereinander verknüft:

Diesen sechs farblich gekennzeichneten Tabellen werden in der weiteren Konfiguration immer wieder referenziert:

 

Si können Sie sehen, an welchen Stellen ein Eintrag zu finden ist, der referenziert. Wer also ein SBC-Routing anlegen will, muss vorher die entsprechenden "IP-Group Table" gepflegt haben, um auf diese Einträge zu verweisen.

Interface-Definition

Damit ein Mediant SIP-Verbindungen annahmen kann, muss man entsprechende "Listener" einrichten. Hier ist es wichtig für die SBC und "IP to IP"-Applikation unterschiedliche Adressen oder zumindest Ports zu nutzen, damit die Zugänge unterschieden werden können.

  • VoIP - Network-IP Settings
    Hierüber wird die Netzwerkkarte konfiguriert (IP-Adresse etc)

    Weiter hinten in dieser Zeile steht der "Interface Name". Der wird später bei der SBC-Definition noch einmal benötigt.
  • Generelle Konfiguration
    Basierend auf den IP-Adressen der Netzwerkkonfiguration kommen beim "IP zu IP"-Gateway die Ports zum tragen, welche unter "General Parameter" hinterlegt werden

    Dieser Dialog ist aber wohl eher noch eine "Altlast" der früheren Versionen, in denen es z.B. kein "IP2 to IP" oder "SBC" gab. (also ein alter Mediant 1000 ohne das "MSBG"-Kürzel
  • SIP-Schnittstellen (Nur in der "Advanced Ansicht" sichtbar
    Wichtiger ist hier die Definition der Schnittstellen unter "VoIP - Control Network - SIP Interface Table". Hier ein Beispiel.

    Hinweis: Sie können hier problemlos auch eine Schnittstelle für ein Gateway definieren, selbst wenn die Funktion nicht aktiv ist oder sie keine Lizenz dafür haben.

Media Realm

Nach der Konfiguration der Netzwerkschnittstellen kann die Definition von "Media Realm" sinnvoll sein, um weitere Parameter bezüglich der Gegenstelle festzulegen, z.B. die Portrange für Audio.

Routung und Normalisierung

Sobald die Verbindungen per IP-Adressen definiert und eingehende Verbindungen über entsprechende Listener konfiguriert sind, kann mit der Konfiguration des Routings und der entsprechenden Normalisierung von Einträgen begonnen werden.

Beim normalen Gateway mit Trunk-Beteiligung sollten Sie zuerst definieren, ob sie Vor oder nach der Normalisierung dann Routen. Ich rate immer dazu eingehend zuerst zu normalisieren, damit man möglichst früh mit E.164 Nummern arbeiten kann

 

Ausgehend kann man dann nach dem Routing normalisieren, weil dann da Gateway das Ziel schon bestimmt hat und sie dann die Nummer passend zu dem Ziel verändern können.

Beim SBC hingegen arbeitet der Audiocodes etwas anders. Es gibt hier ja nur "IP zu IP" Verbindungen. Im Bereich "Manipulation" gib es aber immer zwei Bereiche.

Der Begriff "Inbound" und "Outbound" bedeutet nichts anderes, also dass "Inbound" vor dem Routing erfolgt und "Outbound" nach dem Routing

Beim Routing werden dann wieder die entsprechenden Entscheidungen anhand von Informationen aus der Quell, der Rufnummer etc. konfiguriert, die das nächste Ziel angeben

 

Auch hier sehen Sie, dass die anfangs definierten Elemente (IP Group, SRD etc.) immer wieder zum Einsatz kommen. Eine solcher Struktur hat den Vorteil, dass bei geeigneter Planung spätere Änderungen immer nur an einer Stelle durchgeführt werden müssen und sich dann z.B. auf alle Routing-Regeln für das gleichen Ziel oder Quelle auswirken.

SBC mit FXS-Anschlüssen

Wer einen Mediant als SBC einsetzt aber dennoch auch noch ISDN-Port oder analoge Ports betreibt, wird sich vielleicht fragen, wie das denn nun zu konfigurieren ist. Schließlich gibt es beim SBC einen Bereich zu Normalisierung und Routing und beim eigentlichen "Gateway" eben auch. Der Trick ist ganz einfach: So ein Gerät sind eigentlich zwei Geräte kombiniert und das IP<->TK-Gateway kommuniziert auf einer Seite per IP mit Gegenstellen und auf der anderen Seite mit den Telefonanschlüssen und der SBC macht das gleiche auf anderen IP:Port-Kombinationen.

Wichtig ist hier, dass das Gateway einen anderen SIP-Port bekommt als die SBC-Interfaces.

Wenn nun ein Anruf per SIP-Trunk beim SBC ankommt, aber z.B. an einem analogen Port rauskommen soll, dann muss der SBC auf der anderen Seite eben per IP über "127.0.0.1" mit dem TK-Gateway sprechen. Der Call läuft so gesehen also zweimal durch die Routing und Normalisierungen. Ausgehend ist es das gleiche Prinzip: Ein analoges Fax sendet einen Anruf ab, der vom Gateway per IP zum SBC geroutet wird, der seinerseits dann per IP z.B. über einen SIP-Trunk zum Carrier weiter geht.

Weitere Links