Eingehende Anrufe landen direkt auf der Mailbox

  • Like
Reaktionen: bitn2
Ich habe mich hier noch nicht eingelesen, aber ich würde das generell und einfach wie folgt testen:
  • eine komplett neue NSt. anlegen
  • eine eingehende Regel darauf einrichten
  • die NSt. mit dem Webclient in einem Chrome basierten Browser öffnen (dabei die entspr. Berechtigungen für Mikro usw. geben)
  • anrufen lassen und selber anrufen ...
Vielleicht ist etwas an der NSt., mit dem Smartphone - was auch immer. Prinzipiell wissen wir ja alle, dass es funktionieren kann und sonst überall auch tut.

Laut o.g. Protokoll legt entweder die Smartphone App auf oder die wird nicht richtig erreicht. So sieht es scheinbar aus.
 
Alle Regeln für innerhalb und ausserhalb der Geschäftszeiten sind identisch gestellt so dass das keinen Unterschied machen sollte.
Ja wir wissen dass es generell funktioniert.
Von Nebenstelle zu Nebenstelle geht es auch (querbeet getestet, WebClient zu App, App zu App, WebClient zu WebClient) klingelt es und erst nach 20 Sekunden kommt die Mailbox wie konfiguiert.
Nur die Anrufe von Extern landen direkt auf der Mailbox, egal auf welcher Nebenstelle angerufen wird, auch wenn die 0 gewählt wird (Signalisierungsgruppe, Hunt). Es geht sofort die Mailbox ran, und die oberste Nebenstelle der Jagd bekommt einen verpassten Anruf nachdem aufgelegt wird.
 
Wurde das denn probiert was ich direkt darüber geschrieben habe? Dabei die eingehende Regel auch direkt auf die NSt. weiterleiten, nicht über eine Signalisierungsgruppe.
 
  • Like
Reaktionen: bitn2
Ja, die Nebenstellen haben jeweils eine eigene eingehende Regel mit direkter Durchwahl.
Ich habe sie inzwischen viermal neu angelegt.
Die Signalisierungsgruppe war nur einer meiner Versuche, es irgendwie zum funktionieren zu bringen.
 
Was mich noch wundert: wo kommt die 9 des eingehenden Anrufes her?

22.08.2022 12:39:58 - [CM505003]: Provider:[Peoplefone] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:9[email protected].xx.xx:5060]
 
Zuletzt bearbeitet:
  • Like
Reaktionen: bitn2
Das ist die SIP-User-ID des Trunks
 
Das ist die SIP-User-ID des Trunks
Wenn das so sein muss dann ist das so. Weiß ich nicht, wir haben nirgends peoplefone Kunden.

