Eingehende Anrufe erst beim Zweiten mal Hörer abnehmen ist Anrufer verbunden

MOverhaus

Customer
Mitglied seit
10. Februar 2021
Beiträge
7
Guten Tag,

seit einiger Zeit haben wir das Problem, dass alle Externen Gesprächer erst beim zweiten Abnehmen entgegen genommen werden können. Beim ersten bekommen wir direkt ein Besetzt, dann klingelt es weiter, wenn wir erneut ans Telefon gehen haben wir das Gespräch. Interne Gespräche funktionieren auf Anhieb.

Das Problem tritt an allen Endgeräten auf, Tischtelefone, Handy App, Browser Telefonie und 3CX Windows App. (Sowohl im Haus wie auch extern über VPN)

Wir haben 3CX in Version 3CX Enterprise 16 SC Version 18 laufen. (es gibt zzt. keine Updates). Gehostet bei uns als Virtuellen Server.
Nutzen Snom D785 Tischtelefone, ein ganzes Register an Iphone 12 und auch das ein oder andere Android Handy (Apps sind auf aktuellstem Stand) ebenso wie die installierten Windows Apps.

Ich habe leider keine Idee mehr woran es noch liegen kann. Wir haben uns mittlerweile schon "fast" dran gewöhnt, es ist aber wirklich sehr nervig.

Vielleicht hat ja jemand eine Idee?!?

Marin
 
Hallo,

Fragen:
  1. Läuft der Firewall Test komplett grün durch?
  2. Was für ein SIP Trunk Provider (und ggf. Tarif) wird verwendet?
  3. Was ergibt denn das 3CX Aktivitätenprotokoll (in der Protokollierungsstufe mittel) bei solchen Anrufen?
  4. Was für Codecs werden verwendet (LAN, WAN, SIP Trunk, provisionierte Endgeräte)?
  5. Wird die 3CX nun: a) im eigenen Haus betrieben oder b) außer Haus?
  6. Wenn 2a: Befinden sich 3CX und die phys. Telefone im gleichen phys. LAN?
  7. Wenn 2b: Werden SBC benutzt?
  8. Was für eine Firewall wird benutzt?
  9. Auf was für einer Virtualisierungsplattform wird die 3CX betrieben?
  10. Ist das eine Windows oder Debian 3CX?
  11. Wird für die interne / LAN Provisionierung die IP oder der FQDN verwendet?
  12. Weil die 3CX virtualisiert betrieben wird: Wurden die 3CX Anleitungen bzgl. Zeiteinstellungen der 3CX Installation berücksichtigt?
  13. Tritt das Problem auch auf, wenn eine einzelne DID durch eine einzelne eingehende Regel direkt auf eine einzelne NSt. mit einem einzelnen Endgerät aufläuft und diese DID von extern angerufen wird?
 
Zuletzt bearbeitet:
Guten Morgen,

Anbei die Fragen mit Antworten. Ich hoffe ich habe nicht vergessen!

Fragen:
1. Läuft der Firewall Test komplett grün durch? Ja
resolving 'stun-eu.3cx.com'... done
resolving 'stun2.3cx.com'... done
resolving 'stun3.3cx.com'... done
resolving 'sip-alg-detector.3cx.com'... done
testing 3CX PhoneSystem 01 SIP Server... done
1. stopping service... done
2. detecting SIP ALG... not detected
3. testing port 5060... done
4. starting service... done
testing 3CX PhoneSystem Media Server... done
5. stopping service... done
6. testing port 5090... done
7. testing ports [9000..9398]... done
8. testing ports [10600..10998]... done
9. starting service... done

2. Was für ein SIP Trunk Provider (und ggf. Tarif) wird verwendet?
AGFEOtel 6925.voip.agfeo-tel.de
3. Was ergibt denn das 3CX Aktivitätenprotokoll (in der Protokollierungsstufe mittel) bei solchen Anrufen?
17.01.2023 07:51:37 Overhaus, Marin:Overhaus (01799442095) Overhaus (033) 00:00:02
17.01.2023 07:51:32 Overhaus, Marin:Overhaus (01799442095) Overhaus (033) 00:00:00
• Trunk L:10000(AGFEOtel) has changed status to registered.
SIP Server ID: 4100 17.01.2023 07:44:33
• Service started
SIP Server ID: 4097 17.01.2023 07:44:32
• Trunk L:90000(WebMeeting bridge) has changed status to registered.
SIP Server ID: 4100 17.01.2023 07:44:32
• Service got signal to stop: stop service
SIP Server ID: 4098 17.01.2023 07:44:24
Scheinbar nichts… oben das Anrufer Protokoll, unten das Ereignisprotokoll
4. Was für Codecs werden verwendet (LAN, WAN, SIP Trunk, provisionierte Endgeräte)?
Endgeräte
G711u
G711a
G722
G729
SIP:
G.711 U-law
G.711 A-law
G729

