Teams Incoming Call Handler

Schon seit wir mit Teams telefonieren können, kommt die Frage auf, wie eingehende Calls eine Aktion auslösen können. Diese triviale Funktion wird für die Integration von CRM-Applikationen o.ä. benötigt und nicht jeder möchte eine "Server-Kopplung". Seit Sommer 2022 gibt es nun eine passende Einstellung in den "Calling Policies", über die ich eine URL hinterlegen kann, die bei den entsprechenden Benutzern aufgerufen wird.


Quelle: https://www.microsoft.com/de-de/microsoft-365/roadmap?filters=&searchterms=98054

Am 8 Nov 2022 habe ich in meinem Tenant dazu auch eine Information bekommen:


Quelle: https://admin.microsoft.com/AdminPortal/home?#/MessageCenter/:/messages/MC445202

Funktionsweise

Die Zusammenhänge sind schnell beschrieben:

  1. CRM o.ä. mit Deep-Link-Funktion
    Teams startet eine URL mit der Rufnummer. Ihre CRM-Lösung muss daher für den Client per Browser über eine HTTPS-URL mit der Rufnummer als Parameter erreichbar sein. Ansonsten können Sie hier schon abbrechen. Geben Sie aber nicht zu früh auf. Auch eine lokale Kontaktlösung könnte man durchaus ertüchtigen, denn Teams könnte auch einen lokalen Webserver ansprechen, der die Parameter dann an eine klassische Software weitergibt (SendKey, API etc.)
  2. Eingehende PSTN-Anrufe mit Rufnummer landen auf dem Teams Client
    Die Funktion ist nicht verfügbar, wenn es ein Teams-Anruf, Federation-Anruf oder eine Meeting Einladung ist. Auch anonyme PSTN-Anrufe ohne Rufnummer triggern nicht die Funktion
  3. Der Benutzer muss den Anruf annehmen
    Wenn der Anwender den Anruf ablehnt, startet kein Browserfenster. Der Anwender kann als auch nicht schon allein anhand der Rufnummer vor der Rufannahme die Details des Anrufers einsehen. Das ist aber sinnvoll, wenn die Anrufe z.B. über eine CallQueue kommen und mehrere Agenten den Anruf signalisiert bekommen
  4. Konfiguration der "Calling Policy"
    Darüber kann der Administrator steuern, ob der Anwender überhaupt die Funktion nutzen darf und welche URL aufgerufen wird. Der Anwender kann die Funktion also nicht eigenständig aktivieren oder eine eigene URL hinterlegen. Der Administrator muss also eine passende Calling Policy konfigurieren und dem Benutzer zuweisen. Denken Sie daran, dass Änderungen hier nicht immer sofort aktiv werden.
  5. Benutzer muss die Funktion aktiviert haben
    Der Anwender kann durchaus selbst entscheiden, ob er die angebotene Integration nutzen will. Er muss die Funktion aktuell auch noch selbst einschalten:
  6. Wenn eine URL hinterlegt ist, ruft Teams mit der Rufannahme den Browser mit der URL auf.
    Nun kann der Anwender parallel zum Telefonat im geöffneten Browser die dazugehörigen Aktionen ausführen.

Die URL wird auch bei einer Rufannahme eines eingehenden Rufs über eine Call Queue getriggert.

Denken Sie aber daran das neu geöffnete Fenster dann auch wieder zu schließen.

Aufgrund der Funktionsweise ist diese Lösung nicht dazu geeignet, einen Server über eingehende Anrufe zu informieren. Wenn der Anwender nicht auf einem tauglichen Client angemeldet ist, passiert auch nichts.

Konfiguration

Die Konfiguration der URL finden Sie in den Calling Policies. Ich habe mir dazu eine neue Policy angelegt, um mit den URLs zu spielen und nur einen Testbenutzer zu stören:

Im Portal stellt Microsoft eine Muster-URL bereit, die Hinweise auf das Format gibt:

