Codec Reihenfolge für Telekom Company Flex

[atasolutions]

Hallo alle,

ich habe unsere Anlage neu installiert und versuche, sie so weit wie möglich zu perfektionieren. Wir planen, das 3CX-System weiter zu verkaufen und bei Kunden zu integrieren. Daher experimentiere ich zunächst und optimiere unsere eigene Anlage, damit der Kunde direkt das perfekte Produkt erhält.

Unser 3CX-System befindet sich in der Cloud hinter einer Firewall und hat derzeit nur die notwendigen Ports geöffnet. Unser Unternehmensnetzwerk ist ebenfalls hinter einer Firewall, und derzeit gibt es eine Regel mit "ANY" offenen Ports zwischen unserem Netzwerk und dem 3CX-System in der Cloud.

Interne Anrufe funktionieren nur manchmal und nur eine Seite hört die andere Seite. Externe Anrufe manchmal auch und nur zu Festnetznummern. Bei Handy-Nummern gibt es manchmal Probleme. Gelegentlich hört uns die Gegenseite gar nicht, und manchmal gibt es extrem starkes Rauschen, sodass man nichts anderes hört oder das Ton Qualität ist einfach sehr schlecht.

Ich weiß, dass unsere Probleme derzeit an vielen Dingen liegen können, aber ich vermute, dass die Reihenfolge der Codecs ein Faktor ist. Ich poste hier unsere aktuelle Codec-Reihenfolge, und gebt mir einfach eure Meinung dazu, ob das stimmt oder nicht. Vielleicht dient dieser Beitrag auch als Hilfe für andere, die ähnliche Informationen suchen. Ich habe viele Informationen zu Codecs gefunden, aber leider nichts Konkretes, Sinnvolles und Aktuelles.

Wir nutzen Telekom Company Flex.

Hier sind die SIP-Trunk Codec-Prioritäten:

1. G722
2. PCMA
3. PCMU
4. G729
5. GSM

Codec-Reihenfolge für LAN-verbundene Geräte oder Apps über WLAN:

1. G722
2. PCMA
3. PCMU
4. G729
5. GSM

Codec-Reihenfolge für WAN-verbundene Geräte oder Apps, die mit LTE/5G verbunden sind:

1. G722
2. PCMA
3. PCMU
4. G729
5. GSM

Codec-Reihenfolge für Yealink T54W Tischtelefone:

1. PCMU
2. PCMA
3. G722
4. G729

Wenn ich die Codec-Reihenfolge an irgendeiner Stelle ändere, muss ich dann alles neu bereitstellen (3CX Desktop) und neu provisionieren (Tischtelefone und DECT), damit es die neue Reihenfolge übernimmt?

Ich wäre auch für zusätzliche Tipps dankbar, was man noch verbessern kann.

 

[mbehrens]

Unser 3CX-System befindet sich in der Cloud hinter einer Firewall und hat derzeit nur die notwendigen Ports geöffnet. Unser Unternehmensnetzwerk ist ebenfalls hinter einer Firewall, und derzeit gibt es eine Regel mit "ANY" offenen Ports zwischen unserem Netzwerk und dem 3CX-System in der Cloud.

Ob dies ausreichend ist, zeigen die Logdateien der beteiligten Systeme.

Interne Anrufe funktionieren nur manchmal und nur eine Seite hört die andere Seite. Externe Anrufe manchmal auch und nur zu Festnetznummern. Bei Handy-Nummern gibt es manchmal Probleme. Gelegentlich hört uns die Gegenseite gar nicht, und manchmal gibt es extrem starkes Rauschen, sodass man nichts anderes hört oder das Ton Qualität ist einfach sehr schlecht.

Das hört sich nach einem Firewall- bzw. Transkodierungs-Problem an. Eine Analyse des Datenverkehrs sollte hier Hinweise geben.

Ich weiß, dass unsere Probleme derzeit an vielen Dingen liegen können, aber ich vermute, dass die Reihenfolge der Codecs ein Faktor ist. Ich poste hier unsere aktuelle Codec-Reihenfolge, und gebt mir einfach eure Meinung dazu, ob das stimmt oder nicht. Vielleicht dient dieser Beitrag auch als Hilfe für andere, die ähnliche Informationen suchen. Ich habe viele Informationen zu Codecs gefunden, aber leider nichts Konkretes, Sinnvolles und Aktuelles.

Die Möglichkeiten ergeben sich aus der Dokumentation aller beteiligten Provider.
Die Vorgabe von G.722 halte ich durch die dadurch notwendige Transkodierung für "suboptimal".

Wenn ich die Codec-Reihenfolge an irgendeiner Stelle ändere, muss ich dann alles neu bereitstellen (3CX Desktop) und neu provisionieren (Tischtelefone und DECT), damit es die neue Reihenfolge übernimmt?

Ja, wie sollen die Endgeräte sonst die neue Konfiguration bekommen?

 

[fxbastler]

Unser 3CX-System befindet sich in der Cloud hinter einer Firewall und hat derzeit nur die notwendigen Ports geöffnet.

Was für eine Firewall ist das? Das Umschreiben der Ports (source port NAT) bewirkt z.B. das beschriebene Verhalten. Bei einer pfSense (und OPNsense) wäre das z.B. eine Outbound NAT Regel mit gesetzter Option Static Port. Andere Geräte, andere Notwendigkeiten. Es gibt genug Anleitungen dazu von 3CX und hier im Forum.
Aber liste doch auch einmal die Portfreigaben und Weiterleitungen auf, die denn da gesetzt wurden.

Ich habe viele Informationen zu Codecs gefunden, aber leider nichts Konkretes, Sinnvolles und Aktuelles.

