Audiocodes LDAP-Routing V2

Wenn Skype for Business nicht mehr hinter der TK sondern daneben laufen soll, benötigen Sie eine intelligentes Routing auf dem Gateway oder SBC.

Dieser Artikel ist in Zusammenarbeit mit Dirk Wulhorst, Skype for Business und Audiocodes Spezialist bei Net at Work, entstanden.

Diese Seite ersetzt die frühere Beschreibung auf Audiocodes LDAP-Routing

Dies ist in der Regel verbunden mit dem Aufbau eines Gateways oder Session Border Controller vor der TK-Anlage. Rufe zwischen Amt, TK-Anlage und Skype for Business laufen dann über diese Drehscheibe, die eine flexible Verlagerung von Benutzern erlaubt. Allerdings muss diese Instanz sehr schnell entscheiden, wohin der Anruf geroutet wird. Das kann über ein LDAP-Verzeichnis erfolgen.

Audiocodes bietet von Haus aus die Möglichkeit, die Routing-Entscheidungen auf den Mediant Gateways und SBCs auf Basis einer LDAP Datenbank zu fällen. Hier wird typischerweise das Active Directory angesprochen um hierdurch Skype for Business Teilnehmer zu identifizieren und Anrufe entsprechend zum Skype for Business Server zu routen. Dies wird insbesondere dann genutzt, wenn man im Parallelbetrieb zu einer Telefonanlage arbeitet oder sich in einer Migrationsphase befindet, was ohne Probleme mit einem einzelnen Active Directory und der normalen Routing-Entscheidung Skype for Business oder TK funktioniert. Eine Umgebung könnte ja wie folgt aussehen, das die externe Anbindung an das AMT per SIP-Trunk oder ISDN-Leitung schon über ein Gateway oder einen SBC läuft, der dann aber anhand des Active Directories oder einer anderen LDAP-Quelle entscheidet, ob der Ruf nun in Richtung alter "TK-Technik" oder per VoIP zu Skype for Business geroutet wird.

Oft gibt es vielleicht schon mehrere TK-Anlagen oder weitere SIP-Trunks zu Faxservern, CallCentern etc., so dass das Routing schon etwas ausgefeilter sein muss. Wenn es nur eine Entscheidung zwischen "Skype for Business" und "Resr" geben muss, dann kann eine Abfrage per LDAP an das Active Directory schon ausreichend sein. Wenn die Rufnummer im Feld "msRTCSipLine" enthalten ist und der User für "Enterprise Voice" aktiviert ist, dann ist es nur ein Skype for Business Anwender sein. Gibt es aber Anforderungen, verschiedene Active Directory Strukturen anzufragen oder das Routing weiter aufzuschlüsseln (z.B. TK, Skype for Business Test, Skype for Business Produktiv, Call Center Applikation, etc.) so stößt man über die oben beschriebene Möglichkeit schnell an seine Grenzen.

Die Lösung hierfür kann eine dedizierte AD LDS Instanz sein, die zum einen die benötigten Daten aus den verschiedenen Domänen und Forests konsolidiert, zum anderen aber auch zusätzliche Informationen wie zum Beispiel einen Parameter für das Routing-Ziel beinhalten.

Auf der Seite Audiocodes LDAP-Routing sehen, wie dies früher gemacht wurde.

ADAM / ADLDS Installation

Die Installation des Active Directory Lightweight Domain Services erfolgt bei Windows Server 2012 (R2) über den Server Manager -> Rollen und Funktionen hinzufügen.

Nach der erfolgreichen Installation von AD LDS kann man das Setup für die Instanz starten. Dies erfolgt entweder über die angebotene Verknüpfung am Ende der Installation im Server Manager oder man sucht im Start Menü nach „Active Directory Lightweight Directory Services Setup Wizard“. Als erstes muss man hier eine neue Instanz erstellen (Unique Instance):

Nachdem ein Instanz Name und eine Beschreibung vergeben wurden können im nächsten Schritt die zu nutzenden Ports konfiguriert werden. Der Standard ist hierbei 389 für unverschlüsselten Zugriff und 636 für den SSL Port.

Im nächsten Schritt wird eine neue Partition in der AD LDS Instanz angelegt. Die Namensgebung sollte hierbei nicht gleich einer bereits genutzten Domäne sein um Verwirrungen zu vermeiden und Anmeldungen am AD LDS Server besser verwalten zu können („lokale“ AD LDS User vs. Domänen-Accounts).

