Busy on Busy

Das "Besetztzeichen" wurde lange von Anwendern und Administratoren gefordert, auch wenn es anscheinend eine typisch deutsche Angelegenheit ist. Wer US-Spielfilme kennt, weis schon immer um das "Anklopfen" und "Makeln" selbst auf analogen Leitungen. Aber mit dem Skype for Business 2015 CU3 (Jul 2016) hat Microsoft auch diese Funktion in den Server integriert, die bis dahin von Drittprodukten nachgerüstet wurden.

Für die Funktion ist es erforderlich, dass Sie mindestens Skype for Business Server mit CU3 Update von Juli 2016 installiert haben.. Siehe Skype4B Updates und 3061064 Updates for Skype for Business Server 2015.

Generelle Informationen zur Funktion "Besetzt" in SIP-Umfeldern finden Sie auf Busy - Besetzt

Einrichtung

Die erste Voraussetzung ist natürlich, dass Sie Skype for Business Server 2015 OnPremise betreiben und das Juli 2016 Update oder neuer bereits installiert haben. Aber auch dann sind noch einige Schritte nachträglich erforderlich:

Die Funktion muss über die Voice-Policy für die entsprechenden Anwender überhaupt freigeschaltet werden. Voice-Polices können Global, pro Site oder pro User konfiguriert werden. Siehe dazu auch Lync Policies. Ich mache mir das Leben hier einfach und aktiviere die Funktion global. Ich sehe auch erst einmal keinen Grund, warum diese Funktion nicht für alle Endpunkte bereit stellen sollte.

Set-CsVoicePolicy -EnableBusyOptions $true

Sollte es aber eine Site oder User-Policy geben, dann überstimmt die natürlich die globale Richtlinie. Dann müssen Sie diese Einstellung auch dort noch aktivieren. Sie können die Einstellungen übrigens auch im Skype for Business Control Panel (CSCP) per Maus machen:

Die "Busy on Busy"-Funktion ist als separate Application implementiert, die zwar vorinstalliert aber eben noch nicht aktiviert ist. Sie wird "pro Pool" aktiviert. Wenn sie mehrere Pools haben, muss das auf jedem Pool aktiviert werden. Folgende kleine Schleife vereinfacht das

