Call Routing mit LDAP

Auf dieser Seite beschreibe ich generelle Überlegungen zum Routen von Telefon-Anrufen zu den unterschiedlichen Systemen. Früher gab es nur einen Amts-Anschluss, der direkt zur Telefonanlage geschaltet war. Wenn Sie hier mit OCS, Lync, Skype for Business gestartet sind, dann meist als nachgeschaltete "Unteranlage", der von der Hauptanlage ausgewählte Rufnummern zugeleitet wurden. Mit der der Verlagerung der Teilnehmer zu VoIP und UC und insbesondere mit dem Umstieg auf "SIP-Trunks" seitens der Amtsleitung stellt nicht mehr die Frage, wer die zentrale Routing-Instanz ist sondern eher wie die Entscheidung zu fällen ist.

SBC als Routing-Instanz

Wenn ein Session Border Controller in der Mitte sitzt und alle Verbindungen über diese Instanz laufen, dann muss der Betreiber einen effektiven Weg zur Entscheidungsfindung umsetzen. Niemand möcht auf Dauer in einer Routingtabelle eines SBC einzelne Rufnummern und nicht mal Rufnummernblöcke verwalten.

Also gibt es früher oder später irgendwo einen Verzeichnisdienst, der vom SBC abgefragt wird und dem es für jeden Teilnehmer ein Objekt samt passender Antwort gibt.

Active Directory, ADAM und Co

Das kann natürlich ein Active Directory ihres Unternehmens sein. Allerdings müssen Sie beachten, das die LDAP-Abfragen sehr schnell beantwortet werden müssen und daher die relevanten Felder im Index ein müssen. Ein eigner LDAP-Service hat daher auch seine Vorteile. Ich versuche mich an einer generellen Tabelle. Aber erst über eine Gewichtung der einzelnen Punkte für ihre Umgebung können Sie letztlich eine Entscheidungsvorlage erarbeiten.

Service Vorteile Nachteile

Active Directory
Azure AD Domain Services

  • DCs sind in der Regel da und hochverfügbar
  • Vorhandene Objekte samt Applikationseinstellungen können genutzt werden
  • Keine doppelte Datenhaltung
  • Kooperative Administration

  • Zusätzliche Objekte, die gar nichts mit dem AD zu tun haben
  • Höhere Belastung der Domaincontroller
  • AzureAD: Zusätzliche Kosten
  • Kooperative Administration
  • Enge Verzahnung, z.B. DC Updates und Patches stören SBC Routing

ADAM

  • Eigene unabhängige Server vom AD
  • Eigene Sicherheitsverwaltung
  • Keine Fremdobjekte im AD
  • Platzierung "nahe" des SBC
  • Für Rufnummernabfrage optimierbarer Index
  • Nutz die vorhandene Windows Umgebung
  • Datensparsamkeit

  • Zusätzliche Dienste
  • Zusätzliche Ressourcen
  • Überwachung erforderlich
  • Datenpflege/Synchronisation

3rd Party

  • Komplett getrennt von Active Directory und ADAM zu betreiben
  • Datensparsamkeit

  • Wie bei ADAM
  • Zusatzkosten für Server
  • Koten für Lizenzen
  • Datenpflege/Synchronisation

Wer also sowieso die meisten Teilnehmer als Objekte im Active Directory haben möchte und auch die Rufnummernverwaltung damit im Active Directory abbildet, ist mit einem AD durchaus gut beraten. Bei einem höhen Anrufaufkommen kann aber die Abhängigkeit und Belastung eher dafür sprechen, eigene LDAP-Server (ADAM oder 3rd Party) auf eigener Hardware zu nutzen. So kann auch die Verwaltung separiert betrachtet werden, was je nach Umgebung als Vorteil oder Nachteil ausgelegt werden kann.

Meinen ersten ADAM-Server habe ich bei einem Kunden aufgebaut, der für seine Siemens Hicom damals ein Adressbuch bereit stellen wollte. Das Active Directory war aber keine Option, da zwar auch die Schreibweise der Rufnummer mit einem Produkt in Konflikt gekommen ist aber vor allem hat die fehlende Authentifizierung eine Kopplung mit dem AD verboten

