Missed Call

Beim Einsatz von Lync als Telefonie-Lösung kommt früher oder später auch die Frage, wie man als Nutzer verpasst Anrufe erkennen kann. Ein (Komfort-)Tischtelefon ist ja 24h angeschaltet und kann daher nicht nur die Anrufe melden, auch wenn der PC aus ist sondern auch speichern, wer wann angerufen hat. Das kann ein PC natürlich nicht, wenn er nicht eingeschaltet ist und der Lync Server speichert das auch nicht. Diese Seite will Licht ins Dunkel bringen. Allerdings gibt es ganz viele Kombinationen aus Anrufern, Zustand des Clients (Angemeldet, Abgemeldet, DND, Am Telefon), der Anzahl der Clients, Routing (Voicemail, Parallel-Call, Weiterleitung, Team-Call etc.), so dass ein "Nichtantworten" nicht immer auch eine Information an den Client generieren muss. Ich beschränke mich daher auf eine Teilmenge der möglichen Kombinationen.

Seit Okt 2015 gab es mit dem Updates KB3101496 das Problem, dass die Missed Calls nicht mehr in einer Umgebung ohne Exchange gehen. Deinstallation half. Mittlerweile gibt es ein Update.
3114732 February 9, 2016, Update für Lync 2013 (Skype für Business)
3136400 No missed call notification generated in Lync 2013 (Skype für Business)

Im Prinzip kann ein Client schon erkennen, dass der Benutzer nicht "UM-Enabled" ist und dann auf dem Client die "Missed Call Notification" erstellen und per MAPI oder EWS in das Postfach legen.

  • Clients ohne Exchange
    Nicht alle Clients sind auch fähig, Outlook oder EWS zu nutzen, z.B. einfache Telefone oder ein SkypefB Client, der kein Outlook installiert hat oder wo Outlook Profil und SIP-Adresse nicht übereinstimmen.
  • Mehrere Clients
    Ein andere Problemstellung sind Benutzer, die an mehreren Clients angemeldet sind. Wenn jeder Client den verpassten Anruf meldet, dann gibt es doppelte Messages.

Insofern ist eine serverseitige Generierung der sauberstes Weg. Aktuell macht das nur der Exchange UM-Server, wenn der Anwender auch für Exchange UM aktiviert ist. Vielleicht wird das irgendwann mal ein Skype für Business Server selbst machen.

Grundprinzip

Wie bei SIP üblich sendet der Anrufer einen INVITE an seinen Registrar, der wie im folgenden Beispiel auch gleich den Empfänger "kennt". Es kann aber durchaus sein, dass weitere Zwischenstationen vorhanden sind, z.B. beim Anruf über Federation oder mehrere Pools. Der Registrar sendet den INVITE dann direkt an die angemeldeten Endpunkte:

Das Verhalten ist mit SNOOPER und dem Lync Trace sehr einfach zu verfolgen:

Die grüne Stelle umrahmt das letzte 200OK und anhand der Zeit sehen sie, dass Nach ca. 20 Sekunden der Lync Server aktiv das Gespräch unterbricht. Ein klassischer "Verpasster Anruf". Der Anrufer bekommt in der Regel ein "Besetzt"-Zeichen am Telefon signalisiert. Länger als 60 Sekunden "durchklingeln" ist in Lync nicht einstellbar.

Ein zweiter Fall liegt vor, wenn der Anrufer den Ruf abbricht. Im Log auf dem gerufenen Client ist der eingehende CANCEL schön zu sehen.

Der Client quittiert dies mit einem "487 Request Terminated".

Der letzte Fall besteht darin, dass der Client gar nicht angemeldet ist. Hier kann der Server dann sofort einen "480 Temporarily not availible" an den Anrufer senden.

Erst wenn wieder Exchange  UM dazu kommt, dann wird das Bild etwas aufwändiger, da hier der Lync Server nach der vom Anwender eingestellten Zeit den Ruf an die Endpunkte mit einem CANCEL abbricht und dem Anrufer per "302 Moved Temporary" den Weg zum Exchange UM-.Server weist:

Zudem nutzt Exchange 2010 einen UM-Watcher-Prozess, der auf Port 5061 lauscht und Anfragen an seine beiden "Worker" auf anderen Ports weiter gibt. Der Watcher kann die Worker auch durchstarten, wenn Sie zu viel Speicher verbrauchen.

Missed Call Notification

Interessant wird das ganze nun, wenn wir gerne die Information über verpasste Anrufe hätten. Der Lync Server speichert diese Daten nicht und auch der Client könnte diese Daten nur dann speichern, wenn er aktiv ist. Im letzten Fall sicher nicht. Aber auch Exchange und die Lync Funktion spielen dabei mit.

