Ribon/Sonus/NET UX1000/UX2000

Es hat einige Zeit gedauert, bis ich neben Audiocodes, Ferrari OfficeMaster und Dialogic DIVA SIP Gateway auch mal ein NET-Gateway konfigurieren konnte. Diese Seite ist ein erster  Bericht über diese Gateways. Er ist sicher nicht so ausführlich wie meine Audiocodes Seiten, die ich für gewöhnlich einsetze, aber meine ersten Eindrücke und Erfahrungen möchte ich hier protokollieren.

Die Firma Sonus hat die Firma NET aufgekauft und danach wurde Sonus von Ribbon gekauft. Ich habe aktuell keine aktive Installation mit diesen Gateway und habe die Seite daher nicht weiter aktualisiert.

UX1000 und UX2000

Ich kann nur von den beiden Geräten UX1000 und UX2000 berichten. Beide sind universelle Gateways, die über ein ASM-Einschub (PC auf Steckkarte) auch zur SBA aufgerüstet werden können, die gleiche Administrationsoberfläche per Browser anbieten und nicht nur als IP/PSTN-Gateway sondern auch als SBC agieren können.

Produktname Ausbaustufe

SBC1000
http://www.sonus.net/en/products/session-border-controllers/sbc-1000-up-to-160-sip-sessions

  • Bis zu 160 gleichzeitige SIP Verbindungen
  • 1-2 E1/T1 Ports
  • Bis zu 24 analoge Anschlüsse
  • Bis zu 8 BRI möglich
  • Bis zu 2x Gigabit
  • Optional Application Server Module (ASM) z.B. für SBA
    (Intel Atom, 2GB RAM, 160GB Disk)

NET UX1000 Video Overview
http://www.youtube.com/watch?v=_-27XANlGE8

SBC2000
http://www.sonus.net/en/products/session-border-controllers/sbc-2000-up-to-600-sip-sessions

  • bis zu 8 T1/E1 Module
  • bis zu 4x Gigabit
  • Optional Application Server Module ASM z.B. für SBA
    (Core i7, 4GB Ram, 160 GB Disk)

UX2000 Video Datasheet
http://www.youtube.com/watch?v=dZgonp2w9c4

Diese Seite kann keine komplette Beschreibung der Lync Installation eines NET-Gateways sein, sondern soll ein paar Informationen liefern, die mir beim Einsatz dieser Gateways aufgefallen sind.

Initiales Setup

Das NET-Gateway hat Anfangs eine feste IP-Adresse und muss eine initiale Konfiguration durchlaufen, ehe es an das Hauslan angeschlossen werden sollen. Es wird ein PC benötigt, der an den UX angeschlossen wird

  • UX1000
    Per Hub oder Kreuzkabel am EthernetPort1
  • UX2000
    Per Hub oder Kreuzkabel am AdminPort

Konfiguration erfolgt per https://192.168.128.2 und sie sollten folgende grundlegenden Einstellungen vornehmen, ehe Sie das Gateway dann an das Hauslan anschließen.

Parameter Wert

Hostname

 

DNS-Domain

 

IP-Adresse, Subnetz, Default Gateway

 

DNS-Server

 

Admin-Kennwort

 

Danach kann das Gateway neu gestartet und in das Haus-LAN angeschlossen werden.

Nach dem Anschluss an das Netzwerk und TDM sind die entsprechenden Parameter einzurichten, z.B.:

  • Trunks
    Wenn das NET-Gateway per ISDN kommuniziert, müssen Sie die eingebauten Trunks entsprechend konfigurieren. Mal abgesehen, dass in Europa fast immer EuroISDN zum Einsatz kommt, sind die weiteren Parameter an den Anschluss anzupassen.
  • Monitoring
    Die NET-Gateways erlauben wie Audiocodes die Konfiguration von Syslog-Servern. Allerdings kann NET mehrere Syslog-Server angeben, zu denen individuell ein Debug-Level zu hinterlegen ist. Um ein Gateway sinnvoll zu überwachen sollten Sie auf einem Server einen Syslog-Daemon laufen lassen (z.B. die Kiwi Freeware) und so alle Vorgänge zu protokollieren.

    Zusätzlich können für verschiedene Subsysteme abweichende Debug-Level pro Syslog-Server hinterlegt werden. Diese Funktion ist leistungsfähiger als bei Audioodes.

Lync Assistent

