Audiocodes Mediant 1000

Wir haben schon komplette Telefonanlagen mit dem OCS und einem Mediant 1000 abgelöst. Ich bin aber kein "Spezialist", der jede Konfiguration aus dem ärmel schütteln kann. Die Machbarkeit einer individuellen Konfiguration ist daher im Einzelfall zu prüfen. Sprechen Sie uns einfach an

Achtung: Mediant 1000 MSBG
Das System hat in der Werksauslieferung nicht mehr die IP-Adresse 10.1.10.10 sondern 192.168.0.1 und verteilt per DHCP die Adressen 192.168.0.3-192.168.0.8. Daher unbedingt in einem separaten Netz erstmalig konfigurieren.

Achtung
Beachten Sie zur ersten Einrichtung die Seite Audiocodes Basissetup

Als Media Gateway vermitteln Sie zwischen der klassischen TDM-Welt auf der einen Seite und der VoIP-Welt über Ethernet. Je nach Ausbau können die Systeme aber auch selbst "Mittelpunkt" einer Vermittlung sein, d.h. auch selbst wieder z.B. ISDN-Unteranlage über VoIP an eine zentrale Anlage anbinden und damit Standortvernetzungen erlauben. Beim Einsatz mit OCS und Exchange 2007 UM werden die meisten Firmen aber z.B. einen S2M-Anschluss zum Amt verwenden und ein Ethernet nach innen zum Mediation Server oder anderen VoIP-Telefonen und Soft PBX-Systemen.

Interessant ist hier die Option, dass auch intern S0-Anschlüssel bereit gestellt werden können. Viele andere Gateways können diese Funktion nicht, was den kompletten Verzicht auf eine PBX dann erschwert.

Es kann durchaus sein, dass andere Hersteller die Audiocodes-Gateways als OEM vermarkten. Allein vom Bild könnte hier 3COM (und damit nun HP) auch Gateways unter eigenem Namen vertreiben.

AnschlussMöglichkeiten, Routing und Rufnummer-Normalisierung

Es gibt viele Gateways, die eine Verbindung von TDM zum Mediation Server herstellen und so OCS hinter einer bestehenden Telefonanlage betreiben können. Wer den ganzen Schritt wagen will, braucht aber ein Gateway, welches die Telefonanlage ersetzen kann, bzw. alles mitbringt, damit OCS als Vermittlung agieren kann.

Dazu ist zum einen die Migration zu bedenken, d.h. wie kann eine bestehende Telefonstruktur (z.B. DECT-Stationen) noch weiter betrieben werden oder wie können bei einem PBX-freien betrieb noch Faxgeräte angeschlossen werden. Der OCS-Server unterstützt ja keine "VoIP-Adapter". Die Mediant 1000/2000 sind modular und erlauben die Bestückung mit mehreren ISDN-Steckkarten, die sowohl S2M (30 Kanäle) als auch S0 (2 B-Kanäle) unterstützen. Jeder Anschluss kann sogar als NT oder TN konfiguriert werden, d.h. kann selbst als Teilnehmer (TN) an einer bestehenden PBX agieren oder selbst als Anbieter von Kommunikationsdienstleistungen (NT) arbeiten.

 

Sogar ein Routing untereinander ist möglich, so dass ein Mediant am Amtsanschluss die Verbindung zum OCS-Server darstellen kann aber auch intern z.B. S0 Anschlüsse für Fax, Funktelefone, Alarmanlagen o.ä., bereit stellt. Es kann sogar notfalls über LAN direkt SIP-Telefone und Adapter an OCS vorbei betreiben, um eine Notfallfunktion aufrecht zu erhalten.

Damit das alles funktioniert, müssen Sie natürlich einen guten Rufnummernplan mitnehmen und im Mediant sowohl das Routing als auch die Rufnummern umschreibung korrekt konfigurieren.

Tipp:
Ich habe mir angewöhnt, die Routingentscheidungen im Mediant immer anhand der eindeutigen E.164-Nummer zu fällen. Entsprechend normalisiere ich
TEL2IP: Erst Normalisieren mit gesetzten NPI/TON, dann routen
IP2TEL: Erst Routen, dann Normalisieren und NPI/TON setzen
Es wird aber immer Sonderfälle geben, die eine andere Konfiguration sinnvoller machen.

Wenn Sie in eine Richtung sowohl die Quell und Zielnummer normalisieren sollten Sie bedenken, das der Mediant zuerst die Source-Nummer normalisiert. Das ist wichtig, denn Sie können die Source-Nummer in der Tabelle für die Zielnummer als Filterkriterium nutzen. Hier ist dann die bereits normalisierte Nummer zu verwenden.

