Busy - Besetzt

Beim normalen Telefon gibt es Leitungen oder zumindest B-Kanäle und die sind endlich. Haben Sie früher mit ihrem analogen Telefon ein Gespräch geführt, so hat ein zweiter Anrufer ganz selbstverständlich ein "Besetzt"-Zeichen bekommen. Mit der Einführung von ISDN war es aber nun ganz einfach möglich, über einen Anschluss sogar zwei Gespräche zu führen. In der moderneren Analogtechnik konnte ein Zweitanruf zumindest signalisiert werden und der Anwender konnte dann ebenfalls "Makeln". Bei VoIP gibt es nicht mehr die klassische Leitung und selbst eine langsame 10 MBit LAN-Verbindung hat genug Reserven für viele parallele Gespräche. Technisch kann bei einer bestehenden VoIP-Verbindung immer noch ein zweiter oder sogar dritter Anruf signalisiert werden. Und durch die leistungsfähigeren Telefone bzw. Softwareclients kann ein Anwender damit auch viel besser umgehen. Es bleibt daher nur die grundsätzliche Frage, wie ein Anwender überhaupt mit der Funktion umgehen kann, einen zweiten Anruf signalisiert zu bekommen.

Mit dem Skype for Business 2015 CU3 (Juli 2016) wurde die Funktion Busy on Busy Bestandteil des Servers.

In Skype for Business Online ist BoB noch nicht verfügbar aber angekündigt.

In der TK-Welt gibt es dazu Begriffe wie Anklopfen, Zweitanruf, etc. Und die meisten Telefone erlauben eine Einstellung durch den Anwender, ob ein zweiter Anruf als Anklopfen gemeldet oder der Anrufer ein "Besetzt"-Zeichen bekommen soll.

Besetzt bei VoIP ?

Auch wenn es das klassische "Besetzt" nicht gibt, kann ein VoIP-Endgerät auf einen zweiten eingehenden Anruf verschieden reagieren.

• Zweiten Anruf anzeigen
  z.B.: über einen "Anklopfton" im Headset und als Anzeige auf dem Bildschirm oder Display. Der aktuell telefonierende Anwender kann darauf reagieren. Das ist das "Standardverhalten bei Lync. Der Anwender bestimmt, was mit dem Ruf passiert.
• Abwurf auf Mailbox o.ä.
  Der Client kann den Anruf manuell oder automatisch sofort oder nach einer Zeit z.B. zu einem anderen Teilnehmer oder die Mailbox umleiten.
• Ablehnen mit "486 Busy here"
  In dem Fall bekommt der Lync Server die Information, dass dieser Endpunkt besetzt ist und bricht den Ruf in diese Richtung ab. Alle anderen Endpunkte können aber weiter klingel. Wer also neben dem PC mit Headset noch ein eigenständiges Telefon hat, wird weiter gestört.
• Anruf "still" unterdrücken
  Der Communicator kann dies nicht von Hause aus aber es gibt Zusatztools, die den eingehenden zweiten Anruf einfach "still" schalten.
• DND-Status setzen
  Eine andere, wenngleich nicht ganz saubere Option wäre die Zweckentfremdung von DND durch den Anwender oder eine Add-On, um den Status manuell auf DND zu stellen, so lange eine Telefonat besteht. Dann kämen auch keine Zeitanrufe nicht mehr durch. Aber leider werden auch andere Meldungen durch DND unterbunden.
• Server: Ruf gar nicht "forken"
  Ideal wäre natürlich, wenn der Server eine Einstellung des Clients verstehen würde und bei einem Status "Am Telefon" einen Zweitanruf gar nicht mehr an die Endpunkte signalisieren würde. Lync kann das noch nicht von Hause aus aber Drittprodukte rüsten diese Funktion auf dem Server nach. Sie nutzen dann in der Regel MSPL, um die SIP-Meldungen abzufangen und UCMA, um den Status des Ziels abzufragen.

Sonderfall Busy bei "kein Gerät erreichbar"

Einen Sonderfall gibt es bei VoIP genauso wie bei GSM aber in der Regel nicht beim normalen Telefon. Ein normales Telefon ist immer "an", auch wenn niemand davor sitzt. Ruft jemand also eine Nummer eines normalen Telefons an, dann klingelt es "immer" und hört auch erst auf, wenn der Anrufer entnervt auflegt oder ein Timeout den Zielserver zu einer Fehler veranlasst, die er an den Client zurück sendet. Bei einem VoIP Call kann der Client eine schöne Fehlermeldung liefern und die Audioverbindung wird in der Regel gar nicht mehr aufgebaut

Lync liefert dabei ein "480 Temporarily unavailable" an den Anrufer, wie man im SIP-Call gut sehen kann.

