one-way-audio reproduzierbar, bei ca 80-90% der ausgehenden Telefonate (Telekom SIP Trunk) B-Teilnehmer hört uns nicht, aber wir hören ihn

3cx-Forum-User2323

Forum User
Mitglied seit
15. Juli 2019
Beiträge
108
Hallo,

bei der neuen lokalen 3cx Anlage sind ausgehend 90% der ausgehenden Calls one-way-audio. (Telekom SIP Trunk)
Wenn man ein Reventix SIP Trunk testhalber hinzufügt geht bi-direktional-audio.
Muss man unter Dashboard / SIP Trunk bei deutsche Telekom noch was ändern vielleicht? (haben natürlich die Vorlage verwendet)


Der Kunde hat eigentlich nichts aussergewöhliches:
1x Watchguard, aktuelle Firmware (Draytec als Modem, Telekom PPPOE steht in der Watchguard)
1x Unifi PoE Switch
1x 3cx Debian Version als esxi VM
1x Telekom SIP Trunk Tarif
1x VDSL Telekom (mit fester IP)

Der 3cx PCAP besagt: RTP wurde erfolgreich los geschickt
Telekom sagt, es sind keine RTP Daten angekommen ("Fehler Kundenendgerät A-Tln baut keinen RTP auf es kommt nach 5 sec ein re-Invite von der Plattform vergeblich. Kein Fehler im SIP-Dialog.")
Beim Watchguard PCAP wird noch nachgeguckt, was da los ist. Pcap Argumente waren:
-i eth5 udp port 5060 or udp portrange 9000-10999 / -i eth1 udp port 5060 or udp portrange 9000-10999

Angeblich hat die VDSL 150 Leitung keine Error-Seconds, wurde neu geschaltet. Aber es wurde z.B. noch nicht Vorort nochmal nachgmessen. Nur bei Schaltung vor 1-2 Wochen war Telekom Techniker 1x Vorort.

Falls da jemand eine Idee hat vielen Dank!
 
Als erstes würde ich in der Firewall gucken ob die RTP Pakete da evtl geblockt werden. Einfach mal das Live Log aufmachen und einen Anruf starten, dann sieht man schon ob da was hängen bleibt.
 
In der technischen Dokumentation der Telekom steht sie nutzen RTP von 9000-25000 was bei unseren Kunden ebenfalls Probleme machte wie von Dir beschrieben. Wir haben zusätlich die höhere Range an der vorgelagerten Firewall weitergeleitet seither ist dahingehend ruhe. Aktuell kommt es bei all unseren Telekom Kunden zu unerklärlichen Fehlermeldungen, die sporadisch auftauchen mit dem Trunk. Ich starte parallel einen Forumseintrag - eventuell ist dies für dich auch hilfreich.

Im Anhang einmal das Dokument - vielleicht hilft es weiter.

Gruß!
 

Anhänge

@bitn2

habe da kein deny gefunden
Das Pcap Watchguard Argument lautet übrigens so:
-i eth5 udp port 5060 or udp portrange 9000-10999
-i eth1 udp port 5060 or udp portrange 9000-10999

@MarcPIT

gute Idee aber daran hat es nicht gelegen, wenn ich das experimernt richtig gemacht habe

Die Lösung war Dank @microbinsi

ein Fehler in der Watchguard Policy:

SNAT Objekt Policy FROM/TOM Eintrag, d.h. "SET SOURCE IP "eigene feste ip" aktivieren war FALSCH

siehe auch:
 
Macht sinn, das würde der DNAT Regel sagen, sie solle nur auf diese eine IP lauschen anstatt auf alle die von WAN kommen. Freut mich, dass du das Problem lösen konnntest und danke für das Feedback :)
 

Statistik des Forums

Themen
44.413
Beiträge
232.713
Mitglieder
78.328
Neuestes Mitglied
as7h