Gespräche abgehackt mit Unifi DreamMachine

[andante]

Hallo,

wir haben die 3CX seit rund einem Jahr im Einsatz. Als Sip Trunk hatten wir einen Lancom Router, es hat auch alles soweit funktioniert.

Seit kurzem ist der Lancom weg und wir verwenden stattdessen eine Unifi DreamMachine mit dahinterhängendem Vigor VDSL Modem.

Daher ist in der 3CX der Telekom SIP Trunk direkt eingetragen. Leider ist es so, dass seitdem die Gespräche abgehackt sind. Überwiegend versteht der Angerufe uns nicht, bei uns kommt das Gespräch auch nicht perfekt, aber besser an.

Die Codecs sind wie folgt eingetragen:

G.711 A-law
G722
G.711 U-law
G729

Als Transport-Protokoll ist TCP hinterlegt, wenn ich auf UDP ändere, ist der Sip-Trunk rot.

Der Firewall Test läuft durch.

Zudem wird nun im Display das Nummernformat seltsam angezeigt. Es wird statt wie früher die Nummer des anrufenden der Gruppenname angezeigt.

Woran könnte das liegen?

Danke und Gruß,
Dennis

 

[fxbastler]

Hallo,

Die Codecs sind wie folgt eingetragen:

Wo ist das so? Im SIP Trunk, in den 3CX Codec Einstellungen und den provisionierten Endgeräten gleichermaßen?

Was für eine 3CX Installation ist das - Windows oder Debian? Läuft die 3CX in einer VM oder physisch? Was für Endgeräte werden verwendet? Sind alle im Haus, idealerweise im LAN?

Zudem wird nun im Display das Nummernformat seltsam angezeigt. Es wird statt wie früher die Nummer des anrufenden der Gruppenname angezeigt.

Schick mal bitte ein Bild des 3CX Menü 'Erweitert' / 'Kontakte' / 'Optionen'. Wurde der Telekom SIP Trunk komplett neu mit der Vorlage eingerichtet?

Alles weitere vmtl. nur mit einem passenden Ausschnitt eines solchen Anrufes im 3CX Aktivitätenprotokoll in der Protokollierungsstufe mittel und weiterführend (insbes. bzgl. des Audio Problems) mit einem Wireshark Mitschnitt eines solchen Anrufes (Wink zum 3CX Support, z.B. @avraammich_3CX ). Apropos: ist das Audio in einem solchem Wireshark Mitschnitt auch beidseitig abgehackt?

 

[andante]

Hallo fxbastler,

Die Codec-Einstellungen sind so im SIP-Trunk eingetragen, bei den Telefonen und unter Codec-Einstellungen ist es anders, dort kann ich den G.711 erst gar nicht auswählen.

Die Anlage läuft auf einem Raspberry Pi 4, also Linux. Alle Endgeräte sind im Haus per Lan verbunden, überwiegend Yealink Telefone (T48S)

Anbei das Bild:




Im Anhang hab ich den wireshark dump angehängt. Das Gespräch war in diesem Fall nur für den externen Anrufenden 2 Aussetzer.

 

[fxbastler]

bei den Telefonen und unter Codec-Einstellungen ist es anders, dort kann ich den G.711 erst gar nicht auswählen.

Dort wird das PCMA genannt, ist dasselbe. Ist das dort eingestellt und ganz oben?

Also was ich so nach 1-2 min. kurz drüber schauen in dem Dump sehe (ich muss doch noch bissle arbeiten nebenher): es wird ein Gespräch geführt, man sieht alle beteiligten und teilweise die zwischengeschalteten Geräte und Nummern (oh oh Datenschutz ...), ausgehandeltes und verwendetes Protokoll ist G.711 a (korrekt so weit), es geht ein Päckchen des Anrufers verloren und geraume Zeit später wird eine künstliche Stille eingefügt. Die RTP Analyse zeigt - bis auf das eine läppische Päckchen - keine wesentlichen Gründe (Jitter, Zeit, weitere Verluste) für so eine lange Stille (ausser dass es TCP ist und ein Resend versucht wird was ich noch nicht gesehen habe). Ich schau mir das später noch mal genauer an.

Es gibt in der UDM bzgl. SIP noch einige Einstellungen die ich gerade spontan nicht auf Lager habe. Vielleicht könnten das noch einmal Einige die so etwas produktiv im Einsatz haben (ich nenne keine Namen) kurz hier rein schreiben was denn dort wirklich beachtet werden sollte - unabhängig davon dass der Firewall Check grün zeigt.

 

[bitn2]

Ich habe nur das "Contrack Modul" SIP abgeschaltet und sonst nichts weiter verändert. So läuft es bei mir Fehlerfrei.

 

[avraammich_3CX]

Hi,

fxbastler propos: ist das Audio in einem solchem Wireshark Mitschnitt auch beidseitig abgehackt?

Sofern beide Legs RTP streams vorhanden sind im Pcap ist es lokalisierbar.
Man müsste dann den RTP Stream src.port/dst,port prüfen.
Hier kann man erkennen ob RTP Pakete überhaut richtig ankommen ohne großen Verlust ( expected RTP Pakete/Lost RTP Pakete), normal Werte für Max jitter, Max Delta und Clock Drift.

 

[avraammich_3CX]

Hi,

eine bitte an alle.

KEINE Pcaps hier öffentlich hochladen.
In den Pcaps sind wichtige Informationen enthalten.. welcher ein dritter ausnutzen kann.

 

[avraammich_3CX]

