SBC Contact Lookup

Am Beispiel eines Audiocodes SBC möchte ich ein paar erweiterte Nutzungsmöglichkeiten der "Call Setup Rules" zeigen, um z.B. Phishing-Anrufe anders zu behandeln oder eingehende Anrufe aufzuwerten.

Anwendungsfälle

Ein Audiocodes SBC kann über HTTP oder LDAP auf externe Datenquellen zugreifen und diese bei der Verarbeitung von INVITE-Anforderungen einbauen. In diesem Beispiel gibt es zwei Anwendungsfälle:

  • Phishing-Anrufe abwehren
    Zwar können kriminelle Anrufer sehr häufig ihre Rufnummer ändern, aber anscheinend lohnt sich der Aufwand nicht. Anbieter wie Tellows führen Listen mit einem "Vertrauenslevel". Da liegt es nahe, eigehende Anrufe gegen diese Listen zu prüfen. Man muss ja nicht direkt den Ruf ablehnen (False Positive Risiko) aber eine Kennzeichnung wäre möglich.

    Hier sehen Sie, wie in Teams ein eingehender Anruf von einer "wenig vertrauenswürdigen" Rufnummer aussieht.
  • Firmenkontakte
    Der zweite Anwendungsfall ist die Aufwertung eines Anrufs anhand der Firmenkontakte. Die meisten Firmen pflegen ihre Kunden und Lieferanten in einem ERP/CRM-Systeme mit den Rufnummern. Hier ist es interessant, diese Information so aufzubereiten, dass der SBC bei einem eingehenden Anruf die Nummer um den Namen des Anrufers oder zumindest der Firma erweitert.

Dies sind nur zwei Beispiele und natürlich können Sie die Funktion der "Call Setup Rules" sogar dynamisieren, wenn der LDAP-Server oder der HTTP-Service abhängig von Uhrzeit, Standort, Anrufer, Ziel und vielleicht Auslastungsstatus die Anruf an alternative Ziele leitet.

Ein Problem bleibt natürlich: Die vom Provider gemeldete Rufnummer ist die "User Supplied Number", die der Anrufer allerdings einfach ändern kann, wenn er die Funktion "CLIP" zugekauft hat. Die "Network Supplied Number", die den " Anschluss identifiziert, von dem der Ruf aufgebaut wird, sehen in der Regel nur Polizei und Notrufzentralen.

Ich würde mir schon wünschen, den Provider beide Rufnummern übermitteln. Damit wäre es einfacher "Callcenter" zu unterscheiden und zu kennzeichnen oder Anrufe aus dem Ausland zuzuordnen. Denn die anrufende Nummer kann auch komplett ungültig oder gefälscht sein, so dass ein Rückruf sogar einen unbeteiligten Anschlussinhaber stört.

LDAP bereitstellen

LDAP ist einfach, schnell und kostenfrei. Denn in jeder Windows Server Version ist der AD LDS-Server, früher auch ADAM-Server genannt, dabei. Es ist quasi der gleiche Code, den auch das große Active Directory verwendet, nur dass all die anderen Bestandteile eines DCs wie Kerberos, Netlogon, LSASS etc. fehlen. Der ist schnell installiert und mit Anmeldedaten versehen. Dann brauchen wir nur noch die Quelldaten. Am besten eignet sich nach meiner Erfahrung eine CSV-Datei, die einfach nur die Rufnummer im E.164-Format und den Namen bzw. die Klassifizierung enthält.

Vielleicht war ich zu vorschnell. Gerade in ER/CRM-Systemen sind zwar Rufnummern gepflegt aber die Qualität ist meist miserabel. Menschen sind sehr gut darin, aus einer "komisch" aufgeschriebenen Rufnummer eine gültige Nummer zu wählen. Computer "schätzen" aber nicht. Hier ist vermutlich etwas Aufwand beim Bereinigen/Korrigieren der Adressen erforderlich, wenn Sie nicht per Skript danach die Daten immer wieder angleichen wollen.

Diese CSV-Datei importieren wir dann einfach in den LDAP-Server. CSVDE ist ein Hilfsmittel, welche neue Einträge addieren kann aber es löscht keine alten Einträge. Sie könne es aber auch per PowerShell machen.

LDAP-Verbindung

Wenn der LDAP-Server steht, können wir im Audiocodes den Server entsprechend einrichten. In dem Beispiel gibt es noch einen zweite LDAP-Server der die Anmeldung an der Weboberfläche zentralisiert. Das sind hier erst einmal nur LDAP-Server mit Servername, BaseDN und natürlich Anmeldedaten.

Je nachdem, wo ihr Server steht, müssen sie natürlich noch in der Firewall die entsprechenden Freischaltungen einrichten.

Call Setup Rules

Der nächste Schritt ist dann die Erweiterung der Call Setup Rules, um bei eingehenden Anrufen die gemeldete Nummer per LDAP im LDAP-Verzeichnis nachzuschlagen. Hier nutzt die Regel die LDAP-Suche mit

'CN='+Param.Call.Src.User

Angefordert werden die Felder "Displayname" und "Company". In der Aktion steht dann, dass das Feld "Header.From.Name" durch die Antwort ersetzt wird

ldap.attr.displayName + '(' + ldap.attr.Company +')'

Wenn Sie im LDAP-Server schon beim Import der Rohdaten den Displaynamen nach ihren Vorgaben setzen, dann können Sie die Ersetzungsregel auch einfacher gestalten.

Natürlich kann man das noch "hübscher" machen, z.B. indem man nicht gefundene Felder ausblendet. Die Call Setup Rules sind sehr mächtig und kann ich hier gar nicht alle wiedergeben. Über eine ähnliche Regel können Sie natürlich auch nach einer Rufnummer suchen und im Displayname dann z.B. "Callcenter" oder "Phishingverdacht" zurückliefern.

Zukunft

Diese Lösung funktioniert natürlich nur, wenn Sie selbst Betreiber des SBC sind. Mit einem Microsoft Dialplan kommen die Anrufe gar nicht mehr bei ihnen vorbei und wenn Sie einen "Hosted SIP-Trunk" durch einen Provider nutzen, dann kann dieser solche "Mehrwertdienst" liefern.

Wenn Teams zukünftig immer mehr die Funktion eines CallCenters bekommen soll, dann wird Microsoft eine "Rufverarbeitung" auf die ein oder andere Weise integrieren müssen. Vielleicht können solche Lösungen dann komplett "in der Cloud" erfolgen.

Wenn in ferner Zukunft einmal immer mehr Firmen mit Office 365 arbeiten und Teams per Federation nutzen können, werden Anrufer über Telefonnummer vielleicht eher die Ausnahmen werden. Das Problem wird sich aber dennoch nicht lösen, solange anonyme Anrufer möglich sind.

Hier wären dann schon einmal die Carrier gefragt, dass Sie auch die Anschlussnummer liefern und damit es für Scammer immer schwerer wird, sich hinter fremden Rufnummern zu verstecken. Solange an der mitgelieferten Nummer des Anrufers nicht trauen kann, ist der Mehrwert gering. SPF und DKIM für Rufnummern gibt es leider noch nicht. Es würde ja schon reichen, wenn die Carrier verifizierte Rufnummern anders kennzeichnen oder beide Nummern übertragen. Innerhalb von Firmen ist es ja üblich, dass Telefone und Teams bei einer Umleitung beide Informationen anzeigen.

Weitere Links