Die Konfiguration ist natürlich auch per Teams PowerShell mit Set-CsTeamsCallingPolicy möglich:

Set-CsTeamsCallingPolicy `
   -Identity <name> `
   -popoutAppPathForIncomingPstnCalls "https://www.msxfaq.de"

Es scheint so, dass Teams ein "{phone}" durch die Rufnummer ersetzt. Entsprechend habe ich einige URLs probiert:

URL Ergebnis 
http://localhost:10080/newcall/{phone}

Diese URL ist NICHT möglich, denn HTTP ohne Verschlüsselung ist nicht unterstützt und wird nicht zugelassen.

 
https://localhost:10080/newcall/{phone}

Diese URL kann ich problemlos eintragen. Damit kann ich z.B. einen lokalen CRM-Client als Gegenstelle adressieren, die in dem Beispiel auf 127.0.0.1:10080 lauschen müsste.

 
https://www.msxfaq.de/newcall.php/{phone}

Eine externe URL ist sicher besser, wenn die CRM-Lösung ohne lokalen Client auskommt und über einen Browser bedient wird. Das ist bei Microsoft Dynamics CRM z.B. der Fall.

Kontrolle auf dem Client

Ob die geänderten Richtlinien schon auf dem Client angekommen sind, können Sie einfach über die Client-Logs kontrollieren. Starten Sie diese über CTRL-ALT-SHIFT-1 und öffnen Sie die Textdatei mit einem Editor um nach dem String "popoutAppPathForIncomingPstnCalls" zu suchen.

...
    "callingPolicy": {
      "value": {
        "allowPrivateCalling": true,
        "allowGroupCalling": true,
        "allowCallForwarding": true,
        "allowWebPSTNCalling": true,
        "allowSIPDevicesCalling": true,
        "allowVoicemail": "UserOverride",
        "allowCallGroups": true,
        "allowDelegation": true,
        "allowCallForwardingToUser": true,
        "allowCallForwardingToPhone": true,
        "busyOnBusyEnabledType": "Disabled",
        "musicOnHoldEnabledType": "Enabled",
        "liveCaptionsEnabledTypeForCalling": "DisabledUserOverride",
        "autoAnswerEnabledType": "Disabled",
        "callRecordingExpirationDays": 60,
        "popoutForIncomingPstnCalls": "Enabled",
        "popoutAppPathForIncomingPstnCalls": "https://www.msxfaq.de/newcall.php/{phone}"
      }
    },
...

Anzeige auf dem Client

Die Anzeige auf dem Client ist relativ unspektakulär: Der Anruf kommt an, der Anwender nimmt den Anruf entgegen und je nach Geschwindigkeit des PCs öffnet sich mehr oder minder schnell der Default Browser mit der konfigurierten URL.

Interessanterweise wird die URL nicht encoded und das "+" erscheint direkt. Sie können natürlich in der Konfiguration das "{phone}" auch als Parameter übergeben, z.B. mit

        "popoutAppPathForIncomingPstnCalls": "https://www.msxfaq.de/newcall.php?pone={phone}"

Die aufgerufene URL sollte dann der Webserver nutzen, um entsprechende Stammdaten, Zusatzinformationen und ggfls. Eingabemasken für den Call liefern. Die Authentifizierung obliegt dem Browser. Wenn sie ihren Standardbrowser auch für die Anmeldung per Kerberos oder OAUTH nutzen, kann der Webserver die Anmeldedaten gleich mit beziehen.

Öffentlicher Reverse-Suche

Ansonsten sind theoretisch beliebige andere Webseiten möglich, die auch anonym Daten liefern. Es gibt ja durchaus einige Anbieter, die auch mit einer Rufnummer in der URL zurecht kommen. Allerdings müssen Sie natürlich eine E.164-Nummer prüfen. Am 23.11.2022 konnte ich das über 11880.com nutzen.

# Beispiel für die Nutzung von 118800
https://www.11880.com/rueckwaertssuche/{phone}