SIP/2.0 480 Temporarily unavailable
ms-User-logon-data: RemoteUser
From: "Carius, Frank"<sip:frank.carius@netatwork.de>;tag=45fbe21c09;epid=2385f4c267
To: <sip:frank.carius2@netatwork.de>;tag=30C6DB2183B0D584C42FB64FD08A1697
CSeq: 1 INVITE
ms-diagnostics: 13014;reason="The routing rules did not result in a final response 
and callee is not enabled für Unified Messaging";source="NAWLYNC001.MSXFAQ.DE";
Callee="frank.carius2@netatwork.de";appName="InboundRouting"
Server: InboundRouting/5.0.0.0

Wenn man auf dem Telefonnetz z.B. über ein Audiocodes Mediant so einen nicht angemeldeten Teilnehmer anruft, sieht es vergleichbar aus. Auf den 480 sendet der Mediant dann den ISDN Disconnect mit dem Cause Code 18

SIP/2.0 480 Temporarily unavailable
FROM: <sip:+49xxxxx@nawm1000.netatwork.de;User=phone>;tag=1c1106680607
TO: <sip:+495251304667@192.168.100.100;User=phone>;tag=4833f7e3b5;epid=803B6B3EA7
CSEQ: 1 INVITE
CALL-ID: 11066794837520137407@192.168.100.107
VIA: SIP/2.0/TCP 192.168.100.107;branch=z9hG4bKac1106702018;alias
CONTENT-LENGTH: 0


pstn send --> PSTNDisconnectCall() Trunk:0 Conn:255 BChannel:31 Reason:18 Loc:-1 Des:-1 rc:0

Leider gibt es zwar den passenden Q.850 Cause 18, aber der Anrufer bekommt dann dennoch einfach ein "Besetzt"-Zeichen. Er kann dies aber nicht von einem "echten besetzt" unterscheiden, was auf ein "486 Busy Here" kommt. Das ist natürlich nicht gerade ideal für Firmenanschlüsse. Letztlich obliegt es aber dem Mitarbeiter zu bestimmen, was mit Anrufen auf seine Nummer passiert, die er nicht annehmen kann. Dafür gibt es ja die Anrufweiterleitungen auf dem Client, die auf dem Server gespeichert und auch bei abgemeldeten Clients befolgt werden:

Unabhängig davon kann ein Gateway Administrator natürlich immer noch konfigurieren, dass aus den passenden SIP-Statuscode ein passender Q.850 Code ins Telefonnetz übermittelt wird, z.B.

Auf einem Mediant 1000 sieht das z.B. wie folgt aus

Hier weise ich der 480 (User not Available) den Q.850 Code 17 (BUSY) zu. Es gibt noch einige andere "Codes", die eventuell anders zugewiesen werden können. Das Problem dabei ist aber, dass die meisten Personen an einem Telefonhörer nur drei Töne unterscheiden: Freizeichen, Wähl-Ton, Besetz-Ton. Nur Telefone mit Display zeigen vielleicht eine sprechende Fehlermeldung an. Insofern muss man abwägen, ob ein ruf an eine nicht erreichbare Gegenstelle mit einem "BUSY" signalisiert wird, oder wirklich ein anderer Status verwendet wird.

Besser ist hier immer Weiterleitung des Anrufs auf einen anderen Teilnehmer während der eigenen Abwesenheit. Dies kann ein Administrator auch zentral z.B. durch SEFAUTIL einrichten. Allerdings sollte so eine Logik etwas schlauer sein, um Änderungen des Benutzers nur dann zu überschreiben, wenn er eben keine Weiterleitung aktiv hat.

• SIP Codes
• ISDN NetCause
• SIP-Status-Codes
  http://de.wikipedia.org/wiki/SIP-Status-Codes
• Hangup Causes - Q.850 to SIP Code Table
  http://wiki.freeswitch.org/wiki/Hangup_causes

Wie einfach ist einfach ?

Ehe sie nun MSDN studieren und behauten, dass Sie so eine einfache Lösung auf Basis von MSPL in ein paar Minuten selbst entwickelt, haben, sollten Sie die vielen Sonderfälle berücksichtigen. Zum einen gibt es schon sehr viele Hinweise und Beispiele im Internet, die genau das schon gemacht haben:

• MSPL
• Lync MSPL “Busy Here” Script Project
  http://voipnorm.blogspot.com/2012/02/lync-mspl-busy-on-busy-script-project.html
• lync User busy with one call
  http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/f5829e31-42bd-4a65-bf1a-4777c5c54770/
  Enthält auch ein MSPL-Script
• Send 486 Busy Here when in a call?
  http://social.microsoft.com/Forums/en-US/communicationsservertelephony/thread/d39a8fc0-7a8c-4ebf-9633-6d21bbd3d544
  OCS Routing Script

Zum anderen reicht es aber sicher nicht aus, einfach nur jeden INVITE zu untersuchen und diesen mit einem "486 Busy here" zu beantworten, wenn das Ziel vielleicht im Status "Busy, am Telefon" ist. Das wäre doch sehr einfach, aber ich gebe ihnen einfach ein paar Stichpunkte, die so ein Projekt sehr schnell umfangreich werden lassen:

• Erkennen von Telefon
  Zuerst müssen Sie sicher erkennen, dass der "INVITE" auch wirklich ein Audiogespräch ist. INVITE wird durchaus auch für andere Kommunikationen genutzt, so dass Sie wohl oder übel den SDP (Siehe ICE und Kandidaten) "parsen" müssen.
• Erkennen von "Zuschaltungen"
  Zudem müssen Sie überlegen, wie sie mit einer Erweiterung einer bestehenden Kommunikation umgehen. So kann bereits eine "Instant Messaging" oder sogar Desktop-Sharing-Sitzung bestehen, zu der dann Audio einfach dazu geschaltet wird.
• Responsegroup und Team
  Nicht immer wird ein Teilnehmer direkt "angerufen". Ein Client kann auch einen "Secondary Call" bekommen, z.B. weil er Agent in einer Responsegroup ist oder über die Funktion "TeamCall" einen Anruf an einen anderen Kollegen parallel signalisiert bekommt. Vielleicht ist es hier ja gewollt, dass der Zeitanruf sichtbar wird.
• Umleiten auf Voicemail
  Wenn Sie den Weg wählen, einen Anruf sofort z.B. auf Exchange UM zu leiten, wenn der Angerufene schon ein Telefon führt, dann ist genau die unterscheidung wichtig, ob es ein primärer direkter Anruf ist oder eben ein Responsegroup oder TeamCall-Invite.
• Anruf in Konferenz
  Wir möchten Sie einen Anruf handhaben, wenn Sie in einer Konferenz sind, ihr Status also "Busy, in Konferenz" lautet? Vorschnell könnte die Antwort auf "bitte nicht stören, Konferenz ist wichtig" lauten. Was aber, wenn der Anrufer genau der fehlende Teilnehmer ist, der sich nicht einwählen kann und den Sie als Zweitanruf einfach mit einem Mausklick annehmen und dann in die Konferenz aufnehmen könnten ?. Hier ist ein Zeitanruf wichtig.
• Unterscheidung nach Anrufer (Familie) oder Intern, Federation, TK-Amt
  Lync kennt die Möglichkeit, Personen (Buddies) unterschiedliche Berechtigungen zu geben. Wäre es nicht nett, wenn trotz eines aktiven Gesprächs ein Zweitanruf z.B. von der Tochter
• Temporäre Abschaltung
  Sie warten vielleicht auf einen wichtigen Anruf aber wollen in der Zwischenzeit natürlich nicht untätig sein. Sie telefonieren also wie gewohnt aber möchten diesen einen wichtigen Anrufer dann doch annehmen, indem Sie das andere Telefon schnell beenden. Eine Einstellmöglichkeit auf dem Client ist in dem Fall erforderlich.
• Besetzt während eines Verbindungsaufbau
  Ein Teilnehmer ist erst dann auf "On Phone", wenn das erste Telefonat schon steht. Wie verfahren sie mit dem Sonderfall, wenn es bei einem Teilnehmer schon klingelt und dann noch ein zweiter Ruf ankommt oder wenn jemand gerade ausgehend einen Ruf gestartet hat aber die Gegenseite noch nicht abgenommen hat. ? Auch wenn der Status dann noch nicht auf "Am Telefon" ist, sollte der Zweitanruf unterdrückbar sein.

Haben Sie nun immer noch Lust auf eine schnelle MSPL-Lösung?

Produkte

Zwar hat Microsoft mit Lync eine sehr leistungsfähige Kommunikationsstruktur bereit gestellt, aber leider gibt es aktuell noch keine Lösung "an Bord", die eine alternative Behandlung eines Zweitanrufs zulässt. So haben sich mittlerweile mehrere Firmen mit Eigenentwicklungen daran gemacht, diese Funktion über jeweils unterschiedliche Ansätze nachzurüsten. Es gibt auch einige "Skript Only" Lösungen, die die Funktion erlauben, aber durch den Anwender nicht steuerbar sind und Support ist hier auch fraglich. Einige kommerzielle Lösungen kombinieren mehrere Funktionen in einem Produkt.

Gerade die serverseitigen Versionen nutzen MSPL und müssen in der Regel auf jedem Lync Server installiert werden. Codefehler wirken sich hier extrem aus, so dass die Qualität wirklich hoch sein muss, vergleichbar zu SMTP-Transportagenten bei Exchange. Client-Only Lösungen hingegen müssen natürlich auch verteilt und gepflegt werden und funktionieren z.B. nicht Lync-Telefonen. Die Auswahl ist dadurch nicht einfacher.

Liste wird noch erweitert

Weitere Links

• Busy on Busy
• MSPL
• ICE und Kandidaten
• SIP Codes
• SIP-Status-Codes
  http://de.wikipedia.org/wiki/SIP-Status-Codes