FreePbx - Anrufer hören mich nur abgehackt (ausgehendes Audio fehlerhaft)

[JohoLance]

Hallo,
ich nutze FreePbx auf Raspberry 3B+ hinter einem Lancom Router. Klappte bis vor kurzem reibungslos.

Neuerdings melden viele Mobilfunk-Anrufer, dass sie mich kaum verstehen, der Stream scheint ständig unterbrochen. Ich höre sie problemlos. Wenn ich selbst anrufe, ist die Qualität (immer) beidseits normal.
Das Problem betrifft auch die Wartemusik, scheint also nicht an der Endstelle zu liegen. Es tritt allerdings erst nach knapp 30 Sekunden auf, Ansagen ganz zu Beginn funktionieren gut.

Zwinggt man die Hauptleitung auf G.711, ist das Stottern weg, aber eigentlich ist das keine gute Dauerlösung...

Mein Voip Anbieter ist easybell, VDSL 50/10.

Kennt jemand eine Lösung oder gibt es Ideen, was ich ausprobieren kann?

Besten Dank

Cl.

 

[l1243]

Was für Telefone verwendest du? Und welchen Audio Codec haben diese konfiguriert?

 

[gehtdoch]

Zwinggt man die Hauptleitung auf G.711, ist das Stottern weg, aber eigentlich ist das keine gute Dauerlösung...

Welchen SIP-Treiber nutzt Du? chan_sip oder pjsip?

Zum Thema:
Damit hast Du doch schon den grundsätzlichen Lösungspfad: Du musst nach der Codec-Konfiguration schauen. Und zwar auf beiden Seiten (also sowohl nach intern als auch nach extern).

Erfahrungsgemäß gibt es Smartphones / Handies, die am Anfang des Gesprächs nochmal den Codec ändern - daher kann es passieren, dass es zunächst funktioniert und danach nicht mehr. Wobei 30s schon ziemlich spät ist.

Das Codec-Handling bei ausgehenden Calls ist auch meistens anders als bei eingehenden Calls - ist ein grundsätzliches Problem, wie Asterisk das Codec-Handling durchführt - was v.a. bei ausgehenden Calls oft zu völlig unnötigem Transcoding führt.

Globale Regel in Sachen Codecs:
Nur G711 und G722 erlauben (Reihenfolge ist relevant - je nach dem, worauf Du Wert legst, muss der eine oder andere Codec vorne sein!). Mehr brauchst Du normalerweise sowieso nicht. Musst Du sowohl beim Trunk ("Hauptleitungen") als auch beim Endpoint ("Nebenstellen") in den SIP-Einstellungen unter Codecs hinterlegen.

Ansonsten: Mache einen Trace vom SIP-Verkehr, damit man das Codec-Handling sehen kann. Alles andere ist Kaffeesatzleserei.

 

[JohoLance]

Hallo, nett, dass ihr noch antwortet.

Dia Anlage läuft komplett auf pjsip.
Mit g.711 VOR g.722 funktioniert es, ist aber halt eigentlich schade um den "guten Ton", denn damit sind auch alle Festnetzgespräche auf 711 gebucht.
Steht g.722 zuerst, scheinen die betroffenen Handys zwar diesen erst einmal aunzunehmen, kommen dann aber doch nicht damit klar. Richtig gedacht?

Bloß eigenartig: wenn ich dasselbe Handy selbst anrufe, dann klappt die Verbindung eigentlich immer, und meistens mit HD. Aber wenn das "ein grundsätzliches Problem" von Asterisk ist, dann lasse ich es wohl so.

Schöne Grüße
Cl.

 

[koyaanisqatsi]

Moinsen


Vielleicht kommen die Handfunken (Mobiles) an ihre Grenzen?
In dieser pandemischen Zeit ist es mir in/bei Telefonkonferenzen mit Mobiltelefonen mehrfach aufgefallen, dass die so spätestens nach einer halben Stunde anfangen zu "stottern" ( CPU Last? ).
...wenns wichtig ist/war, musste Konferenz beendet werden und wieder aufgebaut.

Lösung, gerade mit mehreren Teilnehmern, Fehlanzeige.
( Also alle Teilnehmer auf G.711 zwingen ist (normal) unmöglich )

 

[sonyKatze]

JohoLance, wir (jedenfalls ich und gehtdoch) bräuchten einen Paket-Mitschnitt, also die SDP- und RTP-Pakete, was genau passiert. Noch idealer wäre, Du würdest im Lancom einen der Ethernet-Ports auf Mirroring stellen. Dann sehen wir, was an deren Firewall ankommt. Kann nämlich auch sein, dass die sich mit Easybell bekriegt. Kann alles Unmögliche sein.

 