Insofern kann ein eigener LDAP-Service für Voice Routing durchaus Interesssant sein, da aufgrund der Datensparsamkeit hier nur die Rufnummer und das Ziel hinterlegt sein muss. Wenn diese Daten nicht "schützenswert" sind, dann kann bei der Abfrage per LDAP zwischen SBC und LDAP-Server sogar auf eine Authentifizierung und damit auch auf Verschlüsselung verzichtet werden.

Herausforderung LDAP-Suche

Der SBC hat für seine Anfrage nur eine Telefonnummer, die er idealerweise schon auf E164 normiert hat. Damit stellen sich zwei Fragen:

  1. In welchem Feld "sucht" er ?
    Dieses Feld muss natürlich genau die Rufnummer enthalten, nach der die Anfrage sucht. Eine "Ähnlichkeitssuche" kostet Zeit und liefert im schlimmsten Fall mehrere Ergebnisse. Damit der LDAP-Server sehr schnell eine Antwort liefert, muss das Feld indexiert sein. Es muss auch für alle relevanten Objekte vorhanden sein und sollte keine externe Abhängigkeiten nutzen
  2. In welchem Feld steht die Antwort?
    Dann stellt sich die Frage, wie die Antwort aussieht. Früher war es einfach nach der "LineURI" in Skype/Lync zu suchen und bei einem Treffer den Anruf zu Mediation Server zu leiten. Ohne Treffer ging der Ruf dann zur Telefonanlage. Das geht aber nicht mehr, wenn die "Default Route" die Amtsverbindung ist. Dann muss die Antwort schon klar beschreiben, welches Ziel für bekannte Nummern herangezogen werden soll.

Das System kann doch komplexer gemacht werden da SBCs auch flexibel auf Fehler reagieren können. Stellen Sie sich vor, dass ein Ziel gefunden wird aber nicht antwortet (480 Temporarily Unavailable) oder besetzt (486 Busy here) ist und sie darauf flexibel reagieren wollen. Per LDAP könnte dann der Weg zur VoiceMail, Zentrale, CallCenter, Warteschlange o.ä. hinterlegt sein.

Sie könnten aber auch die Datenbank nutzen, um nicht nur nach der Zielrufnummer sondern auch anhand des Absenders zu routen. Sie könnten je nach Länderkennung des Anrufers unterschiedliiche Telefonzentralen (Fremdsprachen) hinterlegen oder auch unterwünschte Rufnummern (Siehe Wardialing - Telefonterror oder Phishing) abweichend behandeln.

Welches Felde zur Suche?

Entsprechend gibt es verschiedene Felder, die unterschiedlich gut geeignet sind. Ich versuche mich mal an einer Gegenüberstellung. Kriterien sind dabei

  • Editierbar
    Wie kann ein Administrator den Inhalt einfach editieren? Wenn er dazu in ADSIEDIT arbeiten muss, ist das negativ.
  • Eineindeutigkeit
    Sichert der LDAP-Server vielleicht schon ab, dass Inhalte nicht mehrfach vorhanden sein dürfen? Dann wäre das positiv
  • Sichtbarkeit
    Einige Fehler sind in Outlook und anderen Stellen auch für Anwender sichtbar
  • Störpotential
    Ich habe schon Konfiguration gesehen, die in den "ProxyAddresses" nach "SIP*" oder "TEL:*"gesucht haben. Das ist sicher möglich aber zumindest fragwürdig, da hier sogar ein Multivalue-Feld durchsucht wird und Störungen zu anderen UC-Produkten nicht auszuschließen sind.
  • Produktbindung
    Es ist immer von Vorteil ein Feld zu nutzen, welches direkt mit dem entsprechenden Produkt verbunden ist. So hat jeder Anwender mit Skype for Business Telefonie die Nummer im Feld msRTCSipLine. Leider kann dies auch für andere Objekte gelten. Fremde Felder sind flexibler aber erfordern eine Abstimmung und bergen das Risiko von Inkonsistenzen.

Hier eine Auswahl an Feldern

Feldname Beschreibung Eignung

TelephoneNumber