5. Wird die 3CX nun: a) im eigenen Haus betrieben oder b) außer Haus?
Wenn 2a: Befinden sich 3CX und die phys. Telefone im gleichen LAN?
a) Ja, die Mobilen Endgeräte meistens auch im selben W-LAN

6. Was für eine Firewall wird benutzt?
Sophos XG135
7. Auf was für einer Virtualisierungsplattform wird die 3CX betrieben?
Hayper-V Server 2019
8. Ist das eine Windows oder Debian 3CX?
Windows 10
9. Wird für die interne / LAN Provisionierung die IP oder der FQDN verwendet?
LAN Provisionierung
10. Weil die 3CX virtualisiert betrieben wird: Wurden die 3CX Anleitungen bzgl. Zeiteinstellungen der 3CX Installation berücksichtigt?
ja
11. Tritt das Problem auch auf, wenn eine einzelne DID durch eine einzelne eingehende Regel direkt auf eine einzelne NSt. mit einem einzelnen Endgerät aufläuft und diese DID von extern angerufen wird?
ja

Das Merkwürdige ist, dass alles über 2 Jahre gut lief. Und ohne eine aktive Veränderung fing dieses Phänomen über Nacht an.

Vg, Marin
 
Nachtrag:
17.01.2023 12:04:49 - [CM503003]: Call(C:102): Call to " Overhaus" <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 192.168.100.137:43306
17.01.2023 12:04:45 - [CM503003]: Call(C:100): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5063
17.01.2023 12:04:45 - [CM503003]: Call(C:100): Call to " Overhaus" <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 192.168.100.137:43306
17.01.2023 12:04:45 - [CM503003]: Call(C:100): Call to <sip:[email protected]:0> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5483
 
Zuletzt bearbeitet:
Oh, das sieht böse aus. Wenn so ein komplettes Log hier geschrieben wird, dann bitte leicht anonymisieren und bitte als Code Block posten.

Eines noch vorab: ich kenne zwar den SIP Trunk Anbieter agfeo-tel / kamikom nicht (habe mich eben kurz belesen), aber sehr wahrscheinlich wird auch der standardmäßig G.711a / PCMA nutzen und voraussetzen. Laut dem SIP Invite im Protokoll handelt der mit der 3CX auch G711.a aus. Also vmtl. die 3CX (LAN, WAN) und die provisionierten Endgeräte umstellen

Woher kommt das Provider Template? Wurde das selbst zusammengebastelt oder hat der Provider das irgendwann einmal bereitgestellt?

Wenn das bisher längere Zeit lief, dann wird es wohl an Änderungen liegen: SIP Trunk Anbieter, ISP, Firewall, deren Regeln, 3CX Update, Endgeräte FW - die Liste ist lang. Wenn bekannt ist, was im betreffenden Zeitraum geändert wurde, dann dem nachgehen. Sonst SIP Trunk Provider anfragen, auch für die geforderten Einstellungen oder gleich ein passendes Template für eine 3CX (falls es das bisher nicht gab oder es nicht aktuell ist).

Die Fehlermeldung SIP 487 besagt: der Anrufer hat aufgelegt. Das sieht aber eher aus wie ein Verhandlungsproblem. Ein weiterer möglicher nächster Schritt der Fehlersuche wäre eine Paketaufzeichnung in der 3CX und Auswertung u.a. auch des SIP Flow mit Wireshark.

Was mich eben in dem sehr schlecht leserlichen Protokoll wundert: 13:24:50 kommt ein INVITE mit aktivierter Verschlüsselung (aber UDP Protokoll) von außen (Zeile 56), kurz danach ruft es an der NSt. 33, 13:24:52 wird Anrufer und NSt. verbunden (Anruf angenommen, Zeile 40 usw.), aber in Zeile 37 wird vom Anrufer (agfeo tel?) getrennt (BYE) und neu verhandelt (wieder ein INVITE), nicht komplett aufgelegt. Dieser Anruf mit prinzipiell den gleichen Verhandlungsdaten aber ohne Verschlüsselung im INVITE wird komplett neu verhandelt, vermittelt und landet später irgendwann auch dauerhaft bei der annehmenden NSt.. Wurde denn Verschlüsselung im SIP Trunk beim Provider oder der 3CX aktiviert? Da scheint etwas nicht zu stimmen (UDP) und nicht zu funktionieren (Abbruch und Neuverhandlung).
 
Guten Tag,

die Lösung war doch denkbar einfach. Durch das Erzwingen des SRTP-Modus hat sich das Problem bei allen Endgeräte lösen lassen.
 

Statistik des Forums

Themen
44.414
Beiträge
232.720
Mitglieder
78.330
Neuestes Mitglied
uvitas