Missing Feature v20: Feiertage separate Ansage

[dj-melo]

mein 1. Gedanke war auch grade "WTF" das ist bisschen am Ziel vorbei... sprich doch viel zu kompliziert... Intuitiv wäre wie geschrieben: Feiertag setzen mit sep. Datei und fertig.

 

[fxbastler]

Die Beschreibung zu TimeBasedRoutingInfo fehlt halt überall und ich wurstel mich da so durch deren Eigenschaften durch, vielleicht fehlt da einfach etwas.

Grundsätzlich könnte man das Skript aber auch mit den bisherigen Mitteln der Abfrage der Feiertage, deren Zuordnung zu Abteilungen und der dafür hinterlegten Audio Dateien anders bauen. Vor allem funktionstüchtig. Das ist kein Hexenwerk. Da fehlt mir persönlich aber grad etwas die Zeit.

 

[sean@axe]

Die Beschreibung zu TimeBasedRoutingInfo fehlt halt überall und ich wurstel mich da so durch deren Eigenschaften durch, vielleicht fehlt da einfach etwas.

Grundsätzlich könnte man das Skript aber auch mit den bisherigen Mitteln der Abfrage der Feiertage, deren Zuordnung zu Abteilungen und der dafür hinterlegten Audio Dateien anders bauen. Vor allem funktionstüchtig. Das ist kein Hexenwerk. Da fehlt mir persönlich aber grad etwas die Zeit.

Ich habe keine CS Entwickler Umgebung und die Suchfunktion in der Dokumentation geht nicht.
Nichtsdestotrotz habe ich mich mal durchgekämpft, und ich kenne mich mit CS auch überhaupt nicht aus.

GetTimeBasedRoutingInfo() wird wohl GetTimeDestionationOverride() in der Doku auf dem DN Interface heissen, durch die Funktion erhältst du dann ein TimeBasedDestination struct.
Schon mal schön, dass die Doku stimmt.

Man muss aber den Trunk der Abteilung hinzufügen, ansonsten erhältst du mit `MyCall.Caller.DN.GetTimeBasedRoutingInfo()` die Systemweiten Öffnungszeiten, welche unter V20 meines Wissens nach nicht konfiguriert werden können.


Wenn du nun aber verschiedene Abteilungen mit einem Trunk belieferst, haben die ja vielleicht andere Feiertage.

Jetzt kannst du aber mit `var routeTarget = MyCall.RouteTarget.GetFullSnapshot();` das DN Interface des Endpoints holen, wohin die angerufene Rufnummer geroutet wird. Dann erhältst du aber trotzdem das TimeBasedDestination struct von der Abteilung, die auf dem Trunk konfiguriert.

Mit `MyCall.RouteTarget.GetFullSnapshot().Number` erhältst du jedoch die Rufnummer des Endpoints, der die Rufnummer zugewiesen hat.

Nur will es mir einfach nicht das TimeBasedDestination struct des Endpoints geben, sondern unbedingt nur das vom Trunk.
In der Doku steht "Time based routing for Extension type of DN is not defined.", nur erhalte ich auch das TimeBasedDestination struct vom Trunk, wenn ich auf eine Ringruppe route.

Schrecklich, dass man das so kompliziert machen muss.

Vielleicht sehe ich es jetzt auch einfach gerade nicht mehr, aber es scheint mir so, als kann man die Feiertagsansage auf dem Feiertag nur dann abspielen, wenn der Feiertag auf der Abteilung, die auf dem Trunk konfiguriert ist.

Ich lasse es nun mal sein für heute.

 

[fxbastler]

Hallo @sean@axe

das was du im ersten Absatz schreibst, speziell auch den wenigen letzten Worten, steht nun wirklich im starken Gegensatz zum Rest des Post, da musste ich sehr lächeln

Gemessen an dem ist das was du gefunden hast sehr gut, Hut ab, sehr gute Detektivarbeit. Die Rückwärtssuche und Schlussfolgerung zu GetTimeDestionationOverride() stimmt wohl nicht und einiges darunter auch nicht aber die Richtung ist gut, der Rest ist noch zu finden.

