eingehende Anrufe werden direkt nach Annahme beendet

[ichbins]

Folgendes Problem:
- ausgehende Rufe funktionieren wie gewohnt
- bei eingehenden Anrufen an Warteschleifen werden diese direkt beendet - der Anrufer bekommt ein Besetztzeichen
- bei eingehenden Anrufe an Nebenstellen bekommt der Anrufer einen normalen Wählton, sobald der Empfänger versucht, das Gespräch anzunehmen wird dieses ebenfalls sofort beendet und der Anrufer bekommt ebenfalls ein Besetztzeichen

Die Anlage lief bis Donnerstag normal. In der Nacht gab es einen Strom- und Internetausfall hier im Industriegebiet. Seitdem das o.g. Verhalten. Durhc den zeitlichen Zusammenhang habe ich einen Fehler im Trunk vermutet - Telekom sagt nach Prüfung (was immer das auch heißt), der Fehler liegt bei mir.

Irgendwelche Tipps, wo und wonach ich suchen muss?

Version 18.0 (Build 441)/Enterprise

 

[fxbastler]

Hallo,
was steht denn bei solchen Testanrufen im 3CX Aktivitätenprotokoll (wenn dieses auf die Stufe Mittel gestellt wurde), woher diese Anrufe kommen und wohin diese weitergeleitet werden sollen usw.?

 

[fxbastler]

Bitte o.g. noch einmal als Code Block posten, danke.

 

[ichbins]

Ah - sorry:

05.06.2023 12:20:03 - Leg L:276.2[Extn:52] is terminated: Cause: BYE from local
05.06.2023 12:20:03 - [CM503008]: Call(C:276): Call is terminated
05.06.2023 12:20:03 - Leg L:276.1[Line:10000<<++49162*******] is terminated: Cause: BYE from 217.0.130.22:5061
05.06.2023 12:20:02 - Currently active calls - 1: [276]
05.06.2023 12:20:02 - [CM503007]: Call(C:276): Line:10000<<++49162******* has joined, contact <sip:[email protected]:0/TLS>
05.06.2023 12:20:02 - [CM503007]: Call(C:276): Extn:52 has joined, contact <sip:[email protected]:5060/UDP>
05.06.2023 12:20:02 - L:276.2[Extn:52] has joined to L:276.1[Line:10000<<++49162*******]
05.06.2023 12:19:52 - [CM505001]: Endpoint Extn:52: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CXPhone for Windows 16.3.0.264] PBX contact: [sip:[email protected]:5060]
05.06.2023 12:19:52 - [CM503002]: Call(C:276): Alerting Extn:52 by contact <sip:[email protected]:5060/UDP>
05.06.2023 12:19:52 - [CM503025]: Call(C:276): Calling T:Extn:52@[Dev:sip:[email protected]:5060;rinstance=1-190f8a2f6d19473297ad79025eaae6a3] for L:276.1[Line:10000<<++49162*******]
05.06.2023 12:19:52 - [CM503027]: Call(C:276): From: Line:10000<<++49162******* ("MV (mobil)" <sip:+49162*******@vortkamp.on3cx.de:5060>)  to  T:Extn:52@[Dev:sip:[email protected]:5060;rinstance=1-190f8a2f6d19473297ad79025eaae6a3]
05.06.2023 12:19:52 - [CM503004]: Call(C:276): Route 1: from L:276.1[Line:10000<<++49162*******] to T:Extn:52@[Dev:sip:[email protected]:5060;rinstance=1-190f8a2f6d19473297ad79025eaae6a3]
05.06.2023 12:19:52 - [Flow] No office hours set, office hours assumed
05.06.2023 12:19:52 - [Flow] Call(C:276): has built target endpoint: Extn:52 for call from L:276.1[Line:10000<<++49162*******]
05.06.2023 12:19:52 - [Flow] Target endpoint for 52 is Extn:52
05.06.2023 12:19:52 - [CM503010]: Call(C:276): Making route(s) from Line:10000<<++49162******* to <sip:[email protected]:5060/UDP>
05.06.2023 12:19:52 - [CM505003]: Provider:[Deutsche Telekom SIP-Trunk (NGN)] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:+49*********@217.xxx.xxx.xxx:5061;transport=TLS]
05.06.2023 12:19:52 - [CM500002]: Call(C:276): Info on incoming INVITE from Line:10000<<++49162*******:
Invite-IN Recv Req INVITE from 217.0.130.22:5061 tid=e27e5880b4c0b9244e929e9375e71b8e.3e9713c1 [email protected]:
INVITE sip:+49*********@217.xxx.xxx.xxx:5061;transport=TLS;rinstance=330e7e2beba56c01 SIP/2.0
Via: SIP/2.0/TLS 217.0.130.22:5061;branch=z9hG4bKe27e5880b4c0b9244e929e9375e71b8e.3e9713c1
Max-Forwards: 54
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tls;lr>
Contact: <sip:8uWotZ5IEVZx1NToVQ8qxJYS+Dt7KFS3jERGVLuASsa3mDFf1hu0oQpgJMU2shjz9Lpp@th1>
To: <sip:+492561******@telekom.de;user=phone>
From: <sip:+49162*******@sip-trunk.telekom.de;user=phone>;tag=92632c4d
Call-ID: [email protected]
CSeq: 48238704 INVITE
Expires: 180
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, UPDATE
Content-Disposition: session
Content-Type: application/sdp
Supported: 100rel, 199, histinfo, norefersub, uui
P-Asserted-Identity: <sip:+49162*******@sip-trunk.telekom.de;user=phone>
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
P-Called-Party-ID: <sip:+492561******@sip-trunk.telekom.de;user=phone>
Session-ID: 1d4cdd4d03098658f2d9dcdbccf7b553;remote=00000000000000000000000000000000
Content-Length: 755

