Call Routing für Durchwahl "49" wenn interne Teilnehmer beim externen Ruf das + der Landesvorwahl +49 nicht markiert haben

[redline]

Hallo Zusammen,

traurig aber wahr. Im Betreff genanntes Problem passiert wohl häufiger als man es sich vorstellen mag.

Wenn interne Kolleginnen und Kollegen eine Rufnummer mit deutscher Landesvorwahl markieren, dabei aber das + vergessen und wählen, wird der interne Benutzer mit Durchwahl 49 angerufen.

Dies kostet Arbeitszeit und der betroffene, genervte Mitarbeiter möchte gerne eine neue Durchwahl.

Ich würde das Problem aber gerne technisch lösen und habe mir überlegt dass es ja prinzipiell funktionieren müsste wenn via CallRouting geprüft wird, ob hinter der "49" noch weitere Ziffern gewählt wurden. Sofern dies der Fall ist, kann es sich nicht um einen gewünschten internen Anruf handeln und das Gespräch soll (ohne Benachrichtigung auf Telefon/Client) abgelehnt werden. Der Kollege wird hoffentlich zeitnah seinen Fehler bemerken und die vollständige Rufnummer wählen.

 

Weiß jemand, wie so eine Regel aussehen müsste?

 

Danke!

[jodost]

Du müsstest es mit dieser Variable abfragen können: 

 

 

(Und die dann einfach vergleichen, wenn sie nicht gleich 49 ist wurde offenbar was anderes gewählt).

 

Allerdings bin ich irritiert, dass es bei diesem Kollegen klingelt. Denn beim wählen mit f11 wird doch immer die amtsgrenze vorgewählt, das heißt er müsste 0- 49221... wählen, oder nicht?

 

Und wenn das der Fall ist, kannst du versuchen, die Täter in einen Standort zu verschieben, bei dem du als ortsvorwahl 00 einträgst. Wenn die das dann so wählen, hält die Swyx das für ein ortsgespräch nach 49221, setz die Vorwahl des Ortes, also 00 davor, und wenn du Glück hast wäre er dann sogar richtig.

[redline]

Hi,

ich muss mir das genaue Fehlerbild tatsächlich nochmal anschauen, ich habe es so weitergeleitet bekommen und nur in der Theorie durchdacht. Ob nun wirklich F11 gedrückt wird (wovon ich ausgegangen bin), muss ich nochmal prüfen.

 

Vielen Dank für den Denkanstoß...

 

Ich hätte die Regel nun wie folgt aufgesetzt:

 

'Wenn keine Ziffer nach der Durchwahl erkannt wird, wird die Regel übersprungen
'Ansonsten der Ruf abgelehnt

if PostDialingDigits = "" then
	UseExit = 0
else 	UseExit = 1

 

Sollte korrekt sein, oder? Teste es bei Gelegenheit mal.

 

EDIT: Ich hab es mir zu kompliziert gemacht.. Du sagstest ja schon, einfach "PBXCall.CalledPartyNumber" auf die 49 prüfen... Also:

'Wenn gewählte Rufnummer = Durchwahl (49) ist, wird die Regel übersprungen
'Ansonsten der Ruf abgelehnt

if PBXCall.CalledPartyNumber = "49" then
	UseExit = 0
else 	UseExit = 1

 

[redline]

So... Das Problem tritt in der Tat nicht auf, wenn das System korrekt verwendet wird. Ein Wählen via F11 landet nicht bei der internen Durchwahl.

Das Problem tritt auf, wenn die AnwenderInnen die Nummer (unvollständig) kopieren und ins Rufnummernfeld einfügen. 🙄

 

Ein erster Test meiner Regel war nicht erfolgreich, das lag aber primär daran, dass ich das end if vergessen habe. Außerdem ist die korrekte Funktion PBXCall.DialedNumber.

Das Script sieht daher nun so aus:

if PBXCall.DialedNumber = "49" then
	UseExit = 0
else 	UseExit = 1
end if

 

Funktioniert wie gewünscht, ABER leider wird der eingehende Anruf nun doch in der Liste entgangener Anrufe angezeigt.

Ist es möglich das zu unterbinden? Das Ablehnen soll völlig still im Hintergrund erfolgen.

[redline]

Hab's gefunden:

PBXCall.PhoneCallListEntry.Delete

 

Ein weiterer VB-Block vor dem Auflegen mit der Funktion und der Ruf ist nicht mehr ersichtlich!

 

Thema abgeschlossen, herzlichen Dank @jodost

[jodost]

Am 17.10.2022 um 10:53 schrieb redline:

Das Problem tritt auf, wenn die AnwenderInnen die Nummer (unvollständig) kopieren und ins Rufnummernfeld einfügen. 🙄

 

wenn Du diesen Anwendern einen Gefallen tun willst, packe sie in einen Standort "Automatische Amtsholung" und da lässt Du bei der Konfiguration dann die Vorwahl leer.

 

denn wer "4922112345" falsch reinkopiert, wird womöglich auch "0221123456" reinkopieren wollen und würde dann ja derzeit ein Ortsgespräch zu 221123456 führen. Durch die "fehlerhafte" Standort-Angabe biegt die Swyx diese Anrufe dann aber zufällig wieder richtig.

 

Hat zumindest bei der v11.38 (damals hatte Swyx zumindest im Yealink-CTI-Betrieb das automatisch-0-vorwählen-bei-F11 mal rausgeworfen) als Patch geklappt.