Eine Besonderheit von NET, die ich bei anderen Gateways noch nichts gesehen haben ist der Assistent für Lync und OCS. Im Assistenten haben Sie die Auswahl zwischen einer SIP-Anbindung, bei der das Gateway als SBC arbeitet oder eine PBX-Anbindung. Der Assistent konfiguriert viele Einstellungen für Lync wie z.B. Encryption etc., die ansonsten mühsam von Hand eingerichtet werden müssten. Der Assistent unterstützt bei Anbindungen per PSTN als auch bei SIP-Trunks.

  • Einrichtung eines PSTN-Links
    Sie sehen hier als wesentliche Parameter den Lync Mediation Server und die ISDN-Ports.

    Hinweis: Als PBX-Prefix muss die Ortsnetzkennzahl + Trunk hinterlegt werden. für Net at Work in Paderborn wäre das dann 52521304 und nicht nur 304
  • Einrichtung als SBC
    Wenn die Anbindung per SIP-Trunk erfolgt, sieht das Fenster wie folgt aus.

Die Ergebnisse sind durchaus durchwachsen. So enthalten die Transformationsregeln aus meiner Sicht unpassende Einträge. Der das richtige PBX-Prefix eingetragen hat, erreicht zumindest eine halbwegs korrekte eingehende Normalisierung der Called Number". Die rufender Nummer ist so aber nicht korrekt normalisiert

Als rufende Nummer kommt sicher keine dreistellige Durchwahl von der Telekom und auf Besonderheiten von NPI und TON geht der Assistent gar nicht ein. Auch ausgehend passen die Tabelle nicht, wie Sie hier sehen:

Die Regeln könnten ausreichen, um ein NET hinter einer PBX einzurichten und dann intern zu telefonieren. Ins Amt aber geht es nicht raus.

Trotzdem ist der Assistent hilfreich, weil es leichter ist, eine bestehende Konfiguration zu erweitern als alle Einstellungen (z.B. auch Codec, Encryption etc.) manuell von vorne aufzubauen. Der Assistent macht aber nur den Anfang.

Der Assistenz erfragt einen Szenario-Namen, der bei allein neu angelegten Objekten als Präfix vorangestellt wird und so immer wieder zu erkennen sind.

Routing und Transformation

Sie haben schon im Abschnitt zum Assistenten gesehen, dass die Normalisierung noch anzupassen ist. Es gehört zur den natürlichsten Aufgaben eines Gateways Verbindungen zu routen und die Rufnummern entsprechend umzusetzen. Audiocodes trennt Routing und Normalisierung. NET hingegen verbindet diese beiden Funktionen derart, dass ein Verbindungsaufbau über die Signaling Group zuerst durch die „Transformation“ geht, bis ein Regelwerk „matched“

  • Signaling Group
    Über diese Konfiguration wird erkannt, woher der Call kommt und welche Routingtabelle zum Einsatz kommt:

    Weiter unten in der Konfiguration wird der Listenport und die RemoteIP (FederationIP) spezifiziert- Diese Konfiguration funktioniert als ähnlich wie ein Exchange Receive Connector.
  • Call Routing Table
    Die Call Routing Table verbinden definierte Einstellungen und können mehrere Zeilen enthalten, von denen jede mit genau einem Eintrag aus der Translationtabelle verknüpft ist.

    Die UX läuft also die Call Routing Table sequentiell ab und führt die verknüpfte „Transformation“. Wenn die Transformation „matched“, dann wird dieser Eintrag für das Routing genutzt.
  • Translation Table
    Die Tabelle selbst dienst nur als Ablage der verschiedenen Normalisierungsvarianten und wird von der Call Routing Table referenziert. Ist damit nicht mit dem Audiocodes.

Durch diese Kombination ist es möglich, abhängig von der Quelle über die Translation entsprechende Ziele zu steuern. Das ist natürlich eine sehr reduzierte Beschreibung ohne auf Message Translation, Cause Route Rerouting, Medialisten etc. einzugehen.

Transformation Besonderheit

Auch denn die Transformation-Tabelle nur referenziert wird, ist sie eine Schlüsselkomponente. für einen Audiocodes-Admin ist so eine Eintrag mit vielen Zeilen nur eine einzige Zeile im Audiocodes. Es sind eben unterschiedliche Konzepte. NET verknüpft die Transformation als "Bedingungen" für die Route die zugleich dann auch normalisiert. In der Dokumentation von NET steht dazu:


Quelle: Optional Matching Overview
https://support.sonus.net/display/UXDOC/Optional+Matching+Overview

Da stimmt so aber nicht. Laut Trace wird aber jede optionale Rule, die “matched” durchgegangen wird und wenn eine Regel ein Feld verändert, dann sieht die folgende Regel das geänderte Feld als „Input“. Hier ein Beispiel:

Schaut man sich einen Ruf von meinem Mobiltelefon auf die Durchwahl 613 dann an, dann findet man aber folgendes:

Die 4. Regel "matched" um die rufender Nummer umzuschreiben aber die 5. Regel würde normal auch "matchen" aber da die Regel 4 den Wert von "Calling Address/Number" umdreht, (das "+49" addiert) kann die Regel 5 nicht matchen. Aber die Aussage "Last to be matched" ist natürlich so nicht offensichtlich. Es werden alle Verarbeitet.

Transformation und Testcall

NET erlaubt über die GUI einen „Testanruf“ zu starten.

Leider kann man hier keine „Calling Number“ angeben. Wer also eine „Mandantory“ Transformation Regel hat, die die rufende Nummer aus E164 umsetzt, dann schlägt der Call immer fehl.

Wenn das UX ein ASM-Modul enthält und damit eine SBA installiert ist, gibt es auch einen „Lync Testcall“.

Hier kann man zumindest eine SIP-Adresse vorgeben, die dann umgesetzt werden sollte.

Media Bypass, Codec und Encryption

Interessant bei "qualifizierten Gateways" die Funktion MediaBypass. Dies gilt um so mehr, wenn die Media Encryption in Lync auf "Require Encryption" steht. Der Assistent bei der Ersteinrichtung liefert hier schon die ersten Einstellungen mit. Allerdings setzt er „Operation Option“ auf „Required. Das ist i.O. wenn auch Lync auf RequireEncryption und alle anderen Endpunkte auch Encryption verstehen.

Dies ist also eventuell anzupassen. Das Crypto-Einstellung ist in der Media-List referenziert.

Status

Direkt auf der Startseite gibt es auch eine schicke Statusübersicht, die alle Module und ihren Status anzeigt.

Natürlich lässt sich das Gateway auch per SNMP auslesen.

Debugging mit "Log Exchange (LX)"

Ansatzpunkt bei der Fehlersuche ist natürlich der gemeldete Fehler. Oft kommt man damit aber weiter und dann ist der SYSLOG die passende Quelle. für eine „AdHoc“-Analyse eignet sich das kostenfreie Programm Log Exchange (LX) von NET. Es enthält einen SyslogD und bereitet die Ausgaben optisch besser aus.

LX kann auch SYSLOG-Dateien bestehender SyslogD nutzen. Wer seine Syslogs z.B.: mit „Kiwi Syslog Daemon“ sammelt, sollte dort das Format umstellen, dass der SyslogD einfach nur die Meldungen schreibt und nicht selbst noch einen Zeitstempel und den Host addiert. Das sieht dann so aus.

Hier ist das Log File Format auf „Message Text only“ zu stellen.

Hinweis:
Das Programm LX liest die Datei aber schreibt leider im gleichen Verzeichnis ein „Convert“-File. Ohne Schreibrechte dort funktioniert das Einlesen in LX nicht.

SBA im Gateway

Gerade für den Einsatz in Niederlassungen ist natürlich die SBA-Funktion interessant. Bei einem UX1000 ist das kleiner Slot-PC mit AtomCPU, 2GB RAM und 160 GB Festplatte.

Leider reicht es bei solchen „Einbau-PCs“ in der Regel nicht mehr für eine RAID und auch wenn man per RDP auf den Server kommt, so sollten Sie zweimal überlegen, ob Sie mit Notepad eine mehrere MB-große Syslog-Datei öffnen.

Mit der SBA kommt ein weiterer StatusBildschirm mit, der zumindest die Versionen und einen einfachen Status anzeigt.

Sonus und PowerShell

Der Hersteller selbst hat bislang keine Unterstützung per PowerShell bereit gestellt aber die SONUS-Gateway stellen zumindest eine REST-API bereit und daher hat Vik Jaswal ein PowerShell-Modul dazu entwickelt, um die Sonus-Gateway per PowerShell auszulesen und ggfls. sogar zu ändern.

Weitere Links