Der Lync Client nutzt EWS, um sich mit dem Postfach zu verbinden und dort die Informationen über verpasste Anrufe dort zu speichern. Ohne Postfach kann Lync diese Informationen nicht im Postfach anlegen und die Anzeige bei "Verpasste Anrufe" bleibt leer. Sobald der Lync Client aber ein Postfach bekommt, liefert der Client die Daten nach! Das passiert selbst dann, wenn der Anwender gar kein Postfach hat und erst nachträglich "Mailbox aktiviert" wird. Ich habe noch nicht nachgeschaut, wo der Lync Client diese Informationen für wie lange puffert.
Schade nur, dass der Lync Client das nicht ohne Outlook und Postfach anzeigt.

Entsprechend sieht die Tabelle der Funktionen ziemlich einfach aus.

Lync user Anrufer legt auf Timeout Client offline

PC Audio Only

Keine Info

Keine Info

Keine Information

Enterprise Voice

Keine Info

Keine Info

Keine Information

PC Audio Only mit Mailbox

Lync Client legt Info an

Lync Client legt Information an

Keine Information

Enterprise Voice mit Mailbox

Lync Client legt Info an

Lync Client legt Information an

Keine Information

PC Audio Only mit UM Mailbox

Nicht getestet, denn was soll jemand mit VoiceMail, wenn er nicht telefonieren darf ?

Enterprise Voice mit UM-Mailbox

Exchange UM sendet MissedCall

Exchange UM beantwortet Voicemail nach Timeout

Exchange UM beantwortet Voicemail sofort

Sie können gut sehen, dass erst die Kombination mit Exchange UM die volle Funktion bereit stellt, d.h. dass der Anwender einen verpassten Anruf durch einen Serverprozess gemeldet bekommt. Ohne Exchange UM bekommt der Anwender die Information über verpasste Anrufe nur, wenn der Lync Client aktiv ist und eine Verbindung mit dem Postfach vorhanden ist. Ohne Exchange Postfach gibt es keinerlei Informationen über verpasste Anrufe.

Testserie

Ich habe in einer Testserie einige Konstellationen durchgespielt und von einem externen Telefon den Lync-Benutzer mit verschiedenen Konfigurationszuständen angerufen.

Zieluser Lync Feature Exchange
Postfach
Ende durch Timeout Missed Call
Information
SIP Error
ms-diagnostics

Online

PC Only

Nein

Timeout

180 Sek

Nein

487 Request Terminated
52051; reason="Callee timeout on no response from caller"

Online

PC Only

Nein

Cancel

entfällt

Nein

487 Request terminated
5002;reason="Request was cancelled

Offline

PC Only

Nein

Sofort

Sofort

Nein

480 Temporarily unavailable
13014;reason="The routing rules did not result in a final response and callee is not enabled für Unified Messaging"

Online

EV user

Nein

Timeout

20 Sek

Nein

Lync Default Routing sendet nach 20 Sec ein CANCEL an den Anrufer
ms-diagnostics-public: 5025;reason="Cancel sent by application für INVITE client transaction.";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FDefaultRouting

Online

EV user

Nein

Cancel

entfällt

Nein

487 Request terminated
5002;reason="Request was cancelled

Offline

EV user

Nein

Sofort

Sofort

Nein

480 Temporarily unavailable
13014;reason="The routing rules did not result in a final response and callee is not enabled für Unified Messaging"

Online

EV user

Postfach
ohne UM

Timeout

20 Sek

Ja

Lync Default Routing sendet nach 20 Sec ein CANCEL an den Anrufer
ms-diagnostics-public: 5025;reason="Cancel sent by application für INVITE client transaction.";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FDefaultRouting
Lync Client generiert eine Information im Postfach

Online

EV user

Postfach
ohne UM

Cancel

entfällt

Ja

487 Request terminated
5002;reason="Request was cancelled
Lync Client generiert eine Information im Postfach

Offline

EV user

Postfach
ohne UM

Sofort

entfällt

Nein

480 Temporarily unavailable
13014;reason="The routing rules did not result in a final response and callee is not enabled für Unified Messaging"

Online

EV user

UM Postfach

Timeout

20 Sek

Ja
Anrufer kann Voicemail

Anruf wird von Exchange UM angenommen. Anrufer kann Nachricht hinterlassen

Online

EV user

UM Postfach

Cancel

entfällt

Ja aber keine Voicemail

Exchange UM bekommt den Call vom Lync Server gemeldet und erstellt eine Information.

Offline

EV user

UM Postfach

Sofort

entfällt