v=0
o=- 103315660509021 103315660509021 IN IP4 217.0.130.22
s=on transit
c=IN IP4 217.0.133.5
t=0 0
m=audio 24964 RTP/SAVP 96 97 98 8 99
a=rtpmap:96 AMR/8000
a=rtpmap:97 AMR/8000
a=rtpmap:98 AMR/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:96 mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1; max-red=0
a=fmtp:97 mode-set=0,2,4; mode-change-period=2; mode-change-neighbor=1; max-red=0
a=fmtp:98 mode-change-capability=2; max-red=0
a=maxptime:30
a=ptime:20
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:2NhKi3r6cuLoLTZNY/00MuK2cr2eNbKCwbhdHVqU
a=crypto:6 AES_CM_128_HMAC_SHA1_32 inline:QIca/KN1ERjvZIws+Ywp8hIHhMiRJNOxk6PEpmTc
a=crypto:7 F8_128_HMAC_SHA1_80 inline:hizcLZO1iw3lFG5PvMIkmMLbm1aniv69DPJAct8R
05.06.2023 12:19:52 - [CM503001]: Call(C:276): Incoming call from Line:10000<<++49162******* to <sip:[email protected]:5060>

 

[fxbastler]

So, jetzt mal eben fix geschaut: das Problem, was ich sehe, ist die Aushandlung der Codecs. Da steht
m=audio 24964 RTP/SAVP 96 97 98 8 99
Die 8 (PCMA / G711.a) ist nicht vorn. Ich weiss nicht, wie die 9x-er nach vorn kommen und was genau das ist.

Wikipedia sagt dazu: Payload identifiers 96–127 are used for payloads defined dynamically during a session.

Hat die Telekom doch etwas geändert? Auch wenn die sagen, es ist nicht so, ist dem manchmal nicht so (SRTP?).

Hat die 3CX eine feste IP? Ist es noch dieselbe wie in der 3CX angegeben? Der 3CX Firewallcheck läuft noch grün durch?

 

[ichbins]

Hat die 3CX eine feste IP? Ist es noch dieselbe wie in der 3CX angegeben? Der 3CX Firewallcheck läuft noch grün durch?

Ja, die 3CX hat ene feste IP, die hat sich nicht geändert. Firewallcheck hab ich gerade nochmal gemacht - alles grün.

Hat die Telekom doch etwas geändert? Auch wenn die sagen, es ist nicht so, ist dem manchmal nicht so (SRTP?).

Tja - was soll ich Dir dazu sagen? Kann ich das prüfen?

So, jetzt mal eben fix geschaut: das Problem, was ich sehe, ist die Aushandlung der Codecs. Da steht
m=audio 24964 RTP/SAVP 96 97 98 8 99
Die 8 (PCMA / G711.a) ist nicht vorn. Ich weiss nicht, wie die 9x-er nach vorn kommen und was genau das ist.

Das sind für mich zugegeben böhmische Dörfer. Im Trunk ist diese Reihenfolge hinterlegt:



Sollte ich daran was ändern? Würde eine Änderung auf Telekom-Seite sich nicht genauso auf ausgehende Telefonate auswirken?

Danke!

 

[fxbastler]

Sollte ich daran was ändern?

Ich würde es so belassen.

Ist im SIP Trunk SRTP aktiviert?

 

[ichbins]

Ist im SIP Trunk SRTP aktiviert?

War es nicht. Hab ich geändert und das scheint das Problem gewesen zu sein.

Vielen, vielen Dank!!!

 

[bitn]

Hallo zusammen,

hatte heute auch bei einem Kunden das Problem.
Habe umgestellt auf SRTP erzwungen seit dem läuft es wieder. Die Liebe Telekom ……

 

[ichbins]

Ich hab von "Deaktiviert" auf "Aktiviert" umgestellt. Bringt eine Änderung auf "Erzwungen" noch was?

 

[bitn]

Hallo,

die bewirkt das nur SRTP genutzt wird und nichts anderes angeboten wird.

 

[bitn2]

Wenn ich das richtig erinnere war das Problem das die 3CX sonst einen verschlüsselten und einen unverschlüsselten Stream anbietet und damit kann die Telekom nicht um.

 