Eine C# Entwicklungsumgebung nutzt mir imho in diesem Fall auch nichts (obwohl das auf dieser Maschine bei uns möglich wäre, ist Server 2019), habe ich dort aktuell auch nicht und mit Powershell (sonst sehr hilfreich) komme ich auch nicht weiter. Das sind alles Prozessdaten während eines Anrufes, das kann ich nicht mal eben anhalten - zumindest ich weiss nicht wie. SoftICE wie früher (das waren noch Zeiten) hilft mir hier nicht. Die aktuelle 3cxpscomcpp2.dll (ich habe aktuell 5 v20 u2 Versionen) nach Funktionen zu zerlegen bringt wohl nichts, das spielt dort wohl nicht rein, das sind Prozesse.

Kurzes Fazit 'am Rande': das offizielle 3CX Skript funktioniert genau so wie beschrieben, aber eben nur unter der Bedingung, dass der SIP Trunk einer Abteilung zugeordnet ist. Nur dann holt sich das Skript diese benötigten Daten.

Das Skript nutzt uns und vmtl. anderen so nicht. Die Zuordnung SIP Trunk - Abteilung für die Fälle wo wir diese Funktion brauchen ist bei uns nicht statisch und können wir auch nicht so begrenzen.

Nach wie vor wie von mir beschrieben: das Bild in der offiziellen Beschreibung ist falsch. Das kann nicht funktionieren und tut es aktuell nicht. Ich weiss nun nicht, ob das Skript vor dem 14.06.24 (dem Post von Nick) bzw. am / bis zum 21.06.24 (da wurde die Beschreibung zuletzt geändert lt. aktuellen Sachstand) in irgend einer 3CX Version jemals so wie gezeigt funktioniert hat. Es wird auf jeden Fall eine 3CX v20 u2 benötigt. Mit div. 3CX v20 u2 Beta und der akt. 3CX v20 u2 Build 715 tat und tut es das nicht. Nur wenn man den SIP Trunk an eine Abteilung bindet, dann funktioniert das Skript. Dann steht in der nicht änderbaren Bindung des Skriptes allerdings die dem SIP Trunk zugewiesene Abteilung und nicht mehr Systemweit.

Ich versuche mal den Ablauf mit meinem dürftigen Wissen und akt. Kenntnisstand zu vervollständigen, Korrekturen und Erweiterungen sind willkommen.

Ja, die Suchfunktion der 3CX v20 Doku funktioniert leider nicht. Man muss anderweitig suchen - in den Dateien selber und sich dann wieder nach oben hangeln - oder wissen wo man starten muss. In diesem Fall startet man mit den laufenden Daten und Prozesse, sprich CallFlow -> ICall von dem MyCall eine Instanz ist.

Die TimeBasedStruct kommt abhängig von der DN mit Daten zurück. Die Funktion GetTimeBasedRoutingInfo() ist wirklich nirgends in der akt. Doku beschrieben. Das fehlt komplett, aber es funktioniert, auch ohne Beschreibung - einfach so (erinnert mich an MS und früher: undokumentierte Funktionen zuhauf).

Die Audio Dateien für die Feiertage der Abteilungen liegen alle im 3CX Pfad unter Instance1/Data/Ivr/Prompts egal ob Windows oder Debian. Wenn für einen Feiertag keine Audio Datei (mit möglichen eigenem, anderen Namen) angegeben wurde, dann wird zusätzlich unterhalb Instance1/Data/Ivr/Prompts/holidays nach einer Audio Datei (.wav) mit dem Namen des Feiertages gesucht und diese benutzt. Wenn auch diese nicht da ist, dann beendet sich das Skript (es gibt ja nichts zum Abspielen) mit einem Fehler und daher wird die reguläre Abarbeitung des Callflow seitens der 3CX fortgesetzt.

Das ist ein Merkmal dieser Anrufverarbeitungsskripte:

• ist der Rückgabewert = true (das Skript läuft und läuft und tut etwas), dann wird nach dem Ende des Skriptes seitens der 3CX der Callflow beendet, es werden wohl keine weiteren Call Routen verfolgt
• ist der Rückgabewert = false (auch wenn das Skript vorher gelaufen ist usw.), dann wird nach dem Ende des Skriptes seitens der 3CX der Callflow weiter verfolgt und versucht zu routen; wenn da z.B. eine Abteilung dahinter steht und diese hat für den Fall eines Feiertags eine Route eingetragen und es ist Feiertag, dann wird dieser Route gefolgt

