Company Pro 50 / Call and Surf

[suessmilch]

Guten Morgen,

ich habe bei einem Kunden ein Problem.
Der Anschluss ist ein Company Pro 50 von der Telekom, Carrier ist auch die Telekom.

Die Anlage funktioniert an sich ohne Probleme.
NUR ein Anschluss (Krankenhaus) macht Probleme.

Bis vor ca. 2-3 Monaten funktionierte alles problemlos, das Update auf Version 18.8 wurde erst einiges Später eingespielt.

Von einem auf den anderen Tag jedoch ist jedoch das Problem, dass mit diesem Anschluss ein Anrufen beim Krankenhaus nicht mehr möglich ist.
Entweder werden die Gespräche selbst binnen 20 Sekunden getrennt oder die Kommunikation ist nur Einseitig, Der B-Teilnehmer wird gehört, hört jedoch unseren Kunden nicht.
Bei den Kunden handelt es sich um eine Praxis, welche regelmäßig im Krankenhaus anruft.

Der Fehler ist reproduzierbar: Auf einer Anlage eines Anderen Kunden mit Call and Surf Anschluss tritt das gleiche Verhalten auf
Bei der Nomadischen Nutzung mit Phoner Lite jedoch tritt dieses Problem nicht auf (getestet von einem Kollegen Zuhause)

Der Firewall Check verläuft immer erfolgreich. Den Anschluss habe ich bereits mehrfach mit den Call and Surf Template (Entspricht den Zugangsdaten) neu eingerichtet.

Ist so ein Verhalten bekannt oder kann jemand helfen? Passende Informationen poste ich, wenn ich genau weiß, was benötigt wird.

Grundinstallation:

FritzBox mit Internet Einwahl, Switch ohne Management, PBX auf Linux Mini Server (keine VM, direkt), Version 18.8

 

[Road69]

Da wird vermutlich der SIP Stack von der Telefonanlage der anderen Seite irgendwas Komisches senden, was dann Deine 3cx nicht so mag.

Ohne genaue Analyse auf Wireshark-Ebene und in Verbindung mit dem 3CX Support (Ticket!) wird das vermutlich erst mal so nichts. Und dann wird noch die Frage sein, ob 3cx oder die andere Seite gewillt ist, was überhaupt daran zu ändern.

Bei Pascom CloudPB Anlagen gibt's zB seit Jahren Probleme div. Finanzämter anzurufen. Bei den Finanzämtern ist z.B. CISCO im Spiel - womit der SIP Stack der Pascom Systeme Probleme hat. Seit Jahren ein eher doch ungelöstes Problem.

 

[suessmilch]

ein Wireshark Cap habe ich.
Auch ein Support File.

Die Files könnte ich hier bereitstelle, muss ich da irgendwas drin kastrieren vorher / schwärzen?

Ich habe bereits den 3CX Support angeschrieben, leider jedoch ohne den erhofften Erfolg.
Die Telekom sagt, ist einen Problem beim B-Teilnehmer
Der B-Teilnehmer stellt keine Informationen zur Verfügung.

Mich wundert es halt das es von Januar (da wurde die 3CX geliefert) bis vor 3 Monaten lief.
Mein Easy Bell Test Trunk funktioniert einwandfrei auf der Anlage.

 

[fxbastler]

Hallo @suessmilch

Zur ursächlichen Frage: wir kennen so ein Problem nicht. Die einfachste schnelle Lösung für derartige ausgehende Anrufe ist, dem Kunden einen Easy Bell Trunk für Telefonate zu diesen problematischen Nummern einzurichten bis das Problem geklärt ist. Die generell bessere Lösung ist vmtl. die Nummern zu portieren, zu einem generell unproblematischeren Anbieter mit einer besseren Preis / Leistung. Eben nicht die Telekom, 1und1, Vodafone oder Kendidat V laut unserer Erfahrung.

Die Files könnte ich hier bereitstelle, muss ich da irgendwas drin kastrieren vorher / schwärzen?

Das Supportfile enthält einfach alles der 3CX, das geht gar nicht. Selbst der Wireshark Mitschnitt wird noch zu viele Informationen enthalten die nicht veröffentlicht werden sollten.


Der Vorteil ist: das Problem ist sehr gut reproduzierbar. Dazu einige Fragen:

1. Was für Endgeräte werden beim Kunden zum Telefonieren verwendet?
2. Stimmt die Zeiteinstellung der 3CX (hiermit ist die Installation und Nutzung von ntp gemeint)?
3. Wird überall bei der Telefonie des Kunden als alleiniger Codec der vom Telefonie Provider bevorzugte Codec verwendet?
4. Wurde der Router schon testweise getauscht (weg von der Fritte, hin zu einem DSL Modem und einem anderen Router mit mehr Funktionen, z.B. Mikrotik, openWRT, pfSense o.ä.)?

 