Alles auf PCMA stellen. Wenn dann irgendwann alles langfristig stabil läuft, dann kann man evtl. mit anderen Codecs spielen oder auch sein lassen (so wie wir es tun).

 

[atasolutions]

Was für eine Firewall ist das? Das Umschreiben der Ports (source port NAT) bewirkt z.B. das beschriebene Verhalten. Bei einer pfSense (und OPNsense) wäre das z.B. eine Outbound NAT Regel mit gesetzter Option Static Port. Andere Geräte, andere Notwendigkeiten. Es gibt genug Anleitungen dazu von 3CX und hier im Forum.
Aber liste doch auch einmal die Portfreigaben und Weiterleitungen auf, die denn da gesetzt wurden.

Es handelt sich um eine Securepoint Firewall.

Regeln in der Cloud:

• Internet - 3CX Server - HTTPS - Destnat
• Internet - 3CX Server - 5060 UDP - Destnat
• Internet - 3CX Server - 5061 UDP - Destnat
• Internet - 3CX Server - 5060 TCP - Destnat
• Internet - 3CX Server - 9000-9010 UDP - Destnat
• Internet - 3CX Server - 5090 UDP - Destnat
• Internet - 3CX Server - 5090 TCP - Destnat
• 3CX Server - Internet - beliebig - Hidenat

Interne Regeln:

• Internes Netzwerk - 3CX Server in der Cloud - beliebig - Hidenat

Alles auf PCMA stellen. Wenn dann irgendwann alles langfristig stabil läuft, dann kann man evtl. mit anderen Codecs spielen oder auch sein lassen (so wie wir es tun).

Ich habe die Codecs jetzt wie folgt umgestellt:

• PCMA
• PCMU
• G722
• G729

Trotz der Änderungen haben wir immer noch die gleichen Probleme, die sporadisch auftreten und schwer zu erklären sind. Zum Beispiel gibt es Verbindungsunterbrechungen bei internen Anrufen zwischen zwei Desktop-Clients oder es wird kein Signal angezeigt. Allerdings gibt es keine Probleme bei Anrufen vom Webclient zum Desktopclient oder vom Desktopclient zum Smartphone. Es scheint, dass die meisten Probleme durch die Desktop-Clients verursacht werden. Unsere Poly-Headsets funktionieren ebenfalls nicht mit den Desktop-Clients.

Ich wäre sehr dankbar für jegliche Hilfe, da mich die Probleme mit 3CX stark beschäftigen und ich verstehen möchte, was die Ursache ist.

 

[fxbastler]

Internet - 3CX Server - 5061 UDP - Destnat

Wenn der SIP Port der 3CX der Port 5060 ist (Standard), dann ist diese Regel unnütz. Richtig wäre eine gleiche Regel mit dem Protokoll TCP für z.B. SIPS.

Internet - 3CX Server - 9000-9010 UDP - Destnat

Das ist viel zu wenig. Wie im Admin Handbuch steht und in den Schulungen erklärt und gezeigt wird: es werden standardmäßig für die RTP Ports von 9000 bis 10999 per Protokoll UDP eingehende Weiterleitungen benötigt. Also den Bereich erweitern. Das wird vmtl. das Problem mit dem Audio sein, ein typisches Fehlerbild.

3CX Server - Internet - beliebig - Hidenat

Ich weiss nicht genau was Hidenat in diesem Fall bei dieser Firewall bedeutet. Es muss sichergestellt sein, dass ausgehende Anfragen der 3CX in andere Netzwerke (insbes. die 3CX HTTPS, SIP, SIPS, Tunnel und RTP Ports) nicht umgeschrieben werden. Ein Firewall Test zeigt das auf.

 

[fxbastler]

 

[atasolutions]

Wenn der SIP Port der 3CX der Port 5060 ist (Standard), dann ist diese Regel unnütz. Richtig wäre eine gleiche Regel mit dem Protokoll TCP für z.B. SIPS.

5060 ist für SIP und 5061 für SIPS. Ich hatte beide geöffnet, weil es in der 3CX-Dokumentation so angegeben war. Ich habe nun sowohl 5060 als auch 5061 für TCP und UDP geöffnet.

Das ist viel zu wenig. Wie im Admin Handbuch steht und in den Schulungen erklärt und gezeigt wird: es werden standardmäßig für die RTP Ports von 9000 bis 10999 per Protokoll UDP eingehende Weiterleitungen benötigt. Also den Bereich erweitern. Das wird vmtl. das Problem mit dem Audio sein, ein typisches Fehlerbild.

Ursprünglich habe ich nur wenige Ports geöffnet, da ich dachte, dass wir pro parallelem Gespräch nur 2 Ports benötigen. Daher war die Anzahl gering. Jetzt habe ich auch

Ich weiss nicht genau was Hidenat in diesem Fall bei dieser Firewall bedeutet. Es muss sichergestellt sein, dass ausgehende Anfragen der 3CX in andere Netzwerke (insbes. die 3CX HTTPS, SIP, SIPS, Tunnel und RTP Ports) nicht umgeschrieben werden. Ein Firewall Test zeigt das auf.

In unserem Fall stellt Hidenat sicher, dass die privaten IP-Adressen für das Internet bei ausgehenden Verbindungen übersetzt werden. Das hat bisher auch funktioniert. Die interne Telefonie zwischen zwei Desktop-Clients ist jedoch weiterhin problematisch. Ich habe nun auch neue Meldungen im Ereignisprotokoll festgestellt. Bilder wurden hinzugefügt.

 

[fxbastler]

Da wird schon wieder transcodiert, in G722. Sollte nicht alles erst einmal auf G711.a / PCMA stehen, damit es wenigstens diese mögliche Problemquelle nicht mehr gibt?