Hi andante,

dein Problem ist an sich nicht vom Telefon zu der Anlage.
Das audio vom Telefon zu der Anlage kommt ohne Unterbrechung an und von der Anlage zu provider auch ok.
.Auffällig ist hier im reverse quasi vom Provider zur Anlage das Bandbreite nach X Sekunden ca. 1 Minute etwas runterfällt mit einem größeren Delta genau zu diesem Zeitpunkt ca 1 Minute wenn ich mir das Gespräch anhöre.



Mit

 

[fxbastler]

Oje, ich weiss nicht was ich gestern gelesen habe. Aber a) wird zwischen der 3CX und dem Endgerät im Haus G722 und nicht G.711 a verwendet (einzustellen unter Einstellungen / Codecs, dort oben und unten mal auf PCMA stellen, verringert tlw. die Latenz, benötigt keine Rechenleistung für's umkodieren da durchgereicht wird) und alle RTP Streams werden natürlich per UDP transportiert. Es bleibt dabei: ein Päckchen im Audio Stream des Anrufers vom Provider zur 3CX fehlt, sind 214 Bytes gesamt, Nutzlast 160 Bytes, bei G.711 a sind das 20 ms Audio, das hört man nicht, das ist grundsätzlich nicht weiter schlimm, dafür ist es da dass es mal fehlen kann. Aber woher die später künstlich eingefügte Stille - so beschreibt es auch Wireshark - kommt ist mir noch unklar. Ich schau dann nochmal.

Stell mal bitte die Codecs in der 3CX um und reprovisioniere / starte die Telefone neu.

 

[andante]

Hallo,

habe den PCMA nun eingestellt, leider ohne Verbesserung.

und alle RTP Streams werden natürlich per UDP transportiert

D.h., ich müsste im SIP Trunk von TCP auf UDP ändern?

Ich habe nur das "Contrack Modul" SIP abgeschaltet und sonst nichts weiter verändert. So läuft es bei mir Fehlerfrei.

Das war schon drin:



VG,
Dennis

 

[fxbastler]

D.h., ich müsste im SIP Trunk von TCP auf UDP ändern?

Wenn damit die SIP Trunk Registrierung gemeint ist: grundsätzlich nein. Es ging in meiner Aussage bzgl. des pcap Dump nicht um SIP (die Verwaltungsdaten des VOIP Gespräches, unter Optionen / Transportprotokoll) sondern um die Audio Daten (RTP).

Es hängt nach wie vor an dem einen verlorenen Paket (20 ms) und der Frage: Woher kommt die zwangsweise eingefügte längere Pause?

Wenn das Problem oft auftritt (damit fast schon reproduzierbar) würde ich an dieser Stelle testweise einen anderen Router (ein einfaches Modell, z.B. openWRT oder Mikrotik hEX) testweise einsetzen und schauen, ob das dann auch passiert. So eine Internetverbindung ist fix eingerichtet. Die sonstigen Netzwerke, VPN usw. kann man ja kurz außen vor lassen. Ich habe im Moment die UDM in Verdacht. Aber das ist nur meine persönliche Meinung.

 

[bitn2]

Ich glaube nicht das die UDM da das Problem ist, betreibe das in verschiedenen Varianten mit Unifi Hardware und Vigor seit Jahren. Wie sind denn die Firmwarestände der UDM und des Controllers? Die Möglichkeit die 3CX wo anders zu installieren und auf die aktuelle Version zu bringen?

 

[andante]

Wenn das Problem oft auftritt (damit fast schon reproduzierbar) würde ich an dieser Stelle testweise einen anderen Router (ein einfaches Modell, z.B. openWRT oder Mikrotik hEX) testweise einsetzen und schauen, ob das dann auch passiert. So eine Internetverbindung ist fix eingerichtet. Die sonstigen Netzwerke, VPN usw. kann man ja kurz außen vor lassen. Ich habe im Moment die UDM in Verdacht. Aber das ist nur meine persönliche Meinung.

Muss mal schauen, ob ich noch etwas rumliegen habe, aber glaube eher nicht.

Das Problem tritt eigentlich bei jedem Gespräch auf.

Ich glaube nicht das die UDM da das Problem ist, betreibe das in verschiedenen Varianten mit Unifi Hardware und Vigor seit Jahren. Wie sind denn die Firmwarestände der UDM und des Controllers? Die Möglichkeit die 3CX wo anders zu installieren und auf die aktuelle Version zu bringen?

Die Versionen sind wie folgt:

Unifi OS: 1.12.22
Network: 7.1.66

Ich könnte sie auf einem Windows PC installieren, würde das aber nur im äußersten Notfall tun.

 

[bitn2]

ist eventuell die Internetleitung ausgelastet? Was für ein Anschluss ist das denn? Ansonsten mal mit Smart Queue versuchen.

 

[andante]

Hi,
die Leitung ist nicht ausgelastet, es ist eine 250er DSL Leitung (Upload 40). Habe es auch mal nachts versucht, wo es keinerlei anderen traffic gab.

 

[bitn2]

Die 3CX läuft ja auf ein Raspi 4, vermutlich auf einer SD Karte. Evtl ist die zu langsam oder defekt. Hast du die Chance die 3CX mal wo anders zu installieren? Ist die Anlage mit dem Raspi Image von 3CX installiert worden oder hast du die nachinstalliert auf ein Raspi Linux?

 

[andante]

Habe das Raspi Image genommen. Habe es auf einem schnellen USB Stick installiert, also keine SD Karte