Nach Update Version 20.0 Update 8 (Build 1109 Release) - abbruch Gespräche

[rootex]

Hi,
seit dem Update werden ausgehende Gespräche nach genau 2 Minuten getrennt.

Jemand gleiches Phänomän.

Sind nicht alle, würde sagen, jedes 20-30 Gespäch. Die meisten sind aber auch unter 2 Min., welche dort getätigt werden.

 

[bitn2]

Na bei so reichhaltigen Infos kann dir bestimmt jemand helfen...

Fang doch erstmal damit an zu sagen wo deine 3cx installiert ist, wie die installiert wurde. Firewallcheck ok? Welcher Trunk Anbieter? Usw....

 

[rootex]

Ist eine VM - auf Windows Server - FirewallCheck läuft durch.
SIP-Trunk vom lokalen Provider der Stadtwerke.

Da es wirklich erst nach dem Update aufgetreten ist, dachte ich, es gibt vielleicht einen Zusammenhang.

 

[bitn2]

Nein da gibt es so erstmal keinen Zusammenhang... Windows Firewall geprüft? SIP Trunk dauerhaft verbunden? Auch wenn das Gespräch abbricht? Was sagt das ausführliche Log zu so einem Anruf? Ist das ein echter Trunk oder nur eine private Rufnummer vom Internet Tarif? Um welche Anbieter und Tarif dreht es sich denn?

 

[rootex]

So, habe mich nochmal intensiv mit der Problematik beschäftigt.
Ich habe mit dem Provider gesprochen, welcher mir mitteilte, dass mittlerweile 3 Kunden diesen Phänomen haben.
Alle 3 User haben eine 3CX Anlage.

Aufgefallen ist, das nur augehende Gespräche bestroffen sind.
Dann aber ALLE ausgehenden Anrufe - Diese werden nach exakt 120 Sekunden getrennt.

Wir haben dazu einen SIP-Trace erstellt. In der Signalisierung ist zu sehen:
im INVITE / 200 OK wird der Header Session-Expires: 120;refresher=uas gesetzt.

Während des Gesprächs erfolgt kein Session-Refresh (kein re-INVITE / UPDATE).

Nach ca. 120 Sekunden sendet der Provider ein BYE und beendet den Call.

Das BYE kommt vom Provider-Server.
NAT / Firewall / RTP-Ports wurden bereits geprüft.

Jemand noch eine Idee?
Prodvider sagt, wir haben nichts geändert, bei allen anderen läuft es!

 

[mbehrens]

Jemand noch eine Idee?

Wenn Wireshark dies wirklich bestätigt könnte man diesen Wert über die REST API per PowerShell anpassen.

 

[rootex]

Das ist aus dem Trace der Anlage? - Aber welchen Wert soll ich anpassen?

 

[patrickb]

Auch wenn du geschrieben hast das Ihr NAT/Firewall/RTP usw. schon durch habt:

Aktiviere im Trunk testweise mal Sticky Register. Dadurch werden m.W.n. der initiale INVITE und nachfolgende SIP-Requests (z. B. re-INVITEs) zwischen Anlage und Provider immer über denselben Server gesendet. Das verhindert bei manchen Providern Routing- oder NAT-Probleme weil z.B. durch Loadbalancing Antwortpakete plötzlich von anderen IPs kommen als beim ursprünglichen INVITE.

How-To:
Admin-> Erweitert -> Parameter -> DEVELOPMENT_DNTABLE_EXPOSE auf 1, danach Seite neuladen und über "Wählcode-Eigenschaften" die Propertys des Trunks aufrufen. Dort dann nach STICKY_REGISTER suchen bzw. diesen erstellen und auf 1 setzen. Im Template verändert es dann:

<field name="RegistrarInvite">X</field>

Ggf. Reboot. Alternativ kannst du natürlich wie schon geschildert die ganzen Trunk Parameter per Konfigurations API anpassen.

Weiteres: Evtl. ein Trunk der auch schon aus V18 gekommen ist? Wenn ja: Trunk schonmal frisch neu angelegt in V20?

 

[rootex]

<field name="RegistrarInvite">X</field>

Hatte ich vorher schon probiert und via neuem Template und Trunk auf 1 gestellt. Hat nichts gebracht.

Ebenso den Eintrag: <field name="IsSupportReinvite">1</field>

Auch keine Besserung! - Ein Kollege meinte der Provider müsste das senden. - Dieser behart aber darauf, lief immer, Ihr habt was geändert (Update der 3cx), nicht unser Problem.

Weiteres: Evtl. ein Trunk der auch schon aus V18 gekommen ist? Wenn ja: Trunk schonmal frisch neu angelegt in V20?

Die Anlage ist übrigens eine "frische" V20 - also nichts aus der V18.

 