Ja
Anrufer kann Voicemail

Anruf wird von Exchange UM angenommen. Anrufer kann Nachricht hinterlassen.

Timeout im Client: 20, 60 oder 180 Sekunden ?

Wenn Sie in der Tabelle der Testfälle genau hinschauen, dann erkennen Sie das Thema "Timeout", ab wann der Lync Server den Anruf mit einem "besetzt" beendet oder auf die Exchange Voicemail weiter leitet. Solange der Benutzer nur "PC Audio" aktiviert hat, kann der Anwender den Timeout gar nicht beeinflussen. Er scheint auf 180 Minuten fest gezurrt zu sein. Erst wenn der Benutzer für "Enterprise Voice" aktiviert ist, gibt es im Client überhaupt erst die Möglichkeit die Anrufweiterleitung zu konfigurieren. Und dann ist der Default auf 20 Sekunden gestellt.

Wer für Exchange UM aktiviert ist, bei dem wird das "Kein" durch "Voicemail" ersetzt

Es ist meines Wissens nicht möglich, mit einer aktiven VoiceMail die automatische Weiterleitung auf diese temporär zu unterdrücken.

Diese Einstellungen werden vom Client an den Server übermittelt. Über das Logging können Sie schon den "SERVICE"-Request sehen, wenn Sie auf dem Client die Einstellung anpassen.

Das bedeutet aber auch, dass der Server diese Information kennt und der Server auch die Verbindung verwaltet. Der Lync Server ist ja die Instanz, die im Gegensatz zum Lync Client permanent aktiv ist und daher einen Anruf gemäß der Einstellungen entsprechend umleiten kann. Neben den einfachen Weiterleitungen auf die Voicemail sind hier auch Teamanrufergruppen und ParallelCall hinterlegt.

Missed Conversation

Ein verpasster Anruf darf nicht mit einer verpassten IM verwechselt werden. Eine Textmeldung kommt nur an, wenn auch ein Client online ist, der diese anzeigen kann.

In dem Fall "Posted" der Lync Client die Information über die verpasste Meldung direkt in den Posteingang des verbundenen Postfachs, so dass Sie die Konversation später wieder aufnehmen können.

Missed Call und "Secondary Calls"

Es ist versteht sich von selbst, dass ein direkter Anruf auf mich als Ziel, die von niemandem angenommen werden, als "Missed Call" gemeldet werden. Aber es gibt ein paar weitere Fälle.

  • Ruf wird anderweitig beantwortet
    Wenn ich direkt angerufen werde und ich habe eingerichtet, dass meine Rufe parallel z.B. auf meinem Mobiltelefon oder bei einem Team oder einem Stellvertreter klingeln, dann kann kann der andere Teilnehmer oder ich an einem zweiten Gerät den Ruf annehmen. Lync sendet dann an alle anderen Endpunkte, die parallel mit klingen ein SIP:"CANCEL , Accepted Elsewhere", damit diese nicht weiter klingeln. Nach meinem Verständnis sollten dann natürlich die Endgeräte, die mit geklingelt haben, keinen Missed Call mehr anzeigen.
  • Sekundärer Ruf als Team, Stellvertreter, Weiterleitung, Responsegroup
    Wenn ich selbst z.B. Mitglied einer Responsegroup bin oder als Teammitglieder oder Stellvertreter nach einiger Zeit einen Anrufe gemeldet bekomme, dann erwarte ihc nicht, dass dieser Anruf in meinen "Missed Calls" auftaucht, wenn ich den Ruf dann nicht annehme.

Wer Lync mit Telefonie betreibt und ExchangeUM als Mailbox hat, erwartet eigentlich gar nicht, dass die Endgeräte selbst Buch über eingegangene und Verpasste Anrufe führen, sondern diese Aufgabe Exchange überlassen und einfach dort nach "ungelesenen VoiceMails" und "Verpassten Anrufen" nachschauen. Das hätte auch den Vorteil, dass ein Endgerät den Status immer aktuell anzeigen kann, also auch dann, wenn das Gerät im Moment des Anrufs gar nicht "online" war oder die verpassten Anrufe mittlerweile vom Anwender schon anderswo bearbeitet wurden.

Allerdings haben immer noch gerade die Telefone (Snom, Polycom, Audiocodes) oft noch die Einschränkung, dass Sie zum einen auch sekundäre Calls als "Missed Call" anzeigen und der Zugriff auf das Exchange Postfach natürlich nicht bei einer Anmeldung per Extension/Pin möglich ist. Noch ( Stand Anfang 2014) kann ein Client nicht per SIP den Lync Server fragen, im Postfach den Status "on behalf" abzufragen und Lync führt leider auch nicht selbst Buch über "Missed Calls"

