Rufsteuerung nach Status anderer NST mit Anzeige auf Telefon

[Ringo]

Es handelt sich um eine Schule.

Aufgabe:
- manuelle Steuerung der Erreichbarkeit für außer Bürozeit und Ferien. (Da die Anwesendheitszeiten variieren und auch in Ferien zeitweise das Büro besetzt ist soll es nicht automatisiert laufen)
- Standard ist dass nach Ansage 2 NST in Gruppe klingeln
- 4 NST wollen die Erreichbarkeit per BLF steuern und "etwas" auf dem Telefon dazu sehen

Mit der Lösung bin ich nicht ganz zufrieden. Geht bestimmt besser.

Für den Status wird eine Dummy-NST (33) genutzt
Problem war das der Webclient einen Status anzeigt aber auf dem Telefon nichts dargestellt wird. Telefone sind Yealink und zeigen von anderen NST nur wenn es klingelt oder telefoniert wird.

Meine Lösung sind meine ersten selbst erstellten CFD´s.

BLF 1 stellt den Dummy per Script auf "Custom 1" (ausser Bürozeit)
BLF 2 stellt den Dummy per Script auf "Custom 2" (Ferien)
Es unterscheiden sich nur die Weiterleitung zu den Ansagen
Jetzt brauchte ich noch die verlangte optische Anzeige auf den Telefonen. Weil die Stati der Dummy-NST nicht auf dem Telefonen zu sehen sind musste ich es irgendwie über "es klingelt dort bzw inCall" lösen.
Dummy ist dafür BLF 3 und heißt "Status Büro"

Beide Scripte legen nach der Umstellung auf und starten einen Call zu einem IVR.
Leider wird das immer nach 60sek vom System beendet.

Also habe ich das in eine Schleife gebaut die alle 55 sek den call beendet, den Status vom Dummy abfragt und wenn der noch "Custom" ist den nächsten Call startet.
Die Schleife wird verlassen sobald der Status vom Dummy auf etwas anderes gestellt wird.

BLF 4 stellt den Status vom Dummy auf "verfügbar" und die Scripte BLF 1+2 beenden sich daraufhin.

Das läuft und die 4 Nutzer sehen auf ihrem Telefon das der Status Büro nicht verfügbar ist und sind zufrieden

Was mir nicht gefällt ist das jetzt natürlich jede Minute auch ein neuer Anruf im Protokoll steht. Kann man den Dummy irgend wie länger als 1 Minute "besetzt" halten oder gibt es eine elegantere Lösung? Dieser hat kein Endgerät. Die nötige Registrierung ist auf einem freien Port eines FXS (Grandstream HT818). Dass permanent ein aktiver Anruf ist stört nicht.
Ausserdem gehe ich ohne es getestet zu haben davon aus dass bei Stromausfall oder Update der 3CX zwar der Status vom Dummy erhalten bleibt aber die Scripte danach neu gestartet werden müssen.

 

[fxbastler]

- 4 NST wollen die Erreichbarkeit ... und "etwas" auf dem Telefon dazu sehen

Das ist ein generelles Problem. Diese Frage kam früher öfter (gefühlt mehrmals jede Woche), jetzt nur noch ca. 1-2x im Monat.
3CX verwendet die BLF Tasten bei IP Telefonen genau so und nach dem Plan für den sie gedacht sind, siehe Abkürzung BLF.

Meine Lösung sind meine ersten selbst erstellten CFD´s.

BLF 1 stellt den Dummy per Script auf "Custom 1" (ausser Bürozeit)
BLF 2 stellt den Dummy per Script auf "Custom 2" (Ferien)

Sehr schön, da wurde wieder jemand von der Nützlichkeit von CFD Anwendungen überzeugt

Beide Scripte legen nach der Umstellung auf und starten einen Call zu einem IVR.
Leider wird das immer nach 60sek vom System beendet.

Keine gute Idee.
Die Billiglösung: im Disconnect Handler Flow dieser CFD App #1 ein Makecall zwischen z.B. einer anderen CFD APP #2 (die einfach nur in einer Endlosschleife läuft) zu der besagten Dummy NSt. starten. Auch diese CFD App #2 hat einen Disconnect Handler Flow. Auch dort kann wieder ein Makecall starten, z.B. von sich selber auf die besagte Dummy NSt..