Dieses Feld gibt es in jedem Active Directory sowohl für Benutzer und Kontakte. Der Administrator kann das Feld wunderbar pflegen und jeder Anwender kann es in Outlook u..a einsehen. Vorsicht ist natürlich geboten, wenn Anwender das Feld selbst ändern könnten oder mehrere Personen sich eine Rufnummer teilen, z.B. Schichtarbeiter o.ä.

ExtensionAttributeXX

Diese Felder sind nur im AD vorhanden, wenn die Exchange Schema Erweiterungen installiert wurden. In einem 3rd Party LDAP-Server ist das kaum der Fall. Aber selbst dann ist nicht ausgeschlossen, dass die Felder schon anderweitig genutzt werden. Es ist aber ein String der auch im Index ist.

IPPhone

Diese Feld im Active Directory ist ebenfalls über die MMC als Administrator direkt zu erreichen und nutzbar. Ich wüsste aktuell von keinem Programm welches dieses Feld nutzt. Allerdings erscheint der Inhalt in der Outlook Kontakt-Karte. Das kann gut oder auch für eine schnelle Fehlersuche gewollt sein.

ProxyAddresses

Das Feld wurde gerne für Lync/Skype genutzt, das neben den SMTP-Adressen hier dann auch eine SIP-Adresse addiert wurde. Aber mal abgesehen, dass das Feld nur nach einer Exchange Schema Erweiterung vorhanden ist wird es aktiv von Exchange genutzt. Es gibt eine klare Aussage zu Microsoft, dass Exchange Felder nur über die Exchange Commandlets verändert werden dürfen. Ich würde daher hier nicht über andere Tools sogar noch E164-Rufnummern kodieren

msRTCSipLine

In diesem Feld steht die Rufnummer als Skype for Business On-Premises Benutzer mit Enterprise Voice. Es ist ein super Feld um diese Teilnehmer zu identifizieren aber hilft z.B.: nicht bei Teams mit Direct Routing weiter.

Eigenes Feld

Es steht ihnen natürlich frei, das Schema das LDAP-Service mit einem eigenen Feld zu erweitern und dort die E.164-Rufnummer als Suchbegriff zu hinterlegen. Allerdings würde ich dies maximal mit einem ADANM-Server oder 3rd Party LDAP-Server tun. Ein produktives Active Directory zu erweitern ist keine alltägliche Aufgabe

Felder mit Antwort

Sie haben also mindestens ein Feld gefunden, in dem das SBC nach der Rufnummer suchen kann und idealerweise genau ein Objekte findet, dann brauchen wir nun natürlich noch ein Feld, welches das Ziel liefert. Wie Sie beim obigen Bild ja sehen können, gibt es sehr viele mögliche Ziele und meist nutze ich ein Feld, in dem ich einen String hinterlegen kann.

In der Regel versuche ich mit einer einzelnen LDAP-Abfrage das passende Objekte zu finden und dann anhand eines anderen Felds das Ziel zu ermitteln. Es gibt aber auch Umgebungen, die z.B. zuerst in msRTCSipLine suchen und bei einem Treffer den Anruf zu Skype for Business routen. Ohne Treffer könnte man dann weitere Felder fragen. Aus meiner Sicht ist dies aber nicht ratsam, da mehrere LDAP-Anfragen erforderlich sind und dies sich negativ auf die Systemleistung auswirkt

Wir gehen also davon aus, dass eine LDAP-Suche nach der Rufnummer in einem Feld schon ein passendes Objekt liefert. Sollte kein Objekt gefunden werden, dann wir der Anruf ins Amt geroutet.

Verifizieren Sie ihr Routing auf jeden Fall, dass keine anonymen Anrufer auf ihre Kosten z.B. Amtsverbindungen aufbauen können. Der Anrufer muss von einer internen Quelle kommen.

Damit ist aber immer noch nicht definiert, welches Feld letztlich das Ergebnis enthält. Hier ein paar Vorschläge. Für eine Fehlersuche durch den Anwender oder Helpdesk ist es natürlich auch hier interessanter ein sichtbares Feld zu verwenden.

Feldname Beschreibung Eignung

msRTCSIP-DeploymentLocator