[gehtdoch]

Aber wenn das "ein grundsätzliches Problem" von Asterisk ist, dann lasse ich es wohl so.

Ich glaube, dass ich mich etwas missverständlich ausgedrückt habe: es ist ein grundsätzliches Problem, dass Asterisk unter bestimmten Umständen sinnlos transkodiert - das führt aber nicht dazu, dass es zu akustischen Problemen kommt - es ist einfach nur sinnlos. Und ich möchte damit sagen, dass Ein- und ausgehende Gespräche (auch bei gleichen TN) unter bestimmten Umständen unterschiedlich behandelt werden und nicht gleich - das ist die Botschaft und das erklärt, warum es bei Dir in eine Richtung geht und nicht in die andere - was üblicherweise aber nicht so ist!

Da Du mit pjsip unterwegs bist, kannst Du in Asterisk selbst wie folgt tracen:
als root in der Shell eingeben:

asterisk -x "pjsip set logger on"
asterisk -x "pjsip set logger verbose off"
asterisk -x "pjsip set logger pcap trace.pcap"

In /var/lib/asterisk/ findest Du dann die Datei trace.pcap (zumindest bei mir). Du musst u.U. ziemlich lange warten, bis der Callflow in der Datei enthalten ist. Am besten für "Bewegung" sorgen (sprich noch einen weiteren Callversuch machen).

Die kannst Du dann mit sngrep oder auch wireshark auswerten. Wichtig ist, was in Sachen Codecaushandlung / SDP zu erkennen ist - sowohl Richtung lokalem Device als auch zum Provider hin. Einmal die Fehlersituation und einmal die OK-Situation vergleichen. Im Internet findet man Hinweise, wie man Callflows mit sngrep oder Wireshark auswertet - ich habe hierzu hier auch schon das eine oder andere geschrieben.

Ziel ist herauszufinden, was konkret in der einen Richtung, wo es nicht geht, passiert und welche Codecs hier zum Einsatz kommen bei den beteiligten Devices.

Auf die Schnelle könntest Du es auch so herausbekommen (ohne Trace - aber brauchen werden wir den u.U. trotzdem - um die Details zu sehen):

# asterisk -x "pjsip show channelstats"

                                             ...........Receive......... .........Transmit..........
 BridgeId ChannelId ........ UpTime.. Codec.   Count    Lost Pct  Jitter   Count    Lost Pct  Jitter RTT....
 ===========================================================================================================

 db17aad9 100-0000003f       00:00:10 g722      478       0    0   0.000    482       0    0   0.000   0.000
 db17aad9 telekomPJSIP       00:00:10 alaw      484       0    0   0.000    478       0    0   0.001   0.000

Da siehst Du dann übrigens auch gleich, ob evtl. Pakete verloren gehen.

Zu sehen sind hier die beiden zusammengehörenden Calllegs: der erste Eintrag ist das lokale Device (vom lokalen Telefon zu Asterisk) - der zweite der zugehörige ausgehende Call - hier von Asterisk zur Telekom.

Es ist auch zu erkennen, dass nach innen G722 verwendet wird und nach Außen G711 (alaw). Hier wird sinnloserweise zwischen G711 und G722 transcodiert - obwohl nach innen G711 genauso erlaubt wäre. Dies ist übrigens ein ausgehendes Gespräch. Wäre das ein eingehendes Gespräch, wäre auf beiden Seiten G711 zu finden (das ist das grundsätzliche besagte Problem von Asterisk, dass die Codecaushandlung richtungsabhängig ist, wodurch es dann zu der Situation kommt, falls die Codecwünsche auf den beiden Seiten differieren).

Ergänzung:
Eine weitere recht elegante Methode, an die einzelnen SIP-Messages zu kommen, ist das pjsip history - Feature. Setzt allerdings noch viel mehr voraus, dass man das angezeigte Ergebnis versteht - es gibt da keine Auswertehilfen / Interpretationstools dafür. Für die, die SIP verstehen, ist das ein durchaus mächtiges Tool, weil es für erste belastbare Ergebnisse den geringsten Aufwand erzeugt.

Im Prinzip sollte man den weiter oben erwähnten Logger grundsätzlich mitlaufen lassen, um jederzeit eine Retrospektive zu haben, um "Auffälligkeiten" nachträglich analysieren zu können und auf Basis dessen bei Bedarf weitere, tiefere Traces (inkl. rtp z.B.) zu aktivieren.

Ein anderes mächtiges Tool ist auch pcapsipdump (zum Erfassen der relevanten Pakete). Nachteil hier ist allerdings, dass es nur für unverschlüsselte SIP-UDP-Pakete brauchbar ist.