foreach ($pool in (Get-CsPool | ?{$_.services -like "registrar*"})){
   write-host ” Processing “ $pool.identity
   New-CsServerApplication `
      -Identity ('Service:Registrar:'+$pool.identity+'/BusyOptions') `
      -Uri 'http://www.microsoft.com/LCS/BusyOptions' `
      -Critical $False `
      -Enabled $True `
      -Priority (Get-CsServerApplication -Identity ('Service:Registrar:'+$pool.identity+'/UserServices')).Priority
}

Damit wird die Applikation auf den Pools aktiviert.

Die "Busy"-Funktion ist mit neuen Commandlets verbunden, die natürlich nicht von "jedem" ausgeführt werden dürfen.

Über den Befehl "Update-CsAdminRole" werden die RBAC-Rollen entsprechend angepasst.

Die Erweiterung des Skype for Business Frontend Servers um eine neue Applikation erfordert einen Neustart der Dienste. Genau genommen sollte der Neustart des RTCSRV ausreichend sein. Auf einem Standard Server ist dies schnell erledigt.

stop-cswindowsservice rtcsrv -graceful
start-cswindowsservice

Auf einem Enterprise Pool müssen Sie wieder mit Invoke-CSComputerFailover und Invoke-CSComputerFailBack arbeiten. Kontrollieren Sie dann das Windows Eventlog auf die Nummer 30253. Hier sehen Sie alle "Applikationen", die geladen wurden. Hier muss auch BusyOnBsy mit erscheinen:

Danach ist die allgemeine Einrichtung abgeschlossen.

Konfiguration des Anwenders

Mit der Aktivierung der "Busy"-Option auf dem Server sind die Vorarbeiten abgeschlossen. Der Benutzer kann aktuell aber nicht selbst einstellen, wie er auf ein "Besetzt" reagieren soll. Die Einstellung muss durch den Administrator auf dem Server erfolgen oder durch eine Provisioninglösung, die solche Einstellungen im Auftrag des Anwender machen kann. Microsoft sieht hier drei Optionen vor:

  1. Keine Busy-Einstellung
    Es bleibt alles wie es ist und Zweitanrufe werden gemeldet. Dies ist der Default
  2. Busy on Busy
    Wenn der Teilnehmer "Busy" ist dann wird ein eingehender Anruf mit einem Besetzt-Zeichen abgelehnt
  3. Voicemail on Busy
    Wenn der Teilnehmer "Busy" ist, dann wird der Anrufer auf die Voicemail (Exchange UM) umgeleitet. Die muss dazu natürlich eingerichtet sein.

Die Konfiguration der drei Optionen erfolgt aktuell nur per PowerShell. Leider ist die Einstellung kein zusätzliche Property mit Set-CSUser, sondern ein eigenes Commandlet und auch hier kann man die Option nur auf zwei der Werte setzen. Um den "Default" wieder zu erhalten, muss die Option entfernt werden:

Set-CsBusyOptions -Identity sip:user@msxfaq.de-ActionType BusyOnBusy
Set-CsBusyOptions -Identity sip:user@msxfaq.de -ActionType VoicemailOnBusy
Remove-CsBusyOptions -Identity sip:user@msxfaq.de

Das Commandlet prüft zwar nicht, ob für den Benutzer diese Option über seine Voice Policy überhaupt freigeschaltet ist, aber gibt "sicherheitshalber" eine Warnung aus.

Auch beim Auslesen der aktuellen Einstellungen für die Benutzer gibt es die ein oder andere Überraschung. Wenn bei einem Benutzer eine Option gesetzt ist, dann wird sie auch ausgegeben. Wenn die Option aber nicht gesetzt ist, dann wird ein Fehler generiert.

Das hätte Microsoft sicher besser machen können und statt des Fehlers einfach "Default" ausgeben können. Wer also einen Report generieren möchte, muss diesen Fehler entsprechend abfangen.

Die Zuweisung der Policy ist übrigens nicht an die Funktion "P2P AV" oder "Enterprise-Voice" gebunden. Die Option kann auch für Benutzer mit dem Status "Audio/Video disabled" gesetzt werden. Hier bringt sie natürlich nicht viel. Wer also nach der Umsetzung erst einmal alle Personen entsprechend behandeln will, kann das mit folgender Sequenz machen.

get-csuser `
   -resultsize unlimited `
   -Filter {HostingProvider -ne "sipfed.online.lync.com"} `
| Set-CSBusyOptions `
     -ActionType BusyOnBusy

Benutzer, die in einer Hybrid-Umgebung in der Cloud sind, können natürlich nicht mit dieser Option versorgt werden. Das Update der Einstellung bei einer größeren Anzahl an Benutzern kann durchaus länger dauern, da es hierbei nicht um die Änderung eines Felds beim AD-Objekt geht, sondern die Daten in der Skype for Business Datenbank hinterlegt werden.

Änderungen an den Einstellungen eines Benutzers werden quasi "sofort" aktiv, aber betreffen nur "neu eingehende Calls". Wenn ich also einen Call noch klingeln lasse und dann meine Option auf BusyOnBusy umstelle, dann wird der aktuelle Ruf nicht abgebrochen. Das gilt auch, wenn ich z.B.: meinen Status von "Verfügbar" auf "Busy" stelle oder eine Konferenz starte. Die Entscheidung wird also nur beim ersten INVITE des Anrufs auf dem Frontend gefällt.

Sie können eine Option übrigens mehrfach setzen. Das Commandlet bringt keine Rückmeldung, wenn die Einstellung schon vorher vorhanden war und daher nicht geändert werden musste. 

1:1 Telefonate

Natürlich habe ich eine Testserie mit dieser neuen Funktion gemacht und meine Benutzer in die verschiedenen Statusmeldungen gesetzt und einen Zweianruf gestartet. Das waren die Ergebnisse für mein Konto, welches natürlich Exchange UM hat.

Mein Status Kein Busy On Busy (Default) Busy On Busy Voicemail On Busy Bemerkung
Offline

Kein Anruf, Voicemail nach Clienteinstellung

Kein Anruf, Voicemail nach Clienteinstellung

Kein Anruf, Voicemail nach Clienteinstellung

Unveränderte Funktion

Appear Offline

Klingelt, Voicemail nach Clienteinstellung

Klingelt, Voicemail nach Clienteinstellung

Klingelt, Voicemail nach Clienteinstellung

Unveränderte Funktion

Bereit

Klingelt, Voicemail nach Clienteinstellung  

Klingelt, Voicemail nach Clienteinstellung 

Klingelt, Voicemail nach Clienteinstellung 

Unveränderte Funktion 

Busy (Manuell)

Klingelt, Voicemail nach Clienteinstellung  

Klingelt, Voicemail nach Clienteinstellung  

Klingelt, Voicemail nach Clienteinstellung

Unveränderte Funktion 

Busy (Outlook Meeting)

Klingelt, Voicemail nach Clienteinstellung  

Klingelt, Voicemail nach Clienteinstellung  

Klingelt, Voicemail nach Clienteinstellung 

Unveränderte Funktion 

Busy (Telefonkonferenz)

Klingelt, Voicemail nach Clienteinstellung  

"Besetzt"

Sofort VoiceMail

Besetzt ist neu

Busy (In a Call)

Klingelt, Voicemail nach Clienteinstellung  

"Besetzt"

Sofort VoiceMail 

Besetzt ist neu

DND

nur Teammitglieder/Familie, sonst
sofort VoiceMail, wenn konfiguriert

nur Teammitglieder/Familie, sonst
sofort VoiceMail, wenn konfiguriert

nur Teammitglieder/Familie, sonst
sofort VoiceMail, wenn konfiguriert

Unveränderte Funktion 

Abwesend

Klingelt, Voicemail nach Clienteinstellung 

Klingelt, Voicemail nach Clienteinstellung 

Klingelt, Voicemail nach Clienteinstellung

Unveränderte Funktion 

Der Begriff "Busy" bezieht sich nur ein ein "Busy In Ccall" oder "Busy In Meeting", d.h. wenn der angerufene Teilnehmer wirklich auch ein Telefonat führt. Wenn der Anwender einfach nur Busy ist, dann kommen die Anrufe weiter durch.

Interessant ist in dem Zuge auch noch die Anzeige auf dem Client, bei einem "Federation-Call". Auch hier kommt der "486 Busy Here" und wird vom Skype for Business Client auch problemlos interpretiert und angezeigt:

Die Meldung können Sie auch auf dem UCCAPI-Log des Clients sehen. Hier kommt ein "486 Busy here" und der Server ist "BusyOptions"

07/12/2016|14:43:08.572 254C:29F8 INFO  :: Data Received -80.66.20.22:443 (To Local Address: 10.138.122.72:49887) 989 bytes:
07/12/2016|14:43:08.572 254C:29F8 INFO  :: SIP/2.0 486 Busy Here
ms-user-logon-data: RemoteUser
Authentication-Info: TLS-DSK qop="auth", opaque="D6AF7EE3"
Content-Length: 0
Via: SIP/2.0/TLS 10.138.122.72:49887;received=88.128.80.185;ms-received-port=41538;ms-received-cid=9F6B100
From: "User1"<sip:user1@netatwork.de>;tag=8ea09bf2e6;epid=2385f4c267
To: <sip:user2@msxfaq.net>;tag=C643D79595F545B
Call-ID: 734ea4e359617902c2098433b
CSeq: 1 INVITE
Server: BusyOptions/6.0.0.0
ms-diagnostics: 
   1034;reason="Previous hop federated peer did not report diagnostic information";
   Domain="msxfaq.net";
   PeerServer="sip.msxfaq.net";
   source="sip.netatwork.de"
ms-edge-proxy-message-trust: 
   ms-source-type=AutoFederation;
   ms-ep-fqdn=nawsfbedge.netatwork.de;
   ms-source-network=federation;
ms-source-verified-user=verified

Sonderfälle

Dann gibt es noch einige andere Fragestellungen in dem Umfeld.

Thema Auswirkungen auf die Funktion

Pool Failover

Die Einstellungen werden auch auf den Backup Pool übertragen und wirken nach einem Failover auch dort

SBA/SBS

Auch Benutzer auf einer SBA können die Funktion nutzen.

Anrufe "gehalten"

Es ist egal, ob der angerufene Teilnehmer ein aktives Gespräch oder ein "gehaltenes" Gespräch hat. Er ist Busy.

MPOP-Support

Ein Anwender kann ruhig auf mehreren Endgeräten angemeldet sein. Die Funktion orientiert sich am aktuellen Status des Benutzers auf dem Registrar.

PrivateLine

Neben der "primären Nummer" kann ein Anwender noch eine Zweitnummer haben. Wenn ich aber im Gespräch bin, dann wird ein Anruf auf die PrivatNummer auch mit einem "Besetzt" gemeldet.

Shared Line

Dessen Einstellung scheint die individuellen Einstellungen zu überstimmen. Hier zählt die Einstellung der SharedLine, d.h. wenn dort BusyOnBusy aktiviert ist, dann gilt das für Anrufe an die ShareLine.

Geparkte Anrufe

Wenn ein Anruf von einem Mitarbeiter geparkt wurde aber wegen "Nich Abholen" wieder zum Parkenden zurück verwiesen wird, dann klingt es dort, auch wenn BusyOnBusy/VoiceMail aktiv ist.

Missed Call Meldung

Wenn ein Anruf als "Busy" abgelehnt wird, dann erhält der Anwender eine Meldung über den "verpassten" Anruf.

Anruf per Skype Federation

Hier gelten die gleichen Regeln wie bei einem Anruf per Telefonnetz. Durch die durchgängige Nutzung von SIP kann aber das "486 Busy Here" bis zum Anrufer zurück gegeben werden und dieser sieht dann, dass die Gegenseite "besetzt" ist.

Team-Call, Boss/Admin

Die Busy On Busy-Einstellungen wirken nur für direkte Anrufe auf mein Endgerät. Alle anderen "sekundären" Anrufen werden entsprechend meines Status wie bisher behandelt, d.h. es gibt weiterhin "Zeitanrufe". Es wäre auch nicht sinnvoll, wen ich als TeamCall oder Delegate ein "BUSY" senden würde und damit den Ruf abweise und andere Mitglieder den Ruf nicht mehr annehmen könnten

ResponseGroup

Wenn hier jemand einfach auf Busy ist, dann wird er weiter angerufen. Ein RGS-Call wird nicht an Mitglieder gemeldet, die gerade im Gespräch sind. (also kein Zeitanruf). Der Anrufer bekommt aber kein Busy, sondern wird gemäß der RGS-Workflows, Queues und Gruppen weiter gereicht.

Parallelruf und Busy

Wenn Sie einen Parallelruf z.B. auf ihr SmartPhone oder ein anderes Telefon eingestellt haben und mit Skype for Business gerade telefonieren, dann wird der Anruf nicht am zweiten Gerät gemeldet, sondern auch als "Busy" abgelehnt.

Hinweis: Bei mir funktioniert genau das nicht. Wenn ich "SimRing" aktiv habe, klingelt es immer

Kein Comon Area Phone

Bus on Busy wird nicht mit Common Area-Teilnehmern unterstützt. Die Klingeln also immer.

ConferenzInvite

Wenn ich in einem Gespräch bin., und mich aber jemand anderes in eine Konferenz einladen will, d.h. ich bekomme einen Anruf von der KonferenzMCU, dann wird mir der auch gemeldet, wenn ich "Busy" bin. So habe ich die Möglichkeit einen aktuellen Anruf abzubrechen um in eine wichtige Konferenz zu wechseln.

SecondaryCall

Eine Anruf, den ich als "zweiter" bekomme, weil ich z.B. IN der Teamanrufergruppe eines Kollegen bin, wird mir nicht gemeldet, wenn ich Busy" bin

Diese kleine Liste soll ihnen auch zeigen, dass das Thema "Besetzt melden" gar nicht so einfach ist, wie es auf den ersten Blick erscheint. 

Diese Zusammenhänge beschreiben meine individuellen Erfahrungen. Es kann durchaus sein, dass die Funktion im Laufe der Zeit verändert wird.

Intern

Die Einrichtung mit "New-CSServerApplication" hat natürlich meine Neugierde geweckt und wie nicht anders zu erwarten, gibt es eine entsprechende AM-Datei, die ein MSPL-Skript enthält, welches die SIP-Pakete inspiziert.

Das AM-File können Sie mit jedem Texteditor anschauen und mit etwas Übung auch sehen, was hier passiert. Das MSPL-Skript protokolliert Ausgaben zum APILogger. (Siehe auch MSPL)

Wenn ich es richtig gesehen habe, dann verbindet sich die Powershell per LDAP mit dem AD und per 1433 auf den SQL-Server. Die Einstellungen zu "Busy On Busy" liegen zumindest nicht beim Active Directory Objekt des Benutzers und werden daher auch nicht über den UserReplicator erst in die SQL-Datenbank übertragen. Allerdings sind die Daten natürlich verschlüsselt.

Bei der Analyse ist mit auch noch eine Besonderheit aufgefallen. Ich habe die Skype for Business Powershell auf einem eigenen PC installiert um per Netmon die Verbindungen besser analysieren zu können. Und hier bin ich auf einen Fehler gelaufen

Set-CsBusyOptions : The operation failed due to issues with Tls. See the exception for more information.
 

PS C:\> $Error[0].Exception.StackTrace
   at Microsoft.Rtc.Signaling.RealTimeServerTlsConnectionManager.SetDefaultTlsTuple()
   at Microsoft.Rtc.Signaling.RealTimeServerTlsConnectionManager.SetLocalCertificate(
         String certificateIssuerName, Byte[] certificateSerialNumber)
   at Microsoft.Rtc.Collaboration.CollaborationPlatform.CreateConnectionManager(
         ITraceFilterConfiguration traceFilterConfiguration, PoolConfiguration poolConfiguration)
   at Microsoft.Rtc.Collaboration.CollaborationPlatform.Initialize(
         CollaborationPlatformSettings platformSettings)
   at Microsoft.Rtc.Collaboration.CollaborationPlatform.Initialize(
         CommonApplicationPlatformSettings platformSettings)
   at Microsoft.Rtc.Collaboration.CollaborationPlatform..ctor(
         ServerPlatformSettings platformSettings)
   at Microsoft.Rtc.SyntheticTransactions.SyntheticTransactionCollaborationPlatform.
         CreateAndInitializeServerPlatform()
   at Microsoft.Rtc.SyntheticTransactions.SyntheticTransactionCollaborationPlatform.
         get_ServerCollaborationPlatform()
   at Microsoft.Rtc.Management.Internal.PreambleBaseCmdlet`1.GetCollaborationPlatform()
   at Microsoft.Rtc.Management.Internal.PreambleBaseCmdlet`1.InitializePlatform()
   at Microsoft.Rtc.Management.Internal.PreambleBaseCmdlet`1.InternalProcessRecord()
   at Microsoft.Rtc.Management.AD.ADTask`1.CmdletProcessRecord()
   at Microsoft.Rtc.Management.OcsCmdlet.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()

Sie man sieht, ist es zuerst einmal ein TLS-Fehler, der sich aber durch den Start der PowerShell als "Administrator" lösen lässt. Anscheinend kommt mein normaler Anwender /UAC ist aktiv) nicht an den privaten Schlüssel des Zertifikats, um sich damit gegenüber dem Server auszuweisen. Das Problem besteht nicht, wenn Sie gleich eine "Remote Powershell" aufmachen.

Performance Counter

Bei der Untersuchung nach neuen Dateien ist mir natürlich auch die Datei "BusyOptionsPerf.dll" aufgefallen. Ein Blick in Perfmon zeigt, dass auch diese neue Option ein paar Counter mitbringt, die Sie auswerten können:

Mehr als ein paar Zahlen ist hier aber nicht zu holen.

Eventlog

Leider gibt es weder von dem MSPL-Skript noch von dem EXE weitergehende Meldungen im Eventlog. Das habe ich aber auch gar nicht erwartet, dass jede Aktivität mir das Eventlog füllt. Das hier ist also der falsche Platz. Allerdings finde sich hier zumindest der Event 30253 im Lync Server Eventlog, der beim Start des Frontend Servers anzeigt, welche Applications geladen werden.

OCSLogger

Leider installiert das CU3 kein eigenes Szenario für den CLS-Logger. Aber Microsoft hat in seiner Anleitung ein entsprechendes PowerShell-Script veröffentlich, welches ich hier übernommen habe^.

$p1 = New-CsClsProvider `
   -Name S4 `
   -Type WPP `
   -Level Info `
   -Flags All
$p2 = New-CsClsProvider `
   -Name Sipstack `
   -Type WPP `
   -Level Info `
   -Flags "TF_PROTOCOL,TF_CONNECTION,TF_SECURITY,TF_DIAG,TF_SHOW_CONFERENCE,TF_SHOW_ALLREQUESTS,TF_SHOW_ALLSIPHEADERS" `
   -Role Registrar
$p3 = New-CsClsProvider `
   -Name BusyOptions `
   -Type WPP `
   -Level Verbose `
   -Flags All
New-CsClsScenario `
   -Parent Global `
   -Name BusyOptions `
   -Provider @{Add=$p1,$p2,$p3}

# Ausgabe
Identity : Global/BusyOptions
Provider : {Name=S4;Type=WPP;Level=Info;Flags=All;Guid=;Role=, Name=Sipstack;Ty
pe=WPP;Level=Info;Flags=TF_PROTOCOL,TF_CONNECTION,TF_SECURITY,TF_DIA
G,TF_SHOW_CONFERENCE,TF_SHOW_ALLREQUESTS,TF_SHOW_ALLSIPHEADERS;Guid=
;Role=Registrar,
Name=BusyOptions;Type=WPP;Level=Verbose;Flags=All;Guid=;Role=}
Name : BusyOptions

Es legt quasi drei CLSProvider-Einstellungen an, die für die Aufzeichnung der relevanten Quellen erforderlich sind und generiert dann im vierten Schritt ein Scenario. Das können Sie dann im CLSLogger einfach auswählen.

 

Mit diesem Szenario zeichnen die Skype for Business Server dann nur die Events auf, die für die Fehlersuche relevant sind. Die Anzeige erfolgt dann natürlich wieder mit Snooper, Notepad oder einem anderen Tool ihrer Wahl.

Busy Logs auswerten

Wenn Sie dann mit dem Logger so eine Textdatei haben, dann ist die Auswertung und Suche darin die eigentliche Herausforderung. Wenn man aber im Log schaut, dann findet man viele Zeilen, die den gleichen String "BusyOnBusy" und "BusyOptions" verwenden:

Danach könnte ein Admin im Fehlerfall schon einmal suchen. Aber auch dann sind es noch sehr viele Zeilen. Ich habe mir folgende Codes gemerkt:

  • BusyOnBusy.OnSipAudioInvite
    Dieser String zeigt in der Regel einen neuen Call an. So finde ich schnell den Anrufer und das Ziel und ob der Eintrag für meinen Fall relevant ist. Interessant ist hier auch die CallID am Ende
  • BusyOptions,CallInfo.GetIsTeamCall
    Hier finden Sie dann die Informationen, ob dieser Anruf ein TeamCall war
  • BusyOptions,CallInfo.GetIsRgsCall
    Auch die Abfrage, ob es sich um einen "ResponsegroupCall" handelt, ist nützlich
  • BusyOptions,CallInfo.GetIsDelegateCall
    Auch Anrufe weil ich Stellvertreter bin, werden gesondert ausgewertet
  • BusyOptions,CallInfo.ShouldPrioritizeCall
    Dieser Text verrät dann auf einmal das "Ergebnis" der Anfrage

    Hier ist gut zu sehen, dass der Anruf an mich dennoch signalisiert wurde, weil es ein Konferenzanruf war. In dem Beispiel war es ein "MeetNow", wo mein Client den Status schon "In Conference" gesetzt hatte. Ohne diese Logik wäre ich selbst nicht in meine Konferenz gekommen.

Microsoft hat also nicht nur eine neue Funktion addiert, sondern auch sehr gute Analysemöglichkeiten eingebaut.

Weitere Links