Wenn man nun das Anrufverarbeitungsskript an den SIP Trunk bindet, diesen SIP Trunk aber nicht an eine Abteilung (der SIP Trunk gilt dann Systemweit, das Skript somit auch), dann muss man 'nur' noch herausfinden, wohin der Anruf geroutet wird, wenn sich das Skript mit dem Rückgabewert false beendet. Das ist wohl die Aufgabe. Das habe ich aktuell noch nicht herausgefunden.

Beinahe jede Entität einer 3CX (zumindest alle Route Endpunkte) ist eine DN: SIP Trunks, Bridges, Nutzer, Abteilungen, DR, RG, WS usw.. Jede DN einer 3CX hat eine unikate Nummer. Das kann man leicht kontrollieren, die Nummer ist zumindest für mich les- und unterscheidbar. Auf Grund der Nummer einer DN bekommt man andersrum auch immer die DN und damit - wenn vorhanden weil Abteilung - deren Feiertage.

Wenn man z.B., wie vorgeschlagen, MyCall.RouteTarget.GetFullSnapshot() folgt (ist ein DN) bzw. MyCall.RouteTarget.GetFullSnapshot().Number (deren lesbare Nummer), dann bekommt man die Nummer des SIP Trunk. Dieser hat eben ab der v20 keine Zeiten und keine Feiertage mehr. Daher bleibt die TimeBasedDestination struct (Doku: CallFlow -> Structures -> TimeBasedDestination) leer. Ich suche noch die Funktion, welche mir eine DN bzw. Nummer nach dem erfolglosen Routing (return false) des Anrufverarbeitungsskript zurückgibt, auf Grund dessen ich auf eine Abteilung schließen kann von der ich dann wiederum die Feiertage lesen kann. Ich suche noch ...

 

[sean@axe]

Wenn man z.B., wie vorgeschlagen, MyCall.RouteTarget.GetFullSnapshot() folgt (ist ein DN) bzw. MyCall.RouteTarget.GetFullSnapshot().Number (deren lesbare Nummer), dann bekommt man die Nummer des SIP Trunk. Dieser hat eben ab der v20 keine Zeiten und keine Feiertage mehr. Daher bleibt die TimeBasedDestination struct (Doku: CallFlow -> Structures -> TimeBasedDestination) leer. Ich suche noch die Funktion, welche mir eine DN bzw. Nummer nach dem erfolglosen Routing (return false) des Anrufverarbeitungsskript zurückgibt, auf Grund dessen ich auf eine Abteilung schließen kann von der ich dann wiederum die Feiertage lesen kann. Ich suche noch ...

Das finde ich komisch, denn wenn ich mit 'MyCall.RouteTarget.GetFullSnapshot() is not Extension' einen Vergleich mache, funktioniert das so wie ich es erwarte. Also bei Usern erhalte ich ein false und bei CQ, IVR etc. erhalte ich ein true.
Wie weisst du, dass man damit die DN.Number des Trunks erhält?
Ich habe die Anrufe dann jeweils im Skript eben an diese DN weitergeleitet, also RouteToAsync(routeTarget.Number), was so weit auch geklappt hat.
Ich weiss leider noch immer nicht wie ich das Zeugs "debuggen" kann, habe bis jetzt aber auch nur direkt mit den Scripts im WebGui gearbeitet.

Du PhoneSystem unter TCX.Configuration hat eine Funktion GetDNByNumber(string), damit könntest du die MyCall.DialedNumber auf die Anzahl interne Stellen kürzen und so die DN erhalten, sofern die korrespondieren.

Wenn du versuchst die GetTimeDestionationOverride() im Skript auszuführen, wird es diese Funktion nicht kennen, weshalb ich davon ausgehe, dass diese umbenennt wurde.


Danke noch für deine ausführliche Zusammenfassung.

 

[fxbastler]

Wie weisst du, dass man damit die DN.Number des Trunks erhält?