[suessmilch]

Vielen Dank für die Rückmeldung:
1.
Endgeräte:
1x Yealink T46U, Firmware Aktuell (derzeit Angepasstes Template, Disabled Ring im Headset)
1X Yealink W60B mit 4 Mobilteilen; Firmware Aktuell
1X Smartphone App
Der Fehler tritt überall auf.

2. Die Zeit stimmt, NTP wurde bei Installation angepasst und Montag Kontrolliert

3. Eingestellt sind G.711 A und G711 U. Ausgehandelt wird in allen erfassten Traces G.711A

4. Negativ, das Rekonstruierte Gegenbeispiel beim andern Kunden mit der Gleichen Technik wurde aber an einen LANCOM und einer Sophos Firewall mit PPPoE Einwahl erzeugt (Fall Back über Lancom, durch Kunden freundlicherweise ausgelöst, hierfür muss ich den Kunden noch eine Packung Süßigkeiten vorbeibringen)
Und mit Nomadischen Daten bei Phoner Lite auf einen Telekom-Anschluss im Privatbereich klappt die Verbindung.
Hier scheint wirklich die 3CX irgendwas nicht zu verstehen, entweder am Anschluss vom Kunden oder vom B-Teilnehmer-

Die Portierung zu Easy Bell hab ich auch schon überlegt. Zumal hier zusätzliches Sparpotenzial für den Kunden besteht.
Dann werde ich wohl eine Rufnummer noch bei Easy Bell beantragen (Fax haben wir bereits Anfang des Jahres über ein Grandstream HT802 an der 3CX vorbeigeleitet, mit Easy Bell)
Dann sicher ich zumindest erstmal wieder den Kontakt zum Krankenhaus und zieh später den Rest rüber.
mit Clip-No Screening bei Easy Bell kann ich ja auch die Easybell Nummer durch die Telekom Rufnummer überschreiben.
Easy Bell Nummer 99555123 ersetzen durch 4455 (Damit das Krankenhaus sieht, wer angerufen hat, mit der bekannten gespeicherten Rufnummer vom Kunden)

 

[Road69]

Mich wundert es halt das es von Januar (da wurde die 3CX geliefert) bis vor 3 Monaten lief.

Naja, die Problematik wird vermitlich durch ein Update oder neues TK-System oder eine dort veränderte Einstellung auf der Krankenhausseite ausgelöst worden sein.

Was hast Du für einen Einfluss? Keinen.
Und deshalb ging es mal bis irgendwann auf der anderen Seite was verändert wurde.

 

[avraammich_3CX]

Hi @suessmilch,

ich hatte im ticket schon erwähnt, dass du hierfür Provider kontaktieren musst.
In keinem Zeitpunkt nach einem 180 Ringing gefolgt von 183 session(von provider) bekommen wir ein 200 OK.
Anruf welcher unter die Luppe genommen wurde wird mit TCP Ausgehandelt.
In keinen Zeitpunkt des Anrufes(welcher von dir angemerkt) wird TLS für connection verwendet.
*(Da du der Meinung warst das TLS das Problem verursacht)

Weshalb kein 200 OK von provider nicht gesendet oder von 3cx nicht empfangen wird, und stattdessen ein 486 bekommst kann ich dir leider nicht mitteilen.
Ich würde beim provider starten...

23. 10. 2023 20:43:08:038 | 9 | Session 845299 has failed in leg L:2737.2[Line:10000>>+495XXXXXXXXX] ; Cause: 486 Busy here/INVITE from 217.0.146.197:5060


* dein Log Abschnitt mit TLS Aushandlung ist von einem anderen Zeitpunkt(hat mit den eigentlichen problem Anruf keinen Zusammenhang)
Dennoch fraglich weshalb Provider Invite TLS sendet, da hier ein Call and surf Telekom trunk benutzt.

22:09:57,844: T: 217.0.147.133:5061 (TLS)

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TLS 192.168.0.102:51178;branch=z9wqrwqrq46sdsgw34634634sdg82;rport

 

[suessmilch]

@avraammich_3CX

ich wollte mir hier noch eine zusätzliche Referenz einholen. TLS schließe ich nach einem erfolglosen Test auch aus (hab TLS eingestellt und das passende Zertifikat der Telekom verwendet), gleiches verhalten.

Auf Rückmeldung der Telekom, wieso TLS bei Phoner Lite verwendet wird warte ich noch.