Nach Auswahl der Daten-Speicherorte (kann bei Bedarf auf ein Netzlaufwerk oder eine weitere Partition ausgelagert werden, im Standard wird es unter „C:\Program Files\Microsoft ADAM\“ abgelegt) müssen Sie einen Account angeben, unter dem der AD LDS Instanz-Dienst laufen soll. Hier haben Sie die Wahl zwischen dem Network Service und einem dedizierten Account, den Sie angeben können. 

Zusätzlich können noch die Administratoren für die AD LDS Instanz festgelegt werden. Entweder kann nur der aktuell eingeloggte Benutzer gewählt werden oder man entscheidet sich für eine lokale oder Domänengruppe.

Je nach Anforderungen kann man im abschließenden Fenster noch die zu importierenden Schema-Informationen wählen. Hier empfehle ich die MS-User.LDF zu nutzen, da hierbei alle benötigten Felder für ein Routing enthalten sind und noch genügend Zusatzinformationen hinterlegt werden können.

Hiermit ist die Installation der benötigten Instanz abgeschlossen und kann mit Daten gefüllt werden

Befüllen der Instanz mit ADAMSync

Um eine AD LDS Instanz mit Daten zu füllen, gibt es grundsätzlich mehrere Möglichkeiten.

1. Manuelle Pflege
   Sie füllen die Datenbank von Hand mit Informationen
   Dies erfolgt am Einfachsten über ADSI Edit, mit dessen Hilfe man sich mit der LDAP Instanz verbindet (Als Ziel die Partition angeben, die man bei der Installation erstellt hat, hier: CN=Audiocodes,DC=ADLDS,DC=Local)
2. Die benötigten Informationen werden über einen Datenbank-Import zum Beispiel aus einem vorhandenen Active Directory gezogen
   Dies erfolgt über das mit installierte Tool ADAMSync, welches unter C:\Windows\ADAM\adamsync.exe zu finden ist

Für die Synchronisation muss zuerst ein Konfigurations-Skript in XML (hier: AdamSyncConf.XML) erstellt werden, welches dann geladen wird. Hier eine Beispieldatei:

<?xml version="1.0"?>
<doc>
  <configuration>
    <security-mode>object</security-mode>
    <source-ad-name>DC.domain.local</source-ad-name>
    <source-ad-partition>AD-Partition des Active Directories in dem die Abfrage gestartet wird (z.B. OU=Users,DC=Domain,DC=Local)</source-ad-partition>
    <target-dn>CN=Audiocodes,DC=ADLDS,DC=Local</target-dn>
    <query>
      <base-dn>OU=Users,CN=Audiocodes,DC=ADLDS,DC=Local</base-dn>
      <object-filter>(&#124;(objectCategory=Person)(objectCategory=OrganizationalUnit)(objectClass=Group))</object-filter>
      <attributes>
        <include>cn</include>
        <include>Userprincipalname</include>
        <include>name</include>
        <include>description</include>
        <include>employeetype</include>
        <include>mobile</include>
        <exclude></exclude>
      </attributes>
    </query>
    <schedule>
      <aging>
        <frequency>1</frequency>
        <num-objects>0</num-objects>
      </aging>
      <schtasks-cmd></schtasks-cmd>
    </schedule>
  </configuration>
  <synchronizer-state>
    <dirsync-cookie></dirsync-cookie>
    <status></status>
    <authoritative-adam-instance></authoritative-adam-instance>
    <configuration-file-guid></configuration-file-guid>
    <last-sync-attempt-time></last-sync-attempt-time>
    <last-sync-success-time></last-sync-success-time>
    <last-sync-error-time></last-sync-error-time>
    <last-sync-error-string></last-sync-error-string>
    <consecutive-sync-failures></consecutive-sync-failures>
    <User-credentials></User-credentials>
    <runs-since-last-object-update></runs-since-last-object-update>
    <runs-since-last-full-sync></runs-since-last-full-sync>
  </synchronizer-state>
</doc>

Das initiale Laden erfolgt über folgenden Befehl:

C:\WINDOWS\adam\adamsync.exe /install localhost C:\Windows\ADAM\AdamSyncConf_DEGT.XML

Der eigentliche Sync erfolgt dann über einen Scheduled Task mit folgendem Befehl:

C:\Windows\ADAM\adamsync.exe /sync localhost:389 " Audiocodes,DC=ADLDS,DC=Local"

Sofern man mehrere Active Directories in den Sync aufnehmen möchte, benötigt man für jedes Active Directory eine entsprechende XML Datei erstellen und das Laden dieser XML mit in den geplanten Task aufnehmen.

Routing im Audiocodes

Um verschiedene Ziele zu definieren kann man zum einen dazu übergehen, die Rufnummern in unterschiedlichen Feldern zu pflegen, sodass abhängig davon, in welchem Feld die Rufnummer zu finden ist, der Anruf auf unterschiedliche Systeme geroutet wird. Die zweite Möglichkeit, die ich hier einmal vorstellen möchte, ist die Einführung eines zusätzlichen Attributs (hier wird als Beispiel das Attribut „employeeType“ genutzt, da es in der Demo-Umgebung nicht anders verwendet wurde). In diesem Attribut werden verschiedene Inhalte abgefragt, an Hand derer man das Routing entsprechend beeinflussen kann. Hierfür werden verschiedene Call Setup Rules erstellt.

In der Demo Umgebung ist das AD LDS eine selbst erstellte Datenbank, in der der CN gleich der Telefonnummern ist. Hierfür wird also im CN nach der angerufenen Nummer gesucht (Attributs to Query). Für alle 5 Fälle brauche ich den ‘employeetype‘ um festzustellen, wohin der Anruf geroutet werden muss. Zusätzlich Frage ich noch das Feld ‘mobile‘ ab, was ich im 5. Rule Set benötige.

• Das erste Rule Set ist ‘true‘, wenn im Feld ‘employeetype‘ „TK“ enthalten ist. Ansonsten wird diese Abfrage mit ‘false‘ beendet.
• Für die Rule Sets 2 – 4 gilt das gleiche mit den entsprechenden Werten (SfBProd, SfBTest, CCC).
• Das letzte Rule Set, die Nummer 5, ist etwas speziell. Die Idee hinter dieser Regel ist es, eine Telefonnummer fest auf ein anderes Ziel umzuleiten, ohne den Anruf überhaupt erst in ein System (Telefonanlage, Contact Center oder Skype for Business) routen zu müssen und somit die Weiterleitung direkt innerhalb des Audiocodes Gateways erfolgt. In diesem Fall wurde das Feld ‘mobile‘ gewählt um die neue Rufnummer zu hinterlegen. Wenn nun also „FWD“ im Feld ‘employeetype‘ eingetragen ist, wird die Zielnummer durch den Inhalt des ‘mobile‘ Attributs ersetzt.

Das ganze sieht dann wie folgt aus:

[CallSetupRules]

Damit diese Call Setup Rules auch genutzt werden, muss das Routing entsprechend konfiguriert sein. Hierbei wird über die Call Setup Rules Set ID geprüft, ob die entsprechende Routing-Regel greift. Bei der angesprochenen Regel 5 wird, wie auch bei anderen unbekannten / externen Nummern der Loopback genutzt um beim IP to Trunk Routing den Anruf ins Festnetz versenden zu können.

[PREFIX] (Tel to IP)

Damit die LDAP Abfragen abgesetzt werden können, muss abschließend noch der Server und der Einsprungspunkt bekannt gegeben werden. Der „LDAP Conf Server Domain Name“ ist dabei der FQDN des AD LDS Servers und der „Ldap Cont Bind Dn“ der User, mit dem man sich verbinden möchte. Zusätzlich muss noch das Password des Users angegeben werden.

[LdapConfiguration]

Das Kennwort ist hier natürlich nicht im Klartext zu sehen

[LdapServersSearchDNs]

Einschätzung.

Im Vergleich zu dem "einfachen LDAP-Routing" auf Audiocodes LDAP-Routing erscheint diese Variante erst einmal komplexer und umfangreicher. Aber wenn Sie Felder und Nummern umschreiben wollen, dann kommen Sie nicht umhin diesen Weg zu wählen.

Weitere Links

• Audiocodes LDAP-Routing
• Call Routing mit LDAP
• LTRT-08038 Active Directory-Based Call Routing - Application Note
  http://www.audiocodes.com/filehandler.ashx?fileid=128384