480 Temporarily Unavailable

Wenn ein Anrufer eine Gegenstelle erreichen möchte und diese gerade nicht angemeldet ist oder den Ruf zwar signalisiert bekommt aber nicht annimmt, dann sendet der Skype für Business Server nach einiger Zeit einen "480 Temporarily Unavailable" an den Anrufer. Wenn das Ziel ein Skype vor Business User mit "Enterprise Voice" und "Exchange UM" ist, dann bekommt dieser eine Mail mit den Informationen zum verpassten Anruf. Wenn das Ziel aber kein Exchange UM hat oder der Benutzer "nur" PC2PC Audio" aktiviert ist , dann bleibt nichts von dem versuchen Anruf übrig. Auf dieser Seite versuche ich, hierfür eine Lösung zu schaffen

Der Code zu dieser Aufgabenstellung hat es nie aus meiner Testumgebung raus geschafft und mittlerweile ist das Thema obsolet.

Problemstellung

Auf der Seite MissedCall habe ich gegenüber gestellt, in welchen Fällen ein Anwender genau eine "Missed Call Notification" bekommt. Und das ist bei Lync bzw. Skype für Business und Exchange UM nur dann der Fall, wenn zwei Faktoren erfüllt sind:;

  • Enterprise Voice Enabled
    Der Anwender muss also mit Skype für Business "telefonieren". PC2PC Audio reicht nicht
  • Exchange UM Enabled
    Die Missed-Call Notification wird von der Exchange UM-Rolle generiert. So funktioniert dies auch, wenn der angerufene Teilnehmer abgemeldet ist.

Das bedeutet im Umkehrschluss aber, dass alle anderen Anwender auf dieses nette Feature verzichten müssen. Und das ist nicht wirklich schön.

Mögliche APIs

Auf der Suche nach Lösungen sind mir zwei APIs aufgefallen, die dabei genutzt werden könnten:

  • MSPL
    Diese Serverskripte "sehen alles" und können entsprechend auf die SIP-Meldungen reagieren oder sogar verändern. Sie werden auf dem Frontend Server eingespielt
  • UCMA
    Über die Managed API kann sich ein Server "On Behalf" des Benutzers anmelden. Allerdings sehen die anderen Personen quasi nie ein "offline", wenn man dies nicht absichtlich programmiert. Ich kann mit aber vorstellen, dass es ziemlich viel Last ist, wenn eine Applikation sich mit jedem SIP-Konto anmeldet.

Beide haben leider den Nachteil, dass Sie nicht "Cloud-tauglich" sind, d.h. für Office 365 muss Microsoft selbst eine Lösung schaffen. Aber wer weiß, aktuell funktioniert CloudPBX auch noch nicht mit Exchange UM On-Prem, da die Office 365 Server keine Verbindung zum lokalen Exchange UM-Server aufbauen können. Ich könnte mir vorstellen, dass es hierfür auch einmal eine Lösung geben könnten.

Entwurf MSPL + Eventlog

Da das "Erkennen" eines 480-Pakets relativ einfach möglich sein sollte und MSPL von sich aus auch schon ins Eventlog schreiben kann, habe ich den Weg gewählt, über ein einfaches MSPL-Skript diese Aufgabe zu lösen.

  1. Ein MSPL-Skript loggt die Meldungen im Eventlog
    Um möglichst wenig Abhängigkeiten zu erhalten und ohne Queues o.ä., auszukommen, wird das Skript einfach jeden erkannten 480-Event ins Windows Eventlog des lokalen Server schreiben
  2. Event Watcher sendet Mail
    Ein zweiter komplett unabhängiger Prozess überwacht die Eventlogs bzw. wird von Windows aktiv gestartet und reagiert auf das Eventlog. Das Skript muss neben dem Anrufer auch das Ziel ermitteln, anhand der SIP-Adresse dann die passende Mailadresse finden und eine Mail mit der "Missed Call Message" erstellen und versenden. Um doppelte Mails zu verhindern, sollte das Skript nicht aktiv werden, wenn das Ziel für "ExchangeUM" und "Enterprise Voice" aktiviert ist.

Durch diese zweistufige Umsetzung dürfte das MSPL-Skript sehr überschaubar und unkompliziert bleiben und die Benachrichtigungskomponente könnte sogar zentralisiert erfolgen.

MSPL-Skript

Dieses Skript hat es über ein Sample in einer kleinen Lync 2013 Laborumgebung nicht hinaus geschafft. Mit Teams entfällt die Plattform, so dass ich hier keine weiteren Aktivitäten einplane

Eventlog zu Mail

Wenn die Meldung im Eventlog auftaucht, dann kann ein damit verbundenes PowerShell-Skript oder anderes Programm den Event auswerten und eine Mail senden.

Anzeige in Outlook und Co

Da es sich bei der Benachrichtigung einfach um eine Mail handelt, kann der Anwender diese Information überall und mit jedem Client anzeigen lassen. Die Funktion ist nicht einmal auf Exchange beschränkt.

Weitere Links