Wenn man sich das mit CFD App#1 und CFD App #2 genauer anschaut, dann kommt man auch auf die folgende Idee:
Die urspr. CFD App #1 kann ja erkennen wer sie anruft. Eine CFD App kann auch die eigene Rufnummer ermitteln (ist ein kleines C# Schnipsel). So kann eine CFD App z.B. erkennen ob sie sich selber anruft. Dann kann die CFD App ab dieser Stelle einen anderen Ablauf (die Endlosschleife) haben.
Dann kann diese CFD App sich selber immer per Make Call im Disconnect Handler Flow verbinden, erkennt das beim erneuten Anruf und man braucht keine CFD App #2. Nur mal so zum drüber nachdenken.

Setze notfalls den 3CX Parameter MAXCALLDURATION (und evtl. gar CALL_TRANSFER_TRACKING_TIME) höher
Passe ggf. einen Parameter im HT an, damit es dort länger rufen kann und der nicht aufgibt.

Also habe ich das in eine Schleife gebaut die alle 55 sek den call beendet, den Status vom Dummy abfragt und wenn der noch "Custom" ist den nächsten Call startet.

Auch keine gute Idee.

Was mir nicht gefällt ist das jetzt natürlich jede Minute auch ein neuer Anruf im Protokoll steht.

^deswegen, das war absehbar

Kann man den Dummy irgend wie länger als 1 Minute "besetzt" halten

Ja, aber nicht auf diese Weise, siehe Billiglösung oben.
Eine richtig gute Lösung gibt es nicht, s.o.: Nutzung der BLF Funktion durch eine 3CX.
Die bessere Lösung ist eine ganz andere, erfordert aber auch ganz andere Maßnahmen, z.B. eine 3CX NSt. die bei Bedarf permanent besetzt ist. Das geht nur per Software und grds. (Ausnahmen bestätigen diese Regel) nicht in der 3CX.

Ausserdem gehe ich o... davon aus dass bei Stromausfall oder Update der 3CX zwar der Status vom Dummy erhalten bleibt aber die Scripte danach neu gestartet werden müssen.

Das ist richtig. Das ist ein Problem, immer wieder, so wie bei Dialern u.ä. Konstrukten auch

Das geht praktisch nur mit einem völlig anderen Skript welches z.B. nach dem Start der 3CX und den 3CX Services läuft, den Laufzeitzustand der 3CX bzgl. der Ausführung der o.g. CFD Apps überwacht und diese ggf. startet. Keine ganz einfache Aufgabe und keine einfache Lösung wenn die 3CX komplett supported bleiben soll
Eine von 3CX unterstützte Lösung erfordert auf jeden Fall einen weiteren Computer der läuft und das auf geeignete Weise tut. Der kann dann auch per Software Dummy Nebenstellen bereitstellen.
Dass so eine Lösung pro solcher abgebildeter NSt. die 3CX Lizenz (bzgl. SC und Anzahl der Nutzer) belastet erwähne ich nur am Rande, das wird bekannt sein.

Wenn ich mir dein Bild der CFD App anschaue kommen Fragen auf:

1. Was machen die C# Code Schnipsel denn da genau?
   Wenn du den Code dazu posten würdest, dann könnten wir ja mal nachschauen ...
2. Wenn du schon so viele C# Code Schnipsel im CFD verwendest: Warum dann nicht gleich alles in einem einzigen C# Code Schnipsel abbilden? Das ist vielleicht einfacher.

 

[Ringo]

@fxbastler

ich wollte Dir das per PN senden bekomme aber immer eine Fehlermeldung. Kannst Du mich mal anschreiben ?

 

[fxbastler]

ich wollte Dir das per PN senden bekomme aber immer eine Fehlermeldung.

Das sollte nach wie vor funktionieren. Andere machen das auch.

Warum nicht hier?

 

[patrickb]