Das Routing bestimmt ähnlich einem IP-Router, welche angesprochene Rufnummer zu welchem Ziel geleitet wird. Die Normalisierung erlaubt dabei in jede Richtung sowohl die Zielrufnummer als auch die Quellrufnummer in weiten Bereichen umzuschreiben. Das ist besonders wichtig, wenn z.B. ein Telefon am internen S0-Bus nur eine dreistellige Durchwahl intern anruft. Der Mediant muss dann die Zielrufnummer erst mal auf E.164 konvertieren aber auch die abgehende Rufnummer (Kurze MSN) komplettieren. Nur dann kann z.B.: der OCS-Server den Teilnehmer finden und anzeigen. Das Routing überträgt immer die Daten von einer Welt zur anderen. Ein Routing von ISDN zu ISDN geht zweimal durch die Routinglogik, indem der Ruf auf 127.0.0.1 vermittelt wird. Ungewöhnlich aber sicher tolerierbar. "Intern" arbeitet der Mediant nämlich auch immer über "LAN".

Wer bei der Verbindung zu OCS einen gesonderten PC als Mediation Server einsparen will, kann den sogar ebenfalls als Steckkarte in den Mediant einbauen.

Musterinstallation

Wenn Sie also z.B. eine mittlere oder kleinere Firma ganz ohne klassische Telefonanlage betreiben wollen, dann kann der Mediant 1000 eine sinnvolle Möglichkeit darstellen, um zwischen dem Telefonnetz nach extern und dem OCS-Server intern zu vermitteln und über die zusätzlichen ISDN-Anschlüsse eine ausgewählte Anzahl von alten Endgeräten weiter zu betreiben.

In diesem Beispiel ist das Gateway die Verbindung zum klassischen Amtsanschluss (z.B. S2M) und erlaubt über interne S0-Anschlüsse weiter den Betrieb von z.B. Faxgeräten, Telefonen in Aufzügen und Türsprechtelefone. Über die Netzwerkschnittstelle und den Mediation-Server können aber auch alle internen OC-Clients als Telefon genutzt werden.

Mit der passenden Lizenz kann das Gateway kann auch IPzuIP Vermittlung spielen um z.B. klassische SIP-Geräte oder SIP-Anlagen an OCS anzubinden. Es ist aber in dem Fall noch kein richtiger Session Border Controller.

ISDN-Anschluss

Beim M1000 können sie sowohl S2M (E1/T1) als auch S0 (BRI)-Module einbauen. Eine Unterscheidung, ob das Modul nun als Amtssimulation oder Teilnehmergerät konfiguriert ist, gibt es nicht. Allein über die Konfiguration wird eingestellt, welcher Anschluss sich wie verhält. Entsprechend verändern sich auch die elektrischen Eigenschaften, d.h. ob das System Strom liefert oder als Endgerät passiv arbeitet.

Hier die Pin-Belegung für den Anschluss von PRI und BRI aus der Mediant Dokumentation.

Analog-Anschluss