GetDNByNumber() gibt die DN einer Entität auf Grund einer Nummer, xyz.Number die Nummer sofern das geht. Aber das kennst du wohl schon. Geht es dir sonst darum, die SIP Trunks alle zu finden?

Ich weiss leider noch immer nicht wie ich das Zeugs "debuggen" kann, habe bis jetzt aber auch nur direkt mit den Scripts im WebGui gearbeitet.

Ich im Prinzip auch. Ich lasse die Ausgabe mittels z.B.

string sLogFile = @"C:/ProgramData/3CX/Instance1/Data/Logs/3CXCallFlowFX.log";
...
try { File.AppendAllText(sLogFile, "\n##### CFA C# Log: time|"+ DateTime.Now.ToString("H:mm:ss") +"|\n");} catch(Exception ex) { MyCall.Info($"Failed CFA\n{ex}"); }

in eine separate Datei schreiben und monitore diese. Sehr primitiv, gebe ich zu, aber reicht teilweise.

... damit könntest du die MyCall.DialedNumber auf die Anzahl interne Stellen kürzen und so die DN erhalten, sofern die korrespondieren.

Diese Zuordnung stimmt bei uns praktisch nirgends. Wenn überhaupt, dann evtl. nur kurz nach einer Ersteinrichtung. Wir haben das nirgends fest und halten das auch nicht aufrecht. Sonst wären z.B. div. WS und DR mitten im Nummernblock der Nutzer.

 

[sean@axe]

GetDNByNumber() gibt die DN einer Entität auf Grund einer Nummer, xyz.Number die Nummer sofern das geht. Aber das kennst du wohl schon. Geht es dir sonst darum, die SIP Trunks alle zu finden?

Ich meine, weil du gesagt hast:

Wenn man z.B., wie vorgeschlagen, MyCall.RouteTarget.GetFullSnapshot() folgt (ist ein DN) bzw. MyCall.RouteTarget.GetFullSnapshot().Number (deren lesbare Nummer), dann bekommt man die Nummer des SIP Trunk.

Ich kann mit MyCall.RouteTarget.GetFullSnapshot() der Vergleich ziehen, ob das Ziel (also die erhaltene DN) ein User (interface Extension) ist oder nicht, weshalb es mich verwundert, dass du mit MyCall.RouteTarget.GetFullSnapshot().Number die Nummer des Trunks erhälst.

Ich im Prinzip auch. Ich lasse die Ausgabe mittels z.B.

string sLogFile = @"C:/ProgramData/3CX/Instance1/Data/Logs/3CXCallFlowFX.log";
...
try { File.AppendAllText(sLogFile, "\n##### CFA C# Log: time|"+ DateTime.Now.ToString("H:mm:ss") +"|\n");} catch(Exception ex) { MyCall.Info($"Failed CFA\n{ex}"); }

in eine separate Datei schreiben und monitore diese. Sehr primitiv, gebe ich zu, aber reicht teilweise.

Werde ich mal so probieren, da komme ich sicher weiter als bis anhin! Danke dir vielmals!

 

[fxbastler]

Ich kann mit MyCall.RouteTarget.GetFullSnapshot() der Vergleich ziehen, ob das Ziel (also die erhaltene DN) ein User (interface Extension) ist oder nicht, weshalb es mich verwundert, dass du mit MyCall.RouteTarget.GetFullSnapshot().Number die Nummer des Trunks erhälst.

Das liegt wohl daran, weil bis zu diesem Zeitpunkt alle Daten den SIP Trunk als akt. Endpunkt halten, noch nicht einmal das Anrufverarbeitungsskript (was zu dem Zeitpunkt transparent 'nebenher' gestartet wurde und daher kein Ziel ist). Siehe Beschreibung RouteTarget, DNRef, GetFullSnapshot: gives fresh copy of .... Das ist leider keine Glaskugel für folgende Routing Punkte.

 

[bkappeler]

Nachdem beim neuen Update endlich wieder Urlaubstage oder Zeiträume fürs ganze Jahr mit individuell besprochenen Anrunfbeantworterdateien versehen werden können (wie früher) ist mir noch ein BUG aufgefallen. Ich weiß aber nicht wo man den melden muss/kann und zwar:
Urlaub hinzufügen, Zeitraum wählen und dann wenn man keine bereits vorhandene Audiodatei auswählt und eine aufzeichnen will und das Mikro drückt kommt man in ein Unterfenster bei dem die Nebenstelle eingegeben werden soll, von der aus man Diktieren will gehts nicht weiter. Früher rief es dann die Nebenstelle an und man konnte aufnehmen und mit Raute beenden (wurde alles angesagt), danach war die Datei zur Ausweahl vorhanden.

 

[bitn2]

Das ist ein Fehler in der Beschriftung, da sollst du den Datei Namen angeben und dann aufnehmen. Eine Aufnahme über eine Nebenstelle ist nicht möglich.

 

[fxbastler]

3CX v20 u3 Alpha, abrufbares Feiertag Skript:

 

[Corsin]

3CX v20 u3 Alpha, abrufbares Feiertag Skript:
Anhang anzeigen 16038

Nice.
Das scheint jetzt ein anderes Skript zu sein. Unterschiedliche Feiertage auf verschiedenen Nummern vom selben Trunk scheinen immer noch nicht zugehen, oder hat da mittlerweile jemand was herausgefunden?

 

[fxbastler]

Das scheint jetzt ein anderes Skript zu sein.

Aktuell verweist dieser Link auf denselben Blog Eintrag / Skript wie zuvor. Also kein anderes Skript im Moment. Aber man findet es direkt.

Unterschiedliche Feiertage auf verschiedenen Nummern vom selben Trunk scheinen immer noch nicht zugehen, oder hat da mittlerweile jemand was herausgefunden?

Ja, das geht - je nachdem wie man das sieht.

Anders: der Trunk muss einer Abteilung zugeordnet werden, fragt dann deren GZ usw. ab und verarbeitet diese. Das heißt: unterschiedliche Abteilungen benötigen je so ein Skript.

Aber: wird ein SIP Trunk mit einigen DID für verschiedene Abteilungen (mit anderen GZ usw.) genutzt, so kann man das Skript nicht verwenden. Das fehlt.

 

[Corsin]

Aktuell verweist dieser Link auf denselben Blog Eintrag / Skript wie zuvor. Also kein anderes Skript im Moment. Aber man findet es direkt.

Ich kenne mich nicht gut mit C# Code aus, habe nur bemerkt das wenn man den Namen des Skripts anklickt (nicht den Link) wird eindeutlich kürzeres Skript als das vom Blog Post eingefügt. Deshalb dachte ich es hat sich evtl. was verändert.

Aber: wird ein SIP Trunk mit einigen DID für verschiedene Abteilungen (mit anderen GZ usw.) genutzt, so kann man das Skript nicht verwenden. Das fehlt.

Ja das ist genau das was ich meinte, schade.

 

[fxbastler]

Ich kenne mich nicht gut mit C# Code aus, habe nur bemerkt das wenn man den Namen des Skripts anklickt (nicht den Link) wird eindeutlich kürzeres Skript als das vom Blog Post eingefügt. Deshalb dachte ich es hat sich evtl. was verändert.

Das ist derselbe Link und dahinter auch immer noch dasselbe Skript wie bei der ersten Veröffentlichung vom 21.06.24.

 

[Corsin]

Das ist derselbe Link und dahinter auch immer noch dasselbe Skript wie bei der ersten Veröffentlichung vom 21.06.24.

Ich meine ja eben nicht den Link. Sondern wenn man hier drauf drückt:

• Ensure the file name and the holiday name are an exact match.

Der Punkt 2 aus dem Blog-Post ist gemäss meinem Test jetzt nicht mehr nötig. Weiss zwar nicht ob das bereits vorher geändert hat.

Hier die beiden Skripts:

Skript holiday.cs (aus dem Store)

/*
 * Play Holiday Prompts - Use code with caution!
 * Requires holidays and prompts to be configured on department office hours
 * Requires trunk to be part of the department and holidays configured at department level
 * Based on the entered PIN, the call is routed to a predefined destination.
 * Script intercepts inbound calls on a trunk and checks if it is a holiday in Office hours - Department - Office holidays
 * If the day is set as a holiday and a prompt is configured, the prompt will be played and call wil be routed to the holiday routing destination
 * If there is no prompt, the prompt will be skipped
*/


#nullable disable
using CallFlow;
using CallFlow.CFD;
using TCX.Configuration;
using System.Threading.Tasks;
using TCX.PBXAPI;
namespace dummy
{
    public class PlayHolidayPromptBeforeRouting : ScriptBase<PlayHolidayPromptBeforeRouting>
    {
        string GetRealPromptFileName(OfficeHoliday holiday)
        {
            return holiday?.HolidayPrompt;
        }
     
        public override async Task<bool> StartAsync()
        {
         
            PhoneSystem ps = (PhoneSystem)MyCall.PS;
            if (MyCall.Caller.DN is ExternalLine externalLine)
            {
                var trunkTimeBasedroute = MyCall.Caller.DN.GetTimeBasedRoutingInfo();
                if (
                    trunkTimeBasedroute.reason == CallControlAPI.DivertReason.Holiday
                    && GetRealPromptFileName(trunkTimeBasedroute.holiday) is string thePath
                    && !string.IsNullOrWhiteSpace(thePath)
                    )
                {
                    await MyCall.AssureMedia()
                    .ContinueWith(x => MyCall.PlayPrompt(null, new[] { thePath }, PlayPromptOptions.Blocked))
                                .Unwrap();
                }
            }
            return false;
        }
    }
}

Skript vom Blog-Post

#nullable disable
using CallFlow;
using System;
using System.Threading;
using System.Threading.Tasks;
using TCX.Configuration;
using TCX.PBXAPI;
using System.Collections.Generic;
using System.IO;

namespace dummy
{
    public class PlayHolidayPromptBeforeRouting : ScriptBase<PlayHolidayPromptBeforeRouting>
    {
    //the calls during holidays which have either
    //OfficeHoliday.HolidayPrompt OR
    //if the file with <holiday name>.wav in the folder          Data/Ivr/Prompts/holidays is found,
    //will be redirected to the number specified here.
    //if prompt will not be found, the call will not intercepted
        const string destinationDN = "1002"; //routing destination if holiday is true
     
        public override async Task<bool> StartAsync()
        {
            try
            {
                PhoneSystem ps = (PhoneSystem)MyCall.PS;
                if(MyCall.Caller.DN is ExternalLine externalLine)
                {
                    var trunkTimeBasedroute = MyCall.Caller.DN.GetTimeBasedRoutingInfo();
                    if(trunkTimeBasedroute.reason == CallControlAPI.DivertReason.Holiday && trunkTimeBasedroute.holiday!=null)
                    {
                        MyCall.Info($"the holiday is {trunkTimeBasedroute.holiday}");
                        var theFile = trunkTimeBasedroute.holiday.HolidayPrompt;
                        if(string.IsNullOrWhiteSpace(theFile))
                        {
                            theFile = Path.Combine(ps.GetParameterValue("IVRPROMPTPATH"), "holidays", trunkTimeBasedroute.holiday.Name+".wav");
                            MyCall.Info($"Check holidays prompt storage for {theFile}");
                            if(!File.Exists(theFile))
                            {
                                MyCall.Info($"No holiday prompt found. Skip holiday routing");
                                theFile = null;  
                            }
                        }
                        else
                        {
                            MyCall.Info($"HolidayPrompt is {theFile}");
                        }
                 
                        if(!string.IsNullOrWhiteSpace(theFile))
                        {
                            var holidayDestination =new DestinationStruct(ps.GetDNByNumber(destinationDN));
                         
                            MyCall.Info($"Playing prompt {theFile} and route call to {holidayDestination}");
                            await MyCall.AssureMedia()
                            .ContinueWith(x => MyCall.PlayPrompt(null, [theFile], PlayPromptOptions.Blocked))
                            .Unwrap()
                            .ContinueWith(x=>MyCall.RouteToAsync(holidayDestination))
                            .Unwrap();
                            return true;
                        }
                    }
                }
            }
            catch(Exception ex)
            {
                MyCall.Info($"Failed to intercept holiday route\n{ex}");
            }
            return false;
        }
    }
}

 

[fxbastler]

Sondern wenn man hier drauf drückt:

Das habe ich noch gar nicht probiert Du hast Recht, das ist ein völlig anderes Skript.

Das ändert nichts an der Tatsache, dass es für dein Szenario (ein SIP Trunk, gebunden an eine Abteilung, Verwendung von einigen dessen DID in anderen Abteilungen mit anderen GZ und Nutzung dieser) so wie es derzeit aussieht nicht funktioniert.

 

[Claude]

Unfassbar! Bin so sauer auf die 3CX Entwickler! Nutze 3cx selbst gehostet seit Jahren, jedoch das v20 raubt mir den letzten Nerv! Freute mich auf den Urlaub, die Urlaub und Feiertage haben aber die gleiche Priorität wie die sonst übliche Warteschleife. Jetzt laufen 2 Ansagen hintereinader, Urlaub mit Warteschleifenmusik, anschliessend Täglicher AB. Intuitiv war es noch nie, habe es aber immer hinbekommen. WTF.. Testen die so etwas nicht vor der Veröffentlichung ?

 

[Severin]

Hallo zusammen

Seit dem Update auf Version 3 Beta, gab es diesbezüglich doch Verbesserung und eine vereinfachung betr. Feiertagskonfiguration mit eigenen Ansagen.
Zudem muss das Audiofile und der Feiertag nicht mehr den gleichen Namen haben.
Man kann nun auch nur einzelne Warteschleifen auf das CFD Feiertag senden indem man "Skript ausführen: Wenn Nutzer einen Wählcode wählt" beim CFD hinterlegt oder halt wie bisher den ganzen Trunk mit ALLEN nummern.
Dennoch fehlt in meinen Augen immernoch gravierende Funktionen diesbezügliches, welche die V18 abdecken konnte und mit der V20 immernoch nicht möglich.

Hier eine kurze Zusammenfassung verschiedener Szenarien unserer Kunden - welche bisher individuelle Feiertagsansagen hatten:

Szenario 1:
1 Trunk & 1 Abteilung --> Warteschleifen mit Feiertagsschaltung, Durchwahlen keine Feiertage = Möglich (Skript ausführen: Wenn Nutzer einen Wählcode wählt)

Szenario 2:
1 Trunk & 1 Abteilung --> Alle Nummern mit Feiertagsschaltung = Möglich (Skript ausführen: Beim Empfang eines Anrufes auf den Trunk)

Szenario 3:
1 Trunk & 1 Abteilung --> Warteschleifen mit Feiertagsschaltung, Durchwahlen mit und Durchwahlen ohne Feiertagsschaltung (Pikettnummern) = BEDINGT Möglich (Durchwahlen kann ich nicht automatisch bei Feiertag auf das CFD senden - nur mit Status wechsel)

Szenario 4:
1 Trunk & 2 oder mehr Abteilungen (unterschiedlichen Feiertage), da unterschiedeliche Standorte oder Gesundheitseinrichtungen mit Abteilungen welche 24H Betrieb haben --> NICHT Möglich --> Hier müsste ich Pro Abteilung einen eigenen Trunk machen, was die Providerkosten wieder enorm in die höhe Treiben würde.

Szenario 5:
1 Trunk & 2 oder mehr Abteilungen (gleiche Feiertage) --> Alle Nummern mit Feiertagsschaltung = Möglich (Skript ausführen: Beim Empfang eines Anrufes auf den Trunk)

Seit die "eingehenden Regeln" von der V18 verschwunden sind, gibt es hier immernoch ein grosses defizit.
Zudem fehlt in meinen Augen, beim Benutzer selber unter den "Ausnahmen" die Funktion der Anrufbeahndlung während Feiertagen. (Ausserhalb ÖFffnungszeiten ist vorhanden, während Feiertage nicht).
Ich hoffe die 3CX bessert hier noch nach.

Vielleicht habe ich auch etwas übersehen, wenn ihr diesbezüglich andere Infos oder Lösungen habt, dann bitte gerne mitteilen.

 

[libertyx82]

Bin gerade auch dabei mir das Script anzuschauen.

Hätte ich hier z.B. die Möglichkeit die angerufene Nebenstelle abzufragen und nach dem abspielen der Ansage den Anruf an die Mailbox der angerufenen Nebenstelle weiterzuleiten?