[ichbins]

Eingehende Anrufe laufen nach wie vor stabil.

Aber ausgehende Telefonate wurden teilweise bei Annahme scheinbar grundlos abgebrochen. Im Ereignisprotokoll fand sich dafür dann jewels

Call or Registration to +49xxxxxxxxxx@(Ln.10000@Deutsche Telekom SIP-Trunk (NGN)) has failed. 217.0.130.20 replied: 500 Server Internal Error

Daraufhin hab ich jetzt SRTP von "Aktiviert" auf "Erzwungen" geändert. Stand jetzt (hab vor zwei Stunden umgestellt) taucht das Problem nicht mehr auf.

 

[avraammich_3CX]

Hi,

hatte ich hier schon erwähnt.

 

[ichbins]

Nachdem jetzt einen Monat alles stabil lief, tritt heute das gleiche Problem wieder auf:

- ausgehende Rufe funktionieren wie gewohnt
- bei eingehenden Anrufen an Warteschleifen werden diese direkt beendet - der Anrufer bekommt ein Besetztzeichen
- bei eingehenden Anrufe an Nebenstellen bekommt der Anrufer einen normalen Wählton, sobald der Empfänger versucht, das Gespräch anzunehmen wird dieses ebenfalls sofort beendet und der Anrufer bekommt ebenfalls ein Besetztzeichen

SRTP-Modus steht nach wie vor auf "erzwungen". Auch sonst gab es keine Änderungen. Die Ursache scheint also diesmal woanders zu liegen. Hat jemand spontan eine Idee?

 

[ichbins]

Korrektur: Es scheint doch mit dem SRTP-Modus zu tun zu haben. Wechsel ich diesen von "erzwungen" auf "aktiviert", kommen eingehende Anrufe wieder durch. Ein Problem mit ausgehenden Anrufen habe ich bis jetzt auch nicht. Ich bin verwirrt.

 

[ichbins]

Nach drei Monaten ohne Probleme oder irgendwelche Änderungen aus dem Nichts das gleiche Problem:

- ausgehende Anrufe funktionieren ohne Problem
- eingehende Anrufe an Warteschleifen brechen direkt ab
- eingehende Anrufe an Nebenstellen gehen durch, brechen aber direkt nach der Verbindung (innerhalb einer Sekunde) ab

Ideen anyone?

 

[avraammich_3CX]

Hi @ichbins,

öffne bitte hierfür ein Ticket so dass dir geholfen werden kann.
Ich würde dann persönlich den Fall bearbeiten.

 

[patrickb]

Hi @ichbins,

ich würde, da wir hier ja im On-Prem Bereich unterwegs sind auf ein Problem mit der (System-)Firewall tippen.

Auf was für einem System läuft die Anlage?
Linux? Windows? Windows Server?

Vor allem bei den letzten beiden kommt es ja häufiger vor, dass sich aus heiterem Himmel (z.B. nach einem Reboot, Updates, Ausfall, Wartung an Switches, Router Neustarts etc.) das Netzwerkprofil unbemerkt ändert, was wiederum Auswirkungen auf die Firewall hat.

Sind in der Firewall nun (meine Vermutung) einige Ports für alle Netzwerke freigegeben (Privat, Öffentlich, Domäne) und andere (die RTP Ports z.B.) nur für Private oder Domänen Netzwerke, der Rechner hat aber das Netz als Öffentlich eingestuft dann könnte hier das Problem entstehen.

Die Calls kommen rein, werden signalisiert und angenommen. Beim Aufbau des Gesprächs kommt es aber zu Problemen weil eben bestimmte Ports nicht einwandfrei laufen weshalb die Calls dann abgebrochen werden. Das würde auch zu deiner Fehlerbeschreibung passen.

Wenn Anrufe direkt auf eine Nebenstelle laufen, signalisieren sie nur und werden Seitens der Anlage noch nicht als angenommen klassifiziert. In dem Moment wo du dann abnimmst braucht er die Ports, die laufen nicht, Resultat = Anruf wird abgebrochen. Landet ein Anruf auf einer Warteschleife wird er direkt von der Anlage angenommen und so klassifiziert. Da bereits in dem Moment die Ports Probleme machen, wird in diesem Fall der Anruf direkt beendet. Da du das kurze Signalsieren vor der Annahme durch die Queue aber nicht mitbekommst, ergibt sich für dich eben das von dir beschriebene Fehlerbild.

Auch das mit den ausgehenden Calls die ohne Probleme laufen ergibt Sinn: Da die für den ausgehenden Anruf benötigten Ports ja zuerst von der 3CX "geöffnet" wurden, stehen diese i.d.R. auch für die entsprechenden Antwortpakete zur Verfügung (solange sie nicht explizit blockiert wurden).

Wie gesagt: Das kann alles völlig Banane sein was ich hier geschrieben habe. Wäre aber vor allem in Verbindung mit Windowssystemen eine denkbare Fehlerursache.