Probleme mit Easybell Trunk (one Way Audio)/ Unklarheit bei den RTP-Ports

[Frerk Siemsglüß]

Moin,

wir hatte heute bei unserer eigenen PBX das Problem der Oneway Audio Übertragung. Wir nutzen einen easybell SIP Trunk und eine 3cx Enterrprise mit V16.0.9.
Wir haben typischerweise bei der Problemstellung natürlich sofort die Firewall in Verdacht gehabt, hier wurde aber keine Pakete gedroppt. Dennoch hieß im Trace der 3cx der Port wäre nicht erreichbar.
Wir haben in unserer Firewall nur die von 3cx geforderten Ports in Richtung PBX auf, nun heißt es von easybell es müssten die UDP Ports 20.000 - 50.000 für RTP in beide Richtungen auf.
Ich habe die Portrange dann mit ins Routing eingefügt, dies brachte aber keine Änderung. Zeitgleich habe einen zweiten Easybell SIP Trunk der PBX hinzugefügt, der keine Probleme hatte sogar nach dem ich die von Easybell geforderte Range wieder aus der Firewall entfernt habe. Ich habe daher den Trunk unseres eigentlichen Anschlusses neu eingerichtet und siehe da er funktionierte wieder.
Als Registrar wird nun neuerdings der "voip.easybell.de" eingetragen, anstatt des "sip.easybell.de", dies war allerdings beim auftreten des Problems bereits so eingerichtet und wurde nur auf sip.easybell.de geändert da wir mit dem "voip auf anderen Anlagen bereits ähnliche Probleme hatten. Ist jemanden etwas ähnliches passiert? Wir betreiben bei unseren Kunden mehrere Anlage in dieser Konstellation ich würde daher gerne ausschließen, dass es Probleme mit dem Provider Template gibt/gab. Der Registrar kann ja nicht die Einzige Veränderung sein.

Weiter hat dieser Vorfall wieder zur Verwirrung meinerseits bzgl. der RTP-Ports geführt?
Müssen nun die RTP-Ports vom Provider auch noch von extern Frei sein? Wenn die Range 9000:10999 und 20000:50000 wo und wann wird dann definiert, bzw ausgehandelt welche Ports genutzt werden. Wenn die Easybell die Daten z.B. über Port 25000 überträgt woher weiß die 3cx dass sie darauf antworten soll, wenn sie doch eigentlich die Ports 9000:10999 nutzt?

Vielen Dank!

 

[BenS]

Dein beschriebenes Problem hatte ich nicht. Das Provider Template ist vielleicht von der Realität überholt worden? Update im Template das erst bei Neuanlage eines Trunks zog?

Aber zu den RTP Ports will ich meine 2ct beisteuern:
Easybell will RTP auf 20-50.000 und so wird es im Template für den Easybell Trunk der 3CX stehen. Die 3CX will RTP auf 9000-10999 und so wird sie das der Easybell via SIP Protokoll sagen.
Also ja, beide Ranges müssen durchgängig sein aber 20-50.000 eben ausgehend und 9000-10999 eingehend, am besten mit Forewarding (warum, dazu komme ich gleich).
Was dein Problem des One Way Audio erklären könnte.

Ich habe das Video nicht angesehen aber das Thumbnail dürfte bereits alles erklären:

Und Forewading ist ja ungleich durchgängig. Die Forewardings sind im Grunde um auf Nummer sicher zu gehen:
Via SIP Port wird ja quasi ausgehandelt über welche RTP Ports dann gesprochen wird. Wenn jetzt ein Anbieter mehrere Mediaserver hat, und der Mediaserver von einer anderen IP ankommt als für die der grade Port offen ist wird das eben gedropt... Zu allem Überflüss kann das jeder Hersteller im SIP ALG und NAT verschieden implementieren. Wenn man prinzipiell die RTP Ports forwarded entsteht dieses Problem nicht. Alles was auf diese Ports kommt direkt weiter. In vielen Fällen wird es ohne Forewardings funktionieren. Aber um sich selber den Support leichter zu machen hat 3CX eben den Firewall check und die Forewardings. Sonst würden die mit den ganzen Sonerkonstellationen nie Land sehen. Und man selbst vernutlich auch immer wieder unerklärliche Sonderkonstellationen haben.

Ich glaube, ganz am Anfang der 3CX Schulungen sollte ein komplette Einheit nur das SIP Protokoll behandeln.
Das würde das alles viel verständlicher machen. Ich bitte auch um Korrektur sollte ich hier Blödsinn erzählen. Aber so hat es sich mir eben aus learning by doing erchlossen.