Audiocodes LDAP-Routing
Voraussetzung für diese Funktion ist die Firmware 6.0 oder höher
Achtung
Die aktuelle Beschreibung scheint mit der
aktuellsten Firmware so nicht mehr zu
funktionierne. Ich arbeite an einer Korrektur
Die meisten Installationen nutzen die AudioCodes-Gateways vermutlich mit "statischen" Routingeinträgen. Wer aber gerade in einer Migration steckt oder manuelle Einstellungen vermeiden möchte, kann auch das Active Directory nutzen, damit der Audiocodes abhängig von Feldinhalten die Rufe an das "richtige" System weiter gibt. Mit der Firmware 5.x musste dazu noch ein "ADRoute"-Hilfsprogramme installiert werden, welches im Kern eine angepasste Version von "FreeSwitch" war. Der Audiocodes hat den Ruf per SIP dann einfach an dieses Programm gesendet, welches im AD nachgeschaut und ein SIP-Redirect gemacht hat.
- LTRT-08038 Active Directory-Based Call Routing -
Application Note
http://www.audiocodes.com/filehandler.ashx?fileid=128384
Interessant wird die Funktion per LDAP, wie Sie in der Version 6.0 seit Februar 2010 implementiert ist. Seit dieser Version kann der Audiocodes direkt per LDAP z.B. ein Active Directory fragen
- Release Notes Version 6.0 - AudioCodes
http://www.audiocodes.com/filehandler.ashx?fileid=774575
Die Beschreibung in dem Readme ist aber aus meiner Sicht etwas irreführend und auch für OCS nicht optimal. Zuerst erfolgt die Einrichtung der LDAP-Verbindung, bei denen übrigens die IP-Adresse auf 0.0.0.0 gesetzt werden kann und im "Server Domainname" der FQDN eines Server oder auch eines Alias (Verfügbarkeit) eingetragen sein kann.

Legen Sie bitte ein Dienstkonto für den Audiocodes an, welches sein Kennwort nie ändern muss und nicht abläuft und vor allem kein Administrator ist.
Dann muss in der Routingtabelle als Ziel eben nicht die IP-Adresse eines Gateway eingetragen werden, sondern LDAP als Ziel addiert werden und weitere Einträge routen dann die Verbindung anhand der LDAP-Antwort.

Hier ist schön zu sehen, dass alle Rufe die aus dem Telefonnetz herein kommen (und vorher normalisiert wurden) zur LDAP-Abfrage gelenkt werden. Nur die Faxnummern 650-689 werden vorab schon anderweitig weiter gegeben. (Das Routen auf 127.0.0.1 erlaubt mir diese Rufe von dem ISDN S2M Anschluss über "Loopback" auf einen ISDN S0 Anschluss intern zu routen, bis auch das Fax auf FaxoverIP umgestellt ist. dann wird dort der Faxserver als Next Hop eingetragen).
Die LDAP-Abfrage liefert als Antwort dann die Ergebnisse:
- OCS:
Benutzer ist per OCS erreichbar - PBX:
Benutzer ist über die alte PBX erreichbar. Das kann auch eine IP-PBX oder eine als ISDN-Unteranlage angeschaltete PBX sein - MOBILE:
Der Benutzer ist über Mobilfunk zu erreichen - LDAP_ERR
Der Benutzer wurde nicht gefunden
Um die Funktionsweise zu verstehen, müssen wir nun ermitteln, was der Mediant im Detail macht und wie die Ergebnisse zustande kommen. Dazu muss man folgendes wissen
LDAP-Suche mit "(&(TelephoneNumber= nummer))"
Der Audiocodes sucht immer nur nach dem Feld "TelephoneNumber" und lässt
sich drei Felder zurückgeben.
Hinweis zum Einsatz von "telephonenumber"
Damit die Suche „schnell“ geht, sollten Sie im AD-Schema dieses Feld mit
einem "Index“ versehen. Das ist „by default“ nicht der Fall: (Siehe auch
Telephone-Number Attribute
http://msdn.microsoft.com/en-us/library/ms680027(VS.85).aspx.
Der Index kann recht problemlos eingeschaltet werden, siehe:
http://blogs.technet.com/b/ad/archive/2008/04/01/how-to-create-a-mosiac-of-user-thumbnails-in-aduc-dsa-msc.aspx
Wobei Sie in dem Feld natürlich auch reines E164 ohne Klammern,
Leerzeichen o.ä. verwenden sollten, damit die LDAP-Suche auch "trifft".
Siehe auch "Globalization Step-by-Step
http://msdn.microsoft.com/en-us/goglobal/bb688129.aspx
Damit ein Objekt gefunden wir, muss also der Inhalt des LDAP-Feld "TelephoneNumber" gefunden werden können. Dem Mediant ist es egal, ob es sich um einen Benutzer, Kontakt, Ordner o.ä., handelt, solange eine einfache LDAP-Anfrage eine Antwort liefert. Zusätzlich fordert der Mediant drei weitere Fehler ab, die in der Konfiguration angepasst werden können

Anhand der Antwort wird dann folgender Entscheidungsbaum durchlaufen:

Spätestens hier fällt dann auf, dass die Wahl des Feldes "msRTCSIPPrimaryUserAddress" (Siehe auch OCS Felder) ungünstig ist, da jeder OCS/Lync-Benutzer dieses Feld hat, selbst wenn er NICHT für Enterprise Voice aktiviert ist. Ich habe mir daher erlaubt das Feld zu ändern auf "msRTCSIP-Line".

Die Prefixes, die zum Routing verwendet werden, werden natürlich bei der Weitergabe ans Ziel wieder entfernt. So kann man mit dem Audiocodes aber sehr gut eine dynamische Umschaltung und zudem eine Ausfallsicherung bezüglich OCS, Lync oder PBX erreichen. Allerdings darf natürlich das LDAP-Verzeichnis nicht ausfallen. Da es sich aber um "Standard LDAP-Calls" handelt, können Sie gerne auch ein OpenLDAP oder ein ADAM/AD LDS einsetzen. Bei der Wahl des "richtigen" OCS/Lync-Felds ("msRTCSIP-Line" statt "msRTCSIPPrimaryUserAddress") werden Rufe nur dann zum Mediation Server geleitet, wenn der Benutzer auch für Enterprise Voice aktiviert ist, d..h. tatsächlich auch über Lync telefoniert.