[avraammich_3CX]

Hi @rootex,

Re-Invite und Replace muss auf 0, falls 1 kann der Provider den Anruf beeinflussen(was er auch tut)
Unabhängig davon würde ich empfehlen, einen von 3CX unterstützten Provider zu verwenden

 

[rootex]

Re-Invite und Replace muss auf 0, falls 1

War vorher auf 0 zum Test auf 1 dann wieder auf 0.

Providerwechsel bei dem Kunden ungünstig: Der Internetanschluss ist dort aufgrund der geographischen Lage "fest verankert".
Und der Trunk ist inkludiert. Würde daher doppelte Kosten entstehen! Lief ja jetzt 2 Jahre, da sind die Argumente auch schwierig, warum es jetzt auf einmal nicht geht.

 

[patrickb]

Ich hab noch ein zwei andere Ideen aber das muss man sich live ansehen und durchtesten.

 

[patrickb]

Ggf. Reboot. Alternativ kannst du natürlich wie schon geschildert die ganzen Trunk Parameter per Konfigurations API anpassen.

Kleiner Nachtrag zu den Trunk Parametern via API @rootex. Hatte den Beitrag die Nacht nicht gefunden:

F

Beitrag im Thema 'SIP Trunk CompanyFlex - VoiceData ausgehende Rufnummer'

1. März 2025

Es gibt zu o.g. Skript eine leider notwendige Änderung die mir heute erst aufgefallen ist.

Hier das aktuelle

3cx-sip-trunk-change-outbound-parameter-v2.ps1

$tcxurl = "mypbx.mydomain.de"       # needs port if not 443

$jsonauthbody = (@{
    Username="100"                  # 3CX user, maybe email address
    Password="Super_Secret0815"     # 3CX user password
    SecurityCode=""
} | ConvertTo-Json)

$LoginResponse = Invoke-RestMethod -Uri "https://$tcxurl/webclient/api/Login/GetAccessToken" -Body $jsonauthbody -Method POST -ContentType "application/json"

$headers = @{Authorization =...

• fxbastler

• 

 

[rootex]

Konnte das Problem jetzt ein wenig eingrenzen:
Seit dem Update sendet die 3cx ein OPTION. Das hat sie vorher nicht getan.

Angeblich wurde laut Build History V20

Resolved an issue where the PBX sent OPTIONS messages to refresh the session timer, causing calls to drop

Dieser Fehler behoben.
Kann ich der Anlage irgendwie sagen, dass sie das eben nicht tut?

 

[avraammich_3CX]

Hi @rootex,

Kann ich der Anlage irgendwie sagen, dass sie das eben nicht tut?

Nein, vom Pcap ist jedoch zu erkennen dass Provider mit einem 200 OK antwortet auf Message Options.
Was soviel bedeutet, dass dieser "OPTIONS" untersützt.
Schau dir den CSeq header an.
Weshlab nach dem 200 OK vom Provider, der Provider den Anruf beendet ist kein 3cx Problem.

 

[rootex]

Vorm Provider kommt diese Antwort:
Diese Nachricht enthält der header Session-Expires: 120;refresher=uas

Mit dieser Antwort signalisiert 3CXPhoneSystem, dass es RFC4028 unterstützt und Refresh-aktualisierungen akzeptiert. Es gelten die RFC4028.

Das Problem ist, dass ein UAS, wenn es der Verwendung von RFC 4028 zugestimmt hat, anschließend kein OPTIONS mehr senden darf.

Des Weiteren bezieht er sich darauf, dass es vor dem Update mit einem Invite refreshed wurde.

3CX-Support macht es sich ebenso einfach und sagt, Trunk nicht in supportet... Kann ich zum Teil nachvollziehen, aber leider schade.

 

[fxbastler]

Mal eine Frage dazu: Welcher SIP Trunk Provider ist das denn nun eigentlich?
Soweit ich es bisher kenne waren es nie die Stadtwerke selber. Das wird i.d.R. ausgelagert, alles spricht dafür. Wir hatten schon mehrfach mit so etwas zu tun. Dann muss man sich mal an eine Stelle höher wenden und das mit dem eigentlichen SIP Trunk Provider klären. Da gab es bei uns bisher immer Möglichkeiten. *auf_Holz_klopf*

 

[rootex]

Ganz vergessen zu antworten.
Der Provider ist Aarenet.
Leider kein offiziell gelisteter „3CX Preferred SIP Trunk Provider“
Habe zwar in RFC 4028 nicht wirklich gefunden, dass ein OPTIONS verboten ist. Aber um mich mit dem Provider oder 3CX zu streiten, fehlt mir dann doch das Fachwissen. So tief bin ich leider nich im Thema...