In den Mediant 1000 können auch Module mit 4 analogen Anschlüssen gesteckt werden. Dabei muss zwischen FXS und FXO unterschieden werden. Die Bezeichnung ist im amerikanischen Sprachraum gängig und bedeutet:

  • FXS ( S = Station)
    Der Audiocodes ist eine "Amt-Simulation, d.h. an diese Anschlüsse kann ein analoges Endgerät angeschlossen werden.
  • FXO (O = Office(
    Dieser Anschluss ist ein Endgerät und kann mit einer Amtsleitung verbunden werden. Diese Module kommen zum Einsatz, wenn der Mediant selbst als Nebenstelle agiert und analog an die Vermittlungsstelle angeschlossen ist.

Hier ein M1K-VM-4FXS Einbaumodul für einen Mediant mit 4 FXS-Anschlüssen.

Achten sie beim Anschluss der Geräte auf die Reihenfolge". Ich habe schon Module gesehen, die ihre Port 1-4 von links nach Rechts aufgeführt haben aber auch Module mit umgekehrter Nummerierung. Zum Glück kann man in der Weboberfläche sehen, welches Modul gerade "abgehoben" hat (Blau)

Fax T.38 mit Mediant und XCAPI (TE-Systems)

Der Mediant unterstützt natürlich auch den Betrieb von "Fax over IP" mit dem Codec T.38. Mittlerweile gibt es eine ganze Menge Faxserver, die auch "Fax over IP" unterstützen, d.h. keine eigene Faxkarten mehr benötigen. Allerdings entwickeln nicht alle Herstelle selbst den Fax over IP-Stack, sondern greifen auf die XCAPI (www.xcapi.de) von TE-Systems (www.te-systems.de) zurück. Dem PC wird damit vorgespielt, er habe einen CAPI-Stack mit ISDN-Karten, auf dem die Software dann aufbauen kann.

Der Mediant kann im Bezug auf Fax einige nette Dinge, die ich aber hier nicht eingesetzt habe. So kann er bei einem Gespräch "mitlauschen" und wenn er den Fax-Ton (CNG) erkennt, den Ruf schnell zum Faxserver umleiten. So können Sie eine Nummer für Telefon und Fax nutzen, wenn Sie einen Anrufbeantworter haben. Dies ist aber nur ein bedingt professionelles vorgehen und einige Faxweichen und Geräte haben dann doch Probleme damit . Wenn jemand heute schon einen Mediant einsetzt, dann dürfte es auch genug Rufnummern für persönliche Faxnummern geben, so dass man diese Funktion abschalten kann.

Technisch werden dann z.B. eingehende Faxe vom Mediant erst per SIP mit "Voice" signalisiert werden und die XCAPI nimmt diese standardkonform an. Damit aber der besser geeignete T.38-Codec verwendet wird, erfolgt ein Wechsel über ein REINVITE. Aber nur wenn die XCAPI auf "TRUNK" eingestellt ist funktioniert das korrekt.

In der Einstellung "Message" baut die XCAPI für jedes SIP-Paket eine neue TCP-Connection auf, womit der Mediant nicht zurecht kommt. Zusammen mit dem optionalen S0-Modul, an dem man noch ein paar vorhandenen klassische Faxgeräte per AB-Adapter anschließen kann, ist man damit gut aufgestellt, eine Telefonanlage komplett zu ersetzen.

Es gibt natürlich noch andere Produkte, die auf der einen Seite eine CAPI vorgeben und im Hintergrund VoIP machen, z.B. von Dialogic SoftIP (http://www.dialogic.com/products/ip_enabled/Diva_IP_Software_SIP.htm)

SBA Funktion

Die aktuelle Version des Mediant kann mit zwei Einschubmodulen zu einem vollwertigen SBA-System erweitert werden. Hier ein paar Bilder.

Die beiden Module werden in die Rückseite direkt neben dem Netzteil eingeschoben. Das obere Modul ist die Festplatte (2,5"  160 GB) und das untere Modul ein spezieller Intel-PC (OSN3), welcher nach außen einfach einen seriellen Port, einen USB-Port und einen Netzwerkanschluss bereit stellt. Ein Bildschirm kann nicht angeschlossen werden.

Mit dem PC bekommt der Mediant natürlich auch einen Microsoft Lizenzaufkleber, der aber "Windows Server Embedded. Standard 2008 R2 Teleco OEM Software" ist. Eine Windows Version, die nicht frei erhältlich ist. Wer genau hinschaut, sieht auch, dass hier ein "physical Productkey" und ein "virtual Productkey" aufgedruckt sind. (Wurden von mir natürlich unlesbar gemacht

Hier noch mal die beiden Module nebeneinander.

 

Die Installation selbst ist bei allen SBA-Systemen standardisiert.

S2M und "Kanalzählung"

Viele Monate lief der Mediant ohne Probleme aber doch gab es ab und an mal einen "Aussetzer" einer Sprachverbindung. Dank AC SNMP konnte ich dann doch die Ursache in Erfahrung bringen.

Jeder sollte wissen, dass ein S2M Anschluss bis zu 30 gleichzeitige Telefonate führen kann. Genau genommen hat er aber 32 Kanäle, von denen aber Kanal 0 und 16 als „D-Kanal“ verwendet werden, so dass effektiv nur 30 Leitungen zur Verfügung stehen. Das zeigt der Mediant auch schön an:

In Deutschland ist das der Kanal 0 und 16, die für die Steuerung herangezogen werden, was in der Trunk-Konfiguration auch hinterlegt wird. (Einstellung pro Trunk9

General Call Control Behavior findet sich ein "CHAN ID 16 ALLOWED = 0"

In der Tabelle mit den "Trunks" muss der Admin im Mediant ja hinterlegen, welche Kanäle zu welchem "Trunk" gehören. Da stand aber folgendes drin:

Wenn man aber 1-30 einträgt, dann bedeutet dies nicht, dass von den erlaubten Kanälen insgesamt 30 genutzt werden, sondern dass Kanal 1-15 und 17-30 genutzt werden. In der Summe als nur 29. Der letzte Kanal bleibt "ungenutzt" Das fällt auch nicht mal sofort auf, wenn der Mediant die Rufe "Ascending" verteilt. Dann kommt der Kanal 30 erst zum Zuge, wenn die anderen 29 schon belegt sind. Ein Fall der bei einer Testinstallation nicht so einfach zu erreichen ist. Aber auch wenn der Verteilung "Cyclic Ascending" ist oder sogar "Descending" ist, fällt dies nicht auf. Fehler gibt es immer dann, wenn die Gegenseite "hereinruft" und dabei den Kanal 31 verwendet oder wenn die Gegenseite einen Kanalwechsel auf die 31 erzwingt. Dann lehnt der Mediant ab, weil dieser Kanal ja so nicht freigegeben ist. Das erkennen Sie dann im Syslog:

(   lgr_psbrdif) pstn send --> PlaceCall: Trunk:0 BChannel:-1 ConnID:0 SrcPN=5251304613 SrcSN= DstPN=05246700 
(   lgr_psbrdex) pstn recv <-- CALL_PROCEEDING Trunk:0 Conn:0 BChannel:31  callhndl:0 Loc:-1 Des:-1
(     lgr_trunk) HandleBChannelNegotiation- BchannelNegotiation switch BChannel 2 to 31 on Trunk 0
(   lgr_psbrdif) pstn send --> PSTNDisconnectCall() Trunk:0 Conn:0 BChannel:2 Reason:17 Loc:-1 Des:-1 rc:0
(  lgr_endpoint) !! [ERROR] #60:CopyEndPointState- BchannelNegotiation new endpoint is busy or disabled
(     lgr_trunk) !! [ERROR] SwitchEndPoints- failed to switch BChannels 2 to 31
(      lgr_flow) #60:LOCAL_CALL_PROCEEDING_EV(Trunk:0 Conn:0 Bchannel:31 TpEv=73)
(      lgr_flow) |       #60:LOCAL_CALL_PROCEEDING_EV
(      lgr_flow) failed to handle board event [Event=LOCAL_CALL_PROCEEDING_EV]
(   lgr_psbrdex) pstn recv <-- CALL_RELEASED Trunk:0 Conn:0 RetCause:98 NetCause:17

Hier ist gut zu sehen, dass der Call nach extern aufgebaut wird aber dann ein B-Kanal-Wechsel der Telekom von Kanal 2 auf den Kanal 31 angefordert wird und das dann natürlich fehlschlägt.

Also stellen Sie hier bitte 1-31 ein, und schon sind diese Probleme auch gelöst.

Loopback für VoIP2VoIP

Der Mediant 1000 bei Net at Work hat eine recht umfangreiche Lizenz aber da wir kein "IP zu IP"-Routing machen, schließlich haben wir keinen SIP-Trunk nach draußen oder zu einer bestehenden TK-Anlage, habe wir keine SBC-Funktion. Nun kommt es aber doch vor, dass ein SIP-Gerät mit dem Mediant sprechen sollte. Das geht auch recht einfach einzurichten, wenn dieses Endgerät aus der TK-Welt (ISDN) erreichbar sein soll. Allerdings kann dieses System dann erst mal nicht mit Lync kommunizieren, denn das wäre dann eine IP2IP umsetzen.

Allerdings haben wir im Mediant noch 4x S0 verbaut, die einmal für den Anschluss von klassischen Telefonen, Faxsystemen etc. gedacht waren, die aber mittlerweile über einen Media Pack 112 als "Analoge Telefone" angeschlossen sind. Damit wurden diese Anschlüsse plötzlich "frei". Wenn man nun nicht allzu viele parallele Telefonate als "Voip2Voip" führen möchte, kann der Mediant diese Konfiguration als "Loopback " verwenden

Über eine geeignete Konfiguration normalisiert man die E.164-Nummer erst mal in eine "kurze" nummer, die dann auf einen S0-Anschluss gesendet wird. Auf dem zweiten S0-Anschluss kommt dieser Ruf dann wieder herein und kann entsprechend zu einem IP-Endpunkt geroutet werden. Jedes "Loopback"-Telefonat belegt dann natürlich auf jedem der beiden Anschlüsse einen B-Kanal.

  1. Loopback Einrichten
    Zuerst stelle ich einen S0-Anschluss auf "Network Site" mit "Clock Generate" und "EuroISDN Punkt zu Punkt"
    Der andere S0-Anschluss wird auf "User Site" mit "Clock Recovered" und "EuroISDN Punkt2Punkt" eingestellt
    Dann kann ich mit einem einfachen 1:1 Kabel die beiden Anschlüsse verbinden.
    Nach kurzer Zeit sollte der Status "Grün" sein
  2. Routing steht auf "Route after Normalization"
    d.h. zuerst werden die Nummern normalisiert und dann geroutet
  3. Eingehender Ruf per VoIP auf E.164-Nummer +49 5251 304 699
    Ich bevorzuge, dass im VoIP immer E.164 komplett mit "Plus" verwendet wird.
  4. Normalisierung E.164-Nummer auf ISDN-Nummer
    +495251304 699 -> 699
  5. Routing 699
    Diese Nummer wird auf den ISDN-Trunk geroutet, welcher als Mehrgeräteanschluss konfiguriert ist
  6. Eingehende Normalisierung  699 -> +495251304699
    Der Mediant bekommt seinen Ruf wieder mit der 699 als Zielnummer, welche wieder zu E164 werden muss
  7. Routing +495251304699 auf SIP-Gateway
    Diesen Ruf kann ich nun wieder an eine IP-Gegenstellt routen. Das kann auch ein "dummes" nicht Lync-taugliches Gateway sein.

Beachten Sie, dass Sie in dem Zuge natürlich auch die "Source Number" eventuell so anpassen müssen, dass die rufende Nummer korrekt mit übermittelt wird. Zudem sollte die Gegenstelle natürlich auch für Teilnehmer aus der "nicht VoIP-Welt" erreichbar sein. Das müssen Sie gegebenenfalls über entsprechende Normalisierungen sicherstellen.

Loopback für ISDN zu ISDN

Das gleiche Spiel kann man auch für eine direkte Verbindung von einem ISDN-Anschluss zu einem anderen ISDN-Anschluss machen. Hier routet man den Anruf erst mal per VoIP auf "Localhost" (127.0.0.1), so dass der Mediant dann eine zweite eingehende Verbindung per VoIP bekommt, die er dann wieder weiter routen kann.

  1. Routing steht wieder auf "Route after Normalization"
  2. Eingehender Call auf ISDN-Kanal mit "Telefonnummer"  698
  3. Normalisierung TEL -> E164
    Aus der kurzen Nummer wird eine vollständige E164-Nummer, z.B. +495251304698
  4. Routing auf "Localhost:5060"
    Damit landet der Call als "VoIP-Anruf auf dem Mediant
  5. Eingehender Call
    Im Syslog können Sie sehen, dass der Mediant ein "Invite" von sich selbst bekommt
  6. Normalisierung E164 auf Teilnehmernummer
    Nun muss die +495251304698 wieder auf eine 698 normalisiert werden
  7. Routing 698 auf ISDN-Trunk
    Diese Nummer wird auf den Trunk geleitet, an der das entsprechende ISDN-Endgerät angeschlossen ist. Dort muss natürlich die MSN entsprechend eingetragen sein

Auch hier müssen Sie beim Normalisieren natürlich auch die "rufende Nummer" anpassen, da im ISDN ein "+" nicht möglich ist. Und zudem werden auch hier zwei "Coder" belegt, da der ISDN-Anruf quasi durch VoIP durch getunnelt wird. Dieser Tunnel erlaubt es aber auch, entfernt angeschlossene Geräte in den VoIP-Verbund mit einzubinden. Und das sogar ohne dass Lync dafür erforderlich wäre.

ISDN und "Amtssimulation"

Ein Mediant 1000 kann wunderbar auch ein S0-Amt simulieren. Mit dem passenden Modul kann ich also intern auch andere ISDN-Teilnehmer einfach verbinden. Allerdings sollten Sie dann eine Einstellung anpassen, wenn das S0-Modul als Amt agiert. Normalerweise reagiert der D-Kanal nur, wenn auch eine "RR"-Meldung anliegt. Beim Amt muss aber der Mediant diese RR-Meldung senden, damit ein Endgerät dies sieht. Wenn Sie dies nicht einstellen, dann werden Sie sehen, dass der Status des S0-Anschlusses entweder orange bleibt oder zwischen Orange und Grün wechselt.

Eingestellt wird dies auf dem dem Trunk unter "Q931 Layer Response Behaviour"

Mit dem "BRI DL ALWAYS UP" wird der Mediant angewiesen, den D-Kanal immer "offen" zu halten.

Weitere Links