Dieses Feld enthält bei Skype for Business den Status des Benutzers, sofern Sie überhaupt Skype for Business OnPremises installiert haben. Das Feld kann einen von drei möglichen Werten enthalten:

  • SRV:  Der Benutzer ist in Skype for Business OnPremises aktiv.
    Das bedeutet aber nicht, dass er auch Enterprise Voice nutzt.
  • sipfed.lync.com
    Der Benutzer ist in Skype for Business Online oder Teams. Leider gibt es keine Unterscheidung hier, welche Online-Plattform der Anwender aktuell nutzt. Sie können den Call noch über SfB Hybrid zu beiden Benutzertypen routen aber wünschenswert wäre natürlich Direct Routing. Nur darf es dann keinen Benutzer mehr in SFB-Online geben
  • $null
    Der Benutzer ist nicht für Skype for Business aktiviert. Ohne Hybrid Mode könnte der Benutzer aber dennoch in Teams aktiv sein

Insofern ist das Feld nur in wenigen Umgebungen sinnvoll nutzbar, z.B. wenn ein Hybrid Umzug von Skype for Business OnPremises direkt zu "Teams Only" durchgeführt wird.

IPPhone

Diese Standardfeld im AD kann Rufnummer enthalten aber wird ansonsten nicht genutzt. Es kann auch einfach über die MMC verändert werden. Die Sichtbarkeit des Inhalts an verschiedenen Stellen kann nachteilig angesehen werden. Dennoch ist es eine Option die Rufnummer über "Telephonenumber" zu suchen und das Ziel über IPPhone zu erhalten.

andere Felder

Wenn ihnen IPPhone nicht gefällt, können Sie gerne auch andere Felder missbrauchen. Sie sollten nur sicherstellen, dass kein anderes Produkt in der Zukunft das Feld belegt. Insofern sind Felder wie "department, networkAdress, OtherPager etc. keine gute Wahl.

 

In dem Feld steht dann natürlich eine Antwort, mit der das Routing im SBC entsprechend gesteuert wird. Ich nutze da am liebsten "lesbare" Strings wie z.B.:

Feldinhalt Bedeutung

Teams

Anrufe an Teilnehmer mit dieser Einstellungen werden über den Direct Routing-Trunk zu Teams in Office 365 geroutet

SfB

Routing zum lokalen Mediation Server

FAX

Routing zum Faxserver

PBX

Routing zur noch vorhandenen TK-Anlage

Es hindert sie natürlich niemand daran, eigene Strings mit eigenen Bedeutungen zu definieren. Denkbar auch Nummern wie Teams1, Teams2, Team3, um verschiedene Trunks anzusteuern.

Synchronisation/Reporting

Wir wissen nun natürlich, dass es Felder für die Routingentscheidung des SBC gibt und andere Felder für die verwendeten Produkte relevant sind. Hier müssen Sie also auf eine 100% Übereinstimmung achten, da ansonsten der SBC Anrufe an ein Ziel routet, welches damit nicht umgehen kann. Leider gibt es hier keine "fertigen" Lösungen, so dass Sie für ihre Umgebung einen geeigneten Weg zum Provisoining umsetzen müssen. Dazu müssen Sie zuerst einmal das "führende System" bestimmen. Für den SBC ist das ja ihr zentraler "Telefonnummern-LDAP-Server". Insofern bin ich versucht diesen Server als "führend" für die Rufnummern anzusehen, dem sich alle anderen Systeme unterordnen müssen.

Ich rate hier schon zu einem Überwachungsskript, welches zyklisch die Rufnummern im System gegen die Zielsystem abgleicht und Unstimmigkeiten umgehend meldet. Dies kann aber nur eine zusätzliche Absicherung gegen Falschkonfigurationen sein. Wer immer auch Rufnummern vergibt und pflegt, muss diese Einstellungen sowohl auf dem Zielsystem als auch der Routing-Datenbank machen. Die Verwaltung von Rufnummern war bislang zwar in der Hoheit der TK-Abteilungen. Seit dem aber die TK-Anlagen nicht mehr alleine oder gar führend sind, müssen hier Prozesse umgestellt werden.

Weitere Links