Achtung: Datenschutz.
Wenn jeder eingehende Anruf einen HTTPS-Request zu einem dieser Dienste erstellt, dann kann der Anbieter anhand der Quell-IP Adresse und anderer Daten ihres Browsers mitsamt der Rufnummer ein lückenloses Angerufen-Protokoll einer Firma anfertigen. Daher sollten sie den Einsatz solcher Quellen genau überlegen.

Nachdem dann die Richtlinie auf meinem Client angekommen ist, bekam ich bei entsprechend rückwärts auflösbaren Rufnummern auch eine Anzeige:

Ich habe noch ein paar andere Dienste geprüft aber noch keine passende URL gefunden bzw. die Dienste konnte mit "+49" einer E.164-Nummer (noch) nichts anfangen

# Scheint nicht zu gehen, da sie mit dem + nicht zurecht kommen
https://www.dasoertliche.de/rueckwaertssuche/?ph={phone}&pa=&address=

# Tellows kommt wohl auch nicht mit dem + zurecht
https://www.tellows.de/search/?number={phone}

Alternativen

Sie müssen nicht die Teams Funktion nutzen. Es gibt durchaus Alternativen.

  • SBC-Abgriff
    Wenn Sie die Telefonie mit Rufnummern über Direct Routing selbst bereitstellen, könnten Sie einen eingehenden Anruf auch serverseitig an ihr CRM melden lassen und der CRM-Service könnte auf dem Client eine entsprechende Aktion komplett losgelöst von Teams auslösen. Das funktioniert allerdings nicht mehr mit Call Queues, da der SBC selbst nicht weiß, welcher Agent den Ruf angenommen hat
  • Parallel-Call
    Eine andere Variante besteht daraus, dass der Anwender einen Parallelanruf in Teams auf eine besondere Rufnummer einstellt. Dort wartet dann einfach ein SIP-Client, der über einen INVITE sowohl die Rufnummer des Anrufers als auch des angerufenen Teilnehmers erfährt. Dieser Bot sollte natürlich den Anruf nicht annehmen sondern nur beim Anwender die CRM-Applikation aufwecken.
  • Subscription/BOT
    Natürlich könnten sie auch einen BOT schreiben, der sich bei allen Benutzern anmeldet, um so über eingehende Rufe informiert zu werden und wiederrum dem CRM-System einen Trigger zu geben.

Alle drei Optionen beruhen aber darauf, dass es eine Schnittstelle zu CRM-System gibt, welches dann initiiert durch den Server auf dem Client eine Aktion durchführt. Es gibt aber noch eine weitere Option.

  • Teams Client API
    Es gibt tatsächlich eine Client-API, über die eine 3rd Party Software mit dem Teams Desktop Client interagieren kann.
    Ein Beispiel ist dazu die Freeware "LyncWizard", die auf dem Arbeitsplatz-PC sich in den Teams-Client einklinkt und auf eingehende Anrufe die entsprechenden Aktionen auslösen kann.
    https://www.lyncwizard.com/products.html#TeamsWizard_Action

Auch andere Produkte können sich mit Teams integriere. Microsoft Dynamics nutzr aber nicht den Call Handler, welcher auf dieser Seite beschrieben ist

Einschätzung

Es hat leider mehrere Jahre gedauert, bis Microsoft in Teams eine so häufig nachgefragte und auf jeden Fall erforderliche Funktion eingebaut hat. Sie müssen diese nicht nutzen aber wenn sie eine Kontaktnachverfolgung haben, die per Browser mit einer URL gestartet werden kann, dann sollten Sie die Funktion für einige Pilotbenutzer mit einer eigenen Calling-Policy bereitstellen und nach ausführlichen Tests für alle Anwender ausrollen. Wenn ein Anwender die Funktion wirklich nicht möchte, können Sie dies serverseitig unterbinden oder dem Anwender die Wahl lassen.

Weitere Links