Bau dir eine CFD APP mit einem C# Element in dem Thread.Sleep(60000); drin steht. Das setzt du in einen Loop, den Loop verlässt du wenn die Durchwahl X den Status Y hat. Das Ganze speicherst du dann als "stille".

Dann lässt du mit MakeCall in deinem "Schalt-CFD" den CFD "stille" von der Dummy-DW anrufen, die Schaltung ausführen und ab geht die Fahrt.

Zusätzlich noch MAXCALLDURATION hochsetzen und fertig. Spät. 60 Sek nach Umschaltung wird das Gespräch beendet weil die Prüfung fehlschlägt und damit der "Stille-Loop" verlassen wird.

Da nach MAXCALLDURATION automatisch gekillt wird, setzt du ein weiteres MakeCall Element mit der gleichen Funktion und Statusprüfung in den DisconnectHandler. Das startet dann den Anruf neu, sollte der Status weiterhin Y und Time > MAXCALLDURATION sein. Wenn nichts wirds übersprungen.

 

[fxbastler]

Ein suboptimales Beispiel. Unflexibel mit den 60 sek. und startet nie von selber nach Anlagen- oder Dienstneustart (das typische Problem). So löst man das nicht dauerhaft mit der BLF Tastenanzeige.

 

[patrickb]

Ein suboptimales Beispiel. Unflexibel mit den 60 sek. und startet nie von selber nach Anlagen- oder Dienstneustart (das typische Problem). So löst man das nicht dauerhaft mit der BLF Tastenanzeige.

Muss auch nicht nach Anlagenneustart gestartet werden, da der "stille" Script nur dann läuft wenn er benötigt wird. Ist kein Dialer. Der CFD überwacht sich durch den DisconnectHandler selbst.

 

[fxbastler]

Ich will hier mit dir keine Sinnlosdiskussion vom Zaun brechen. Wir bewegen uns schon abseits. Zurück zum Anfang: es geht um die Darstellung eines Status auf einer BLF Taste.

 

[Ringo]

Hallo, hat etwas gedauert. Zu viele andere Sachen.

MAXCALLDURATION nützt glaube nichts.

CALL_TRANSFER_TRACKING_TIME habe ich auf meinem Testsystem von 60 auf 120 sek gesetzt. Der Call dauert dann 2 min. Jetzt habe ich festgestellt dass nachdem ich das zurück auf 60 sek gestellt habe es dennoch 120 sek andauert. Blieb auch nach Neutstart.





Verstehe nicht wieso der jetzt noch länger als 60 sek laufen kann. Wenn ich da was noch größeres einstelle und das nicht zurückstellen kann wäre das aber sehr ungünstig.

Und dann noch ne "blöde" Frage. Sobald ich hier den Code einfüge bekommen ich bei "Vorschau" oder "antworten" ne Fehlermeldung. Wenn ich nur Test einfüge nicht. Was mache ich denn falsch?

test

 

[Ringo]

ah als .zip

 

[fxbastler]

Danke für das Teilen des Projekt.

Ich habe mir nur ganz kurz den Code angeschaut und dazu einige Anmerkungen:

1. Jeder Anruf in einer 3CX hat 2 Einträge in ActiveConnections. Wenn also ein Anruf komplett beendet werden soll, dann sollten beide (vmtl. gar alle) ActiveConnections beendet werden. Kannst du dir gern mal anschauen indem du alle GetActiveConnections() einer DN in's Log schreibst.
2. Der CallHelper / StartPark sieht eigenartig aus und ist sinnfrei. Der CFD Code Block Make Call ist im Disconnect Handler Flow benutzbar und sollte auch benutzt werden.
3. Ja, man könnte auch gern die gesamte Schleife im Disconnect Handler in einem einzigen C# Code Schnipsel schreiben. Schleifen im CFD ist so ein Ding mit der Optik, den notw. globalen Variablen und deren Handling davor und drin usw., hat mir noch nie so richtig gefallen, ist leider so. Das sieht in C# etwas einfacher aus. Dann aber ps von myCall ableiten

Den Rest (die Logik bzgl. Aufgabe / Ziel) durchdenke ich mir später in Ruhe nochmal.