Technisch kann ein Rufempfänger schon unterscheiden, ob der Anruf "Primär" ist oder z.B. als Responsegroup oder Teamanrufergruppe ankommt.

  • Response Group Agent
    Kommt ein Anruf als Mitglied einer Responsegroup (Response Group Service) an, dann sind folgende Felder im INVITE ein Hinweis darauf.
Contact: <sip:nawlync001.netatwork.de@netatwork.de;gruu;opaque=srvr:Microsoft.Rtc.Applications.Acd:JvgutxATQmiYbPkgAA>;automata;actor="attendant";text;audio;video;image;applicationsharing user-Agent: RTCC/5.0.0.0 Response_Group_Service 
history-info: <sip:rgtest2013@netatwork.de?Reason=SIP&cause=302&text=Accepted>;
   index=1;
   ms-retarget-reason=acd,<sip:frank.carius@netatwork.de>;
   index=1.1;
   ms-target-phone="tel:+495251304613;ext=613"
  • Teamanruf
    Mitarbeiter können einen "Parallelruf" (sofort oder verzögert) an ein Team einrichten. Dies ist aus meiner Sicht sinnvoller als Call Pickup. Beim Teammitglied kommt folgendes an.
To: <sip:+495251304667@netatwork.de;user=phone>;epid=2385f4c267
Referred-By: <sip:frank.carius2@netatwork.de>;ms-identity="MIIBtAY....
history-info: <sip:frank.carius2@netatwork.de>;
   index=1;
   ms-retarget-reason=team-call;
   ms-target-phone="tel:+495251304667;ext=667",<sip:frank.carius@netatwork.de>;
   index=1.1;
   ms-target-phone="tel:+495251304613;ext=613"
  • Stellvertreter
    Die dritte Variante ist ein Anruf auf eine Person die mich als Stellvertreter eingetragen hat
To: <sip:+495251304667@netatwork.de;user=phone>;epid=2385f4c267
Referred-By: <sip:frank.carius2@netatwork.de>;ms-identity="MIlh....
history-info: <sip:frank.carius2@netatwork.de?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20Temporarily%22>;
   index=1;
   ms-retarget-reason=delegation;
   ms-target-phone="tel:+495251304667;ext=667",<sip:frank.carius@netatwork.de>;
   index=1.1;
   ms-target-phone="tel:+495251304613;ext=613"
  • Weiterleitung
    Bei der Weiterleitung ist die TO-Zeile immer noch das originale Ziel und nicht der das Weiterleitungsziel. Neben der History-Info gibt es nun aber auch noch einen
To: <sip:+495251304667@netatwork.de;user=phone>;epid=2385f4c267
CSeq: 62986 INVITE
Referred-By: <sip:frank.carius2@netatwork.de>;ms-identity="MIIBt.....
history-info: <sip:frank.carius2@netatwork.de?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20Temporarily%22>;index=1;
   ms-retarget-reason=forwarding;
   ms-target-phone="tel:+495251304667;ext=667",<sip:frank.carius@netatwork.de>;index=1.1;
   ms-target-phone="tel:+495251304613;ext=613

Bei allen vier Fällen ist gut zu sehen, dass die "history-Info" die maßgeblichen Informationen enthält. Der "Referred-by" ist aber bei der Response-Group nicht enthalten.

Das war noch nicht alles

Die Information auf dieser Seite sind zwar umfangreich und an einigen Stellen für den ein oder anderen auch zu detailliert. Dennoch gibt es noch viel beim Lync Routing zu entdecken, was hier noch nicht beschrieben ist. So z.B. das Verhalten mit mehreren Endpunkten, die Varianten mit Teamanrufergruppen, Stellvertretern und Parallelruf. Auch die neuen mobilen Clients spielen eine Rolle, da diese per uWCA als Lync Client agieren und bei Anrufen auch Endpunkte bedacht werden. Und natürlich bin ich neugierig, ob man den 60Sek Timeout als Maximum nicht weiter hochsetzen kann; vielleicht mit SEFAUtil.

Aktuell gibt es wohl Überlegungen, diese Timeouts höher setzen zu können. Gerade für das "Durchklingeln"" wäre es hilfreich. Ich würde mir auch wünschen, dass ich die Voicemail auch abschalten kann. Sobald ich Exchange UM habe, werden alle Anrufe nach spätestens 60 Sekunden auf die Voicemail geleitet. Das ist nicht in allen Fällen sinnvoll, z.B. wenn ich mein "Team" erst nach 50 Sekunden benachrichtigen lassen will.

Weitere Links