Weiterleitungsregeln durcheinandergewürfelt - ohne Funktion

[mmk]

Hallo liebe Community,

ich stehe vor einem kleinen Problem mit den Weiterleitungseinstellungen bei den Statusoptionen und hoffe, dass jemand von euch mir weiterhelfen kann. Es scheint so, als ob die Einstellungen nicht richtig funktionieren und ich weiß nicht, was ich falsch mache.

Bei den einzelnen Nebelstellen und dazugehörigen DNDs gibt es das Phänomen, das ist nicht das passiert, was bei den Nebenstellen eingestellt ist wenn die einzelne DND abwesend ist.
Mal kommt man auf eine flasche Warteschleife, mal auf die Mailbox der Nebenstelle. Allerdings sind eigentlich alle Nebenstellen so eingerichtet, dass die Weiterleitung auf eine bestimmte Queue erfolgen soll. Das klappt bei vielen plötzlich nicht mehr. Erneutes Abspeichern hat nicht geholfen.

Hat jemand eine Idee, was ich übersehen haben könnte oder wie ich das Problem lösen kann?

Vielen Dank im Voraus für eure Hilfe!

Liebe Grüße

 

[fxbastler]

Hallo @mmk ,

das 3CX Aktivitätenprotokoll in der Protokollierungsstufe Mittel sollte aufzeigen, wie und warum der Anruf dort hin kommt wo es ruft. Alternativ dazu den 3CX Log Viewer benutzen.

 

[mmk]

Hallo @mmk ,

das 3CX Aktivitätenprotokoll in der Protokollierungsstufe Mittel sollte aufzeigen, wie und warum der Anruf dort hin kommt wo es ruft. Alternativ dazu den 3CX Log Viewer benutzen.

Hi. Danke für den Hinweis.

15.05.2023 19:17:49 - [Flow] Call(C:413): applied forwarding rule (Fwd[Away/AllCalls]) Extn:18 -> VMail:99

15.05.2023 19:17:49 - [Flow] Target endpoint for 18 is VMail:99

15.05.2023 19:17:49 - [Flow] Target endpoint for 18 is VMail:99

Das Protokoll besagt, dass das die Forwarding Rule wäre. Das ist aber nicht der Fall. Für keinen Status ist hier eine Weiterleitung auf die Mailbox eingerichtet. Ich habe auch die Weiterleitungsregeln neu abgespeichert und sogar testweise auf etwas anderes gestellt und dann wieder zurückgestellt. Es bleibt dabei.

 

[fxbastler]

Es greift die Regel für den Status Abwesend (in diesem Fall noch: alle Anrufe) für die Nebenstelle 18. Diese verweist auf die Mailbox der Nebenstelle.

Ist das so in der 3CX eingestellt: die Nebenstelle 18 ist (war zum Zeitpunkt des Log) im Status Abwesend und im Status Abwesend ist die Weiterleitung an die Mailbox eingestellt?

 

[mmk]

Die Nebenstelle 18 ist für interne sowie externe Anrufe im Status Abwesend für die Weiterleitung an eine Warteschleife eingestellt.

 

[fxbastler]

Die Nebenstelle 18 ist für interne sowie externe Anrufe im Status Abwesend für die Weiterleitung an eine Warteschleife eingestellt.

Aber man sieht: laut Protokoll wird die Mailbox der NSt. 18 angesprochen.
Dafür gibt es mehrere mögliche Gründe: Ist die Warteschleife direkt anrufbar? Ist die Nebenstelle 18 Mitglied dieser Warteschleife? Waren zum Zeitpunkt des Anrufes überhaupt (sinnvollerweise auch verfügbare) Agenten in der Warteschleife angemeldet? Gibt es definierte Ausnahmen für die Nebenstelle 18? Besagt die Regel des Anrufes auf die Nebenstelle 18 (der Hop davor) vielleicht, das an deren Mailbox vermittelt werden soll? Das hier gepostete Log gibt das nicht her.

Sonst kurzzeitig testweise die Protokollierungsstufe des Aktivitätenprotokoll auf 'Ausführlich' stellen und damit so einen Testanruf starten. Alternativ den 3CX Log Viewer benutzen, der ist sehr ausführlich.

Sonst (wenn der Fehler reproduzierbar ist): Nebenstellenendgeräte entbinden, Nebenstelle löschen und komplett neu einrichten. Alternativ (wenn die Anlage mal irgendwann ein Problem mit der Hardware, einem Update oder der Spannungsversorgung hatte): Backup erzeugen, Anlage zurücksetzen und Backup wieder einspielen. Aber da muss es schon gute Gründe dafür geben.

 

[mmk]

Hi @fxbastler

22.05.2023 23:05:17 - [Flow] Call(C:7): applied forwarding rule (Fwd[Away/AllCalls]) Extn:18 -> VMail:99

22.05.2023 23:05:17 - [Flow] Building VoiceMail target of endpoint 18 from "Caller1:Caller2" <sip:[email protected]:5060>

22.05.2023 23:05:17 - [Flow] Endpoint VMail:99 has no forwarding rule on reason 'All calls'

Das steht im Protokoll.

Ist die Warteschleife direkt anrufbar?
Nicht von extern, aber intern.

Ist die Nebenstelle 18 Mitglied dieser Warteschleife?
Ja
Waren zum Zeitpunkt des Anrufes überhaupt (sinnvollerweise auch verfügbare) Agenten in der Warteschleife angemeldet?
Ja

Gibt es definierte Ausnahmen für die Nebenstelle 18?
Keine Ausnahmen

Besagt die Regel des Anrufes auf die Nebenstelle 18 (der Hop davor) vielleicht, das an deren Mailbox vermittelt werden soll? Das hier gepostete Log gibt das nicht her.
Das müsste ja so bei den eingehenden Regeln definiert sein, ist es aber nicht.

Sonst (wenn der Fehler reproduzierbar ist): Nebenstellenendgeräte entbinden, Nebenstelle löschen und komplett neu einrichten.
-> Wollte das vermeiden, weil das Verhalten tatsächlich in ähnlicher Form bei einem Haufen von Nebenstellen auftritt. Müsste alle neu einrichten...

 

[fxbastler]

Hallo,

einige grundsätzliche Fragen die hier nicht nicht gestellt wurden:

• 3CX Version, z. B. Professional Jahreslizenz 18.0.7.312
• Server OS, z. B. Debian 10 / Windows Server 201x (welche Version)
• Wenn On-Premise oder selbst gehostet: Wird die 3CX Virtualisiert betrieben und wenn ja wie? bitte eine einfache kurze Beschreibung, z.B. ja, vollvirtualisiert, KVM mit PVE
• Wenn On-Premise oder selbst gehostet: Auf welcher Hardware läuft die 3CX? bitte eine einfache kurze Beschreibung
• Gab es wesentliche Änderungen (Hardware und oder Software) an der 3CX vor dem beschriebenen Problem? ja (Hardaretausch, Software Upgrade 3CX, bitte kurz beschreiben) /nein
• Gab es wesentliche Änderungen (Hardware, Einstellungen) im Telefonienetzwerk vor dem beschriebenen Problem? ja (Hardaretausch, Erweiterung, Netzwechsel, bitte kurz beschreiben) /nein
• Ist das eine 3CX Erstinstallation? Wie lange läuft diese schon? ja/nein (läuft schon seit 3CX Version xyz), läuft seit xyz
• Wurde die 3CX selbst und mittels der 3CX ISO (Debian) / Installer (Windows) installiert? ja/nein
• Marke/Modell/Firmware-Version Ihres IP-Telefons, z. B. Yealink T54W Firmware 96.86.0.74
• Provisionierungsmethode: lokal/VPN/STUN/SBC
• SIP-Trunk-Anbieter oder Marke/Modell des VoIP-Gateways, z. B. AT&T SIP-Trunk / Grandstream GXW-4104
• War der Firewall Checker erfolgreich?: ja/nein
• Nutzen Sie benutzerdefinierte Telefon-Templates?: ja/nein
• Wechselt der Status der Nebenstelle beim Drücken der DND Taste am zugehörigen Telefon auf DND?: ja/nein
• Kann man den Status der Nebenstelle manuell wechseln lassen, z.B. über die 3CX Verwaltungskonsole?: ja/nein

TEILEN SIE NIE: Lizenzschlüssel, öffentliche IP-Adressen, E-Mail-Adressen, Benutzernamen, Passwörter, FQDNs, Provisionierungs-URLs, etc.

Sonst (wenn der Fehler reproduzierbar ist): Nebenstellenendgeräte entbinden, Nebenstelle löschen und komplett neu einrichten.
-> Wollte das vermeiden, weil das Verhalten tatsächlich in ähnlicher Form bei einem Haufen von Nebenstellen auftritt. Müsste alle neu einrichten...

Mit einer einzelnen NSt. evtl. probieren? Es muss ja einen Grund für das absonderliche Verhalten geben.

 

[fxbastler]

Nachträglich noch vier Fragen:

1. Wechselt die Anlage automatisch zw. Geschäfts- und Nichtgeschäftszeiten oder ist die dauerhaft im manuellen Status (z.B. per *64x, Reset evtl. mit *64)?
2. Lassen die betreffenden NSt. denn sonst (intern und oder direkt) anrufen - evtl. wurde eine Umleitung im Telefon selber eingerichtet?
3. Wurde an einem Telefon einer solchen NSt. zur Sicherheit schon einmal die *60 gewählt?
4. Was für Endgeräte werden denn allg. verwendet?

Wegen Frage 3: evtl. wurde die NSt. mittels des Funktionscode *61 unwissentlich auf DND gestellt. Das sieht man in der 3CX nicht.

 

[mmk]

Hi @fxbastler
Dein Hint bzgl. Geschäfts- und Nichtgeschäftszeiten hat den Case denke ich einen Schritt weiter gebracht.
Wenn ich diese Option aktiviere:

dann besteht das Verhalten nicht mehr (allerdings gehen die Nebenstellen nach den Geschäftszeiten automatisch auf Nicht Stören, was nicht gewünscht wäre.)

Es scheint also etwas bei den Geschäfts- und Nichtgeschäftszeiten nicht zu stimmen. Ein Reset mit *64 hat allerdings keine Wirkung bei diesem Verhalten gezeigt. Ich probiere es morgen nochmal aus.

 

[patrickb]

Beliebter Fehler in solchen Fällen ist auch immer das irgendwelche User, irgendwelche Weiterleitungen/Umleitungen direkt an ihren Endgeräten gemacht haben, die bei einer Autoprovisionierung nicht mit überschrieben/gelöscht werden.

Hatte ich auch gerade erst wieder. Bis ich drauf gekommen bin hats nen kurzen Augenblick gedauert.

 

[fxbastler]

Beliebter Fehler in solchen Fällen ist auch immer das irgendwelche User, irgendwelche Weiterleitungen/Umleitungen direkt an ihren Endgeräten gemacht haben, die bei einer Autoprovisionierung nicht mit überschrieben/gelöscht werden.

Hatte ich auch gerade erst wieder. Bis ich drauf gekommen bin hats nen kurzen Augenblick gedauert.

Ja, das haben wir auch oft genug, siehe mein Hinweis 2 hier. Die Telefonanwender wollen so etwas haben, fragen bei der IT an und die erklären langwierig wie das in der 3CX mit Umstellung der Art und Ziele eines Status im Webclient geht (viele wissen, wovon ich hier gerade schreibe). Die ganz schlauen Anwender holen sich dann das Manual des Telefones beim Hersteller, finden die Funktion (Grandstream z.B. *72<nummer> in den erweiterten Funktionen, geht mit *73 wieder zu deaktivieren) und stellen das manuell so ein. Das sieht man an der 3CX nicht. Das wissen die später selber nicht mehr. Wenn das Telefon (das Gerät) zeitweilig besetzt oder offline ist, dann greift in diesem Moment diese Telefonumleitung nicht und dann funktionieren die in der 3CX eingestellten Umleitungen alle so wie sie sollen - aber eben nur dann.

 

[patrickb]

Dazu sei noch gesagt: du kannst den Usern das auch schwerer machen und nur so ermöglichen wie @fxbastler beschrieben hat. (Falls da leute in der 3CX selver Weiterleitungen konfigurieren)

Einfach in den Provisionierungseinstellungen der 3CX App das Häkchen bei "Weiterleitungsregeln in 3CX Apps ausblenden/nicht anzeigen" setzten.

So schliesst du auch aus das User selber rumfummeln und du langwierig jede Nebenstelle durchgucken musst.

Viele User verstehen nicht das die 3CX eine Anlage ist, die viel "mitdenkt" und selber weiß was zu tun ist - wenn sie richtig eingerichtet wurde und der Admin alle Eventualitäten durchdacht hat.

 

[fxbastler]

Viele User verstehen nicht das die 3CX eine Anlage ist, die viel "mitdenkt" und selber weiß was zu tun ist - wenn sie richtig eingerichtet wurde und der Admin alle Eventualitäten durchdacht hat.

Viele verstehen nicht (und vergessen es trotz unserer Erklärung zu Anfang wieder), dass die Telefone nicht eigenständig operieren sondern nur Teil einer Anlage sind. Die wollen immer eine Anleitung vom Telefon haben und finden darin andere Menüs, andere Display Ansichten und eine andere Menüführung vor wie am Gerät. Diese Herstelleranleitungen sind alle immer für den eigenständigen Betrieb des Gerätes geschrieben. Die brauchen eine Anleitung von der 3CX für das Gerät. Wir haben einige wenige bebilderte Kurzanleitungen extra dafür gebaut. Aber dennoch wird rumgebastelt. Also: Factory Reset und erneut ausrollen.

 

[mmk]

Also ich bin nochmal ein Schritt weiter: Hier ist bei den Snom M70 Telefonen keine spezifische Weiterleitungsregel eingestellt.
Allerdings greift die eingestellte Weiterleitungsregel für externe Anrufer nur dann, wenn eben die Option "Status während der Geschäftszeiten auf Verfügbar setzen". Wenn das nicht eingestellt ist, und der User ist Abwesend, geht der Call direkt auf die Voicemailbox, egal was eingestellt ist. Es wird also nicht irgendwo anders hin weitergeleitet.

 

[mmk]

Das steht im Log, obwohl ich zum Beispiel testweise eine Weiterleitung auf eine andere Nebenstelle für diesen Status aktiviert habe:

26.05.2023 14:18:35 - [Flow] Call(C:1095): applied forwarding rule (Fwd[Away/AllCalls]) Extn:07 -> VMail:99

26.05.2023 14:18:35 - [Flow] Target endpoint for 07 is VMail:99

26.05.2023 14:18:35 - [Flow] Target endpoint for 07 is VMail:99

26.05.2023 14:18:35 - [Flow] Call(C:1095): has built target endpoint: Extn:07 for call from L:1095.1[Line:10002<<xxxxxxxx]

 

[mmk]

Hat noch jemand von euch eine Idee?

 

[fxbastler]

Hat noch jemand von euch eine Idee?

Ja, ganz viele. Aber das wird sich jemand in der Anlage ansehen müssen. Entweder der 3CX Partner der dafür bezahlt wird oder der 3CX Support.

Wir werden mit dieser Salamischeibchentaktik vmtl. hier im Forum nicht zielführend erfolgreich sein. Oben steht alles, damit du dir selber helfen kannst.

 

[patrickb]

Eine weitere Option wäre sofern die Anlage relativ simpel aifgebaut ist einfach eine komplette Neuinstallation.

Die DWs kannste dir ja vorher Exportieren als csv und später wieder uploaden. Dann die Telefone zurücksetzen und fertig.

Dann sollte es clean sein. Manchmal ist das der einfachste und auch ökonomisch sinnvollste Weg bevor man Stunden in die Fehlersuche investiert, die kein Ergebnis bringt.

 

[mmk]

Hi @patrickb und @fxbastler - da die PBX leider nicht so simpel aufgebaut ist, sondern zahlreiche Configs auch zu Warteschleifen, Signalisierungsgruppen, etc. hat und mehr als 50 Nebenstellen wollte ich in jedem Fall vermeiden die PBX neu aufsetzen zu müssen. Wir mussten das schon mal machen als die PBX kleiner war, und es war schon letztes mal mit deutlichen Beeinträchtigungen verbunden, bis alles wieder hergerichtet ist, wie es benötigt wird. Die oben genannten Optionen auch insb. bzgl. selbst angelegter Weiterleitungen in den Endgeräten habe ich auch schon geprüft. Insbesondere tritt dieses Phänomen bei manchen Nebenstellen auch auf, die nur den (Web-)Client haben, sonst keine anderen Telefongeräte.
VG