IVR - „Anrufern das Wählen von Nebenstellen erlauben" deaktiviert jedoch ohne Wirkung (V20 U9)

[AlexSess]

Sehr geehrte Forumsmitglieder,

wir betreiben eine V20-Instanz (Update 9, Build 20.0.9.995) mit mehreren Digitalen Rezeptionen vom Typ Standard.

Ziel: Die Direktwahl von Nebenstellen aus der Digitalen Rezeption soll unterbunden werden, zum einen, weil das in diesem Fall schlicht nicht möglich sein darf,
zum anderen, um die Weiterleitung zur gewählten Menüoption zu beschleunigen: Die Anlage wartet nach dem Tastendruck aktuell auf die Eingabe einer zweiten Ziffer (interner Nummernplan ist zweistellig).

Zwischen DTMF-Eingabe und Transfer vergehen dadurch konstant ca. 4–5 Sekunden, was auf den Inter-Digit-Timer der Ziffernsammlung ([0-9]{2}) zurückzuführen sein müsste.
Den Parameter IVR_DIRECT_DIALING_GRAMMAR hatte ich testweise bereits umgestellt, ebenfalls ohne Auswirkung.

Das Deaktivieren von „Anrufern das Wählen von Nebenstellen erlauben" in der Admin-Konsole bleibt ohne Wirkung - Anrufer erreichen weiterhin jede Nebenstelle per Direktwahl, und die Verzögerung bei den Menütasten bleibt ebenfalls bestehen.

Bereits versucht:

Per Backup-Export bestätigt, dass der GUI-Schalter die DN-Eigenschaft DIRECT_FROM_IVR an der jeweiligen Digitalen Rezeption nicht in die Konfigurationsdatenbank schreibt, der Wert bleibt trotz Speichern (und Neustart) auf 1
DIRECT_FROM_IVR = 0 daraufhin manuell über die DN-Eigenschaften-Tabelle gesetzt (via DEVELOPMENT_DNTABLE_EXPOSE = 1)
Nach jeder Änderung vollständiger Neustart der Anlage

Das Laufzeitverhalten ändert sich leider auch nach dieser Maßnahme nicht, die Direktwahl-Konfiguration scheint vom IVR-Dienst in unserem Fall nicht ausgewertet zu werden.

Kennt jemand das Problem, und wie lässt es sich lösen? Als nächste Variante würde ich die zwei IVRs dann mit CFD bauen wenn es hier keine Lösung gibt.

Vielen Dank!

 

[fxbastler]

Zwischen DTMF-Eingabe und Transfer vergehen dadurch konstant ca. 4–5 Sekunden

Ich kann dir bestätigen: das ist auch bei 3CX Anlagen mit 3-stell. int. Nummernkreis der Fall. Es ist auch egal, ob die Option Anrufern das Wählen von Nebenstellen erlauben aktiviert ist oder nicht. Es dauert in jedem Fall so lange.

Per Backup-Export bestätigt, dass der GUI-Schalter die DN-Eigenschaft DIRECT_FROM_IVR an der jeweiligen Digitalen Rezeption nicht in die Konfigurationsdatenbank schreibt, der Wert bleibt trotz Speichern (und Neustart) auf 1
DIRECT_FROM_IVR = 0 daraufhin manuell über die DN-Eigenschaften-Tabelle gesetzt (via DEVELOPMENT_DNTABLE_EXPOSE = 1)
Nach jeder Änderung vollständiger Neustart der Anlage

Wenn du damit die Option

Das Deaktivieren von „Anrufern das Wählen von Nebenstellen erlauben" in der Admin-Konsole

meinst: das ist die DN Property TRANSFER_ENABLE.
Mit ändern der Option Anrufern das Wählen von Nebenstellen erlauben wechselt der Wert zw. 0 und 1.

Aber ja: die Nutzung dieser Option funktioniert und tut - zumindest bei 3CX mit int. 3-stell. Nummernkreis - genau das wofür sie gemacht ist. Da wir keine einzige 3CX mit 2-stelligen int. Nummernkreis verwalten kann ich deine Aussage (Durchwahl zu int. NSt. ist immer möglich) weder bestätigen noch widerlegen. Vielleicht testet das mal ein Kollege irgendwo anders.
Ich habe jetzt gerade wenig Ambitionen und nicht die Zeit um: ein Backup der Testmaschine zu ziehen, die 3CX zurückszusetzen, das Backup zu modifizieren, das modifizierte Backup einzuspielen, die restl. Anpassungen an der 3CX vorzunehmen, die IVR einzurichten, das Szenario noch einmal zu testen und das dann alles wieder an der Testanlage rückgängig zu machen.

Als nächste Variante würde ich die zwei IVRs dann mit CFD bauen wenn es hier keine Lösung gibt.

Das ist keine schlechte Idee. So lassen sich auch komplexere Szenarien abbilden. Manko: das ist dann eine recht statische Sache in der 3CX - außer man modifiziert den C# Code vom CFD später direkt in der 3CX. Das ist möglich und nicht kompliziert aber ohne Erfahrung recht unübersichtlich und nicht zu empfehlen.
Oder man verwendet gleich ein C# Anrufskript für alles, wobei die Programmierung da wg. DTMF ein klein wenig anders ist. Es gibt dazu ein Beispiel direkt von 3CX. So wie im CFD kann man auch dort über die Funktion GetUserInputAsync gezielt die Wartezeit verkürzen.

 

[eliasr]

Hallo Zusammen,

Vielleicht testet das mal ein Kollege irgendwo anders.

Wir haben eine Anlage mit 2-stell. int. Nummernkreis. Ich habe das Szenario einmal nachgestellt.
- V20 Update 9, Build 20.0.9.995
- IVR's mit dem Typ Standart
- "Anrufern das wählen von Nebenstellen erlauben" deaktiviert
- Menütaste 1 testweise belegt

1: Wenn ich von extern per DID einen IVR anrufe und während der Ansage die 1 wähle findet nach 4 Sekunden der Transfer statt. (Soweit ich weis kann man gegen die verzögerung auch nichts machen)
2: Wenn ich von extern per DID den IVR anrufe und während der Ansage die Nebenstelle 13 (aktiver und angemeldeter Nutzer) wähle kommt "Das Ziel ist nicht ereichbar, nicht registriert oder es gibt keine verfügbaren Routen." und die Ansage beginnt von vorne.


Dementsprechend kann ich das:

Das Deaktivieren von „Anrufern das Wählen von Nebenstellen erlauben" in der Admin-Konsole bleibt ohne Wirkung

leider nicht bestätigen :/

Ich würde eventuell mal ein Support Ticket aufmachen. Das die Option "Anrufern das wählen von Nebenstellen erlauben" nicht korrekt funktioniert sollte nicht sein.

Falls ich hier was missverstanden habe bzw. nochmal anders testen soll/kann gerne Bescheid geben!

Erstmal weiterhin viel Erfolg

 

[AlexSess]

Hallo zusammen,

erstmal vielen Dank für die Antworten und eure Zeit,
korrekt ist, dass es sich hier um TRANSFER_ENABLE handelt und nicht um DIRECT_FROM_IVR.

Danke für die Aufklärung. Ich kann bestätigen, dass der GUI-Schalter bei mir auch den Wert korrekt setzt.

Damit ist der Punkt „Option ohne Wirkung" aus meinem Ausgangspost hinfällig, mein Testaufbau war zu diesem Zeitpunkt durch die manuell gesetzten Eigenschaften nicht mehr "verlässlich".

Bestehen bleibt die Verzögerung von 4–5 Sekunden zwischen Tastendruck und Transfer, die ihr beide unabhängig voneinander bestätigt habt.
Jetzt weiß ich das dass kein Einzelfall unserer Installation ist, mir ist es entweder früher nie aufgefallen oder in der v18 mit dtmf-input als IVR Typ war das nicht so?

Was mir noch aufgefallen ist: Bei der Weiterleitung zwischen zwei IVRs war jeweils ganz kurz die Wartemusik zu hören.
Ich habe die onhold-Datei deshalb am Anfang mit zwei Sekunden Stille versehen, damit das nicht mehr auffällt.
Funktioniert als Workaround, wirkt aber etwas unelegant meiner Meinung nach.

@fxbastler: Vielen Dank für den Hinweis auf "GetUserInputAsync" das klingt genau nach dem, was wir brauchen.
Wir werden das Menü entsprechend als CFD bzw. Anrufskript umsetzen.

Ich komme voraussichtlich nächste Woche dazu und berichte dann.

Viele Grüße

 

[fxbastler]

Vielen Dank für den Hinweis auf "GetUserInputAsync" das klingt genau nach dem, was wir brauchen.
Wir werden das Menü entsprechend als CFD bzw. Anrufskript umsetzen.

Das war ja nur ein Beispiel und ein Verweis.
Der CFD ist für den Anfang vmtl. die bessere Wahl. Der ist intuitiver in der Programmierung und Umsetzung. Gerade das Handling von DTMF in Verbindung mit Menüs ist dort sehr gut umsetzbar, genau dafür ist der gemacht.
Bei C# ist es das eher nicht und die div. Coding Agenten helfen einem derzeit auch nicht wirklich weiter. Da kommt i.d.R. ab einer gewissen Komplexität nur nicht funktionierender Schrott raus.

Was mir noch aufgefallen ist: Bei der Weiterleitung zwischen zwei IVRs war jeweils ganz kurz die Wartemusik zu hören.

Kann ich gerade nicht nachvollziehen,

Ich habe die onhold-Datei deshalb am Anfang mit zwei Sekunden Stille versehen, damit das nicht mehr auffällt.

... aber das ist auch eine Lösung