Noch etwas: es sieht so als, als würde der Anruf von einem Gerät hinter der IP 185.190.125.3 kommen (siehe Erklärung des ersten Invite, Zeile 5 von unten. Weiter oben (und damit später, aber laut Zeitstempel direkt zur gleichen Zeit) wird der Anruf von da aus abgebrochen:
22.08.2022 12:39:58 - Leg L:56.1[Line:10000<<089****] is terminated: Cause: CANCEL from 185.190.125.3:5060

Laut diesem dem hier geposteten Protokoll hört der eingehende Anruf auf. Daher macht dieses Log für mich nicht wirklich Sinn bei der Fehlersuche.

Um das vielleicht etwas zu erläutern: in diesem Protokoll geht der Anruf ein, wird weitergeleitet usw. aber der Anrufer legt postwendend auf. Ja, dann bekommt der Angerufene einen verpassten Anruf angezeigt. Es wird zu keinem Zeitpunkt gerufen haben, dafür war einfach nicht genug Zeit.
 
Das ist korrekt interpretiert - ich rufe von extern an und lege (inzwischen recht frustriert ;) auf, sobald ich die Mailboxansage höre.
 
Zwischen dem ersten Flow / der Info on incoming INVITE, dem Alerting Extension 10 und dem xyz is terminated, cause ... vergeht quasi keine Zeit. Das passiert alles gleichzeitig.
 
Dann muss da der Wurm liegen - ich höre die Mailboxansage bestimmt 2-3 Sekunden bevor ich auflege. Die Logs sehen immer so aus, dass alles zur selben Millisekunde passiert.
 
Dann mal länger klingeln lassen und schauen ob das immer noch so aussieht. Nur zur Sicherheit: wenn eine Mailbox annimmt, dann ist es die der 3CX? Die Mailbox von diesem eingehenden Anruf? Keine Fallbackup Nummer o.ä.?
 
@Mike Berger
Gibt es hierzu schon etwas Neues?
Würde mich auch interessieren, wo bei dem Fall der Wurm drin ist.
 
Es gibt nichts Neues, leider.

@fxbastler zur Sicherheit: ja es geht um die 3cx mailbox, keine Fallbacknummer oder so.

Habs grad eben nochmal versucht, vom externen DE Festnetz auf meiner Nebenstelle angerufen. Es kommt sofort die Mailboxansage. Hab mir selbst was draufgesprochen und erst nach 15 Sekunden aufgelegt.

Hab auch prompt ne Email bekommen über den verpassten Anruf und eine zweite über die neue Sprachnachricht.

Im Log steht wieder das gleiche, alles zur selben Zeit, als ob ich sofort aufgelegt hätte.
 
Wenn im Aktivitätenprotokoll sonst nichts brauchbares darüber oder darunter steht gehen uns hier über das Forum die sinnvollen Möglichkeiten der Fehlersuche aus. Das mit der Zeit sollte so nicht sein, dazu noch weitere kleine Ungereimtheiten.

Man könnte sich einem Paketmitschnitt mit wireshark anschauen, aber der SIP Flow sollte bis zum Cancel seitens des Providers gut aussehen, bringt vmtl. nichts.

Ideen haben wir genug: man könnte weitere Protokolle auswerten - evtl. mit dem 3CX Log Viewer (so weit das bei einer hosted eben geht), man könnte sich ein Backup holen, die Anlage zurücksetzen und das Backup wieder einspielen. Aber das ist hier nur bedingt sinnvoll.

Da das eine hosted by 3CX ist: entweder kann dir im Forum noch einer vom 3CX Support direkt weiterhelfen oder du kannst einen Live Chat starten.
 
Zuletzt bearbeitet von einem Moderator:
Hab ne Mail geschrieben an das Hosting-Team, die Antwort: Es ist kein technisches Problem mit der PBX, daher soll ich ein Ticket bei einem Partner öffnen (und dafür zahlen).

Danke für Eure Mithilfe.
 
Zuletzt bearbeitet von einem Moderator:
Hallo zusammen,

ich habe genau die gleichen Probleme, wie @Mike Berger.

Gab es hierzu schon eine Lösung?

Ich selber habe Easybell als VoIP Anbieter.
Anrufe gehen direkt auf die Mailsbox. Nur der Anruf wird aufm Smartphone (Xioami Redmi Note 11 Pro 5G) oder der Desktop App angezeigt.
Hier ist es egal, ob das Handy mitm WLAN oder Mobilfunk verbunden ist.

Interessanterweiße gab es auch schon Fälle, da kam der Anruf auf der 3CX Smartphone App an und konnte angenommen werden, aber auf der anderen Seite ist weiterhin die Mailbox aktiv.

Hat hierzu jemand eine Lösung?

Anbei die Logs der Hostet 3CX Anlage.

Grüße
Kevin

1688554098490.png
 
Hi @kevco97,

kannst du uns bitte ein Ticket öffnen, damit wir der Sache auf den Grund gehen und dir weiterhelfe können.
 
  • Like
Reaktionen: kevco97
Guten Tag zusammen,
das Thema haben wir auch gehabt.
Die Lösung war nicht so schnell zu finden.
Der SIP Trunk hatte noch eine weitere 3CX, die wir als Testreferenz benutzt haben, halb verbunden. Die Anlage wurde zurück gebaut, Der Trunk hatte aber noch eine Anbindung daran, obwohl der Trunk aus der Anlage gelöscht wurde.
Darauf gekommen bin ich nur, weil ich die Dienste der anderen 3CXn beendet hatte. Dann gingen die externen Anrufe sofort und zwar richtig.
Beim SIP Trunk Anbieter sieht man dann in den Einstellungen mehr als die eine Telefonanlage.
Wünsche einen schönen Sonntag

Peter
 

Statistik des Forums

Themen
44.765
Beiträge
233.684
Mitglieder
78.501
Neuestes Mitglied
Erich Gasser