Optimierungsmöglichkeiten bei Echo, Rauschen, Hall

Teil-1

Hallo Zusammen,
da hier im Forum sehr rege über das Thema Echo diskutiert wird, habe ich mal meine Optimierung hier eingestellt, mit welchem
ich Echo und Hall einschränken konnte.

Testsystem-1 (Lokals LAN)
HW: Raspi P3
OS: Jessie Lite
SK: Renkforce Soundkarte
LS: JBL-Go Aktive Lautsprecher über 3,5 mm Klinke
MI: 2 x MCE101 vorgespannt mit 1,5 Volt über 3,5 mm Klinke
NW: Interne eth0 vom Raspi 3
CA: Digitus Optiguard über IP LAN 1280 x 720 und über V4L Loopback mittels ffmpeg
CO: Speex
Alsa Mixer LS auf 65 Micro auf 62
Dorpi 2.51

Sip Backend-1
SIP Asterisk 1.4 ohne tos und cos optimierung

Sip Backend-2
FritzBox 7490 OS 6.60

Netwerk: Cisco SG350XG-2F10 ohne tos und cos Optimierung

Ping zum Router durchschnittlich time=0.376 ms
Ping zum Asterisk durchschnittlich time=0.245 ms

Gegenstelle-1 Galaxy S5 mit AntiSip 5.21-82-4

Gegenstelle-2 Laptop mit Windows 7 Liblinphone win32 SDK version 3.10.2
Soundkarte Realtek und Logitech Funk Headset
Anbindung interne Netzwerkkarte 1Gb Uplink

Sprechtest langsames zählen von 1 bis 10

Testsystem-2 (WLAN)
HW: Raspi P3
OS: Jessie Lite
SK: Renkforce Soundkarte
LS: JBL-Go Aktive Lautsprecher über 3,5 mm Klinke
MI: 2 x MCE101 vorgespannt mit 1,5 Volt über 3,5 mm Klinke
NW: Edimax WLAN Stecker an wlan0
CA: Digitus Optiguard über IP LAN 1280 x 720 und über V4L Loopback mittels ffmpeg
CO: Speex
Dorpi 2.51

Sip Backend-1
SIP Asterisk 1.4 ohne tos und cos optimierung

Sip Backend-2
FritzBox 7490 OS 6.60

Netzwerk FritzBox 7490 and Cisco SG350XG-2F10 ohne tos und cos Optimierung

Ping zum Router durchschnittlich time=1.559 ms
Ping zum Asterisk durchschnittlich time=1.642 ms

Gegenstelle-1 Galaxy S5 mit AntiSip 5.21-82-4

Gegenstelle-2 Laptop mit Windows 7 Liblinphone win32 SDK version 3.10.2
Soundkarte Realtek und Logitech Funk Headset
Anbindung interne Netzwerkkarte 1Gb Uplink

Sprechtest langsames zählen von 1 bis 10

Bei beiden Testsystemen habe ich signifikate Echos, diese sind auch auf den Aufnahmen der DoorPi's zu hören

Teil-2

Optimierung-1 (Optimierung des Sip Servers)

Auf der Asterisk habe ich in der Sip.conf in Sektion [general] tos und cos eingestellt

tos_sip=cs3 ; Sets TOS for SIP packets.
tos_audio=ef ; Sets TOS for RTP audio packets.
tos_video=af41 ; Sets TOS for RTP video packets.
tos_text=af41 ; Sets TOS for RTP text packets.

cos_sip=3 ; Sets 802.1p priority for SIP packets.
cos_audio=5 ; Sets 802.1p priority for RTP audio packets.
cos_video=4 ; Sets 802.1p priority for RTP video packets.
cos_text=3

Ergebnis Testsystem-1 (Lokals LAN) noch mittelstarke Echos welche auf den Aufnamen der DoorPi's zu hören sind
Ergebnis Testsystem-2 (WLAN) immer noch Hall und starke Echos welche auf den Aufnamen der DoorPi's zu hören sind

Optimierung-2 (Optimierung des Switches)

Für Testsystem-1 (Lokals LAN) wird für den entsprechenden Port QosBasic aktiviert und auf höchste Priorität umgestellt
Für Fritzbox (Lokaler LAN Anschluss) wird für den entsprechenden Port QosBasic aktiviert und auf höchste Priorität umgestellt

Ergebnis Testsystem-1 (Lokals LAN) noch leichte Echos welche auf den Aufnamen der DoorPi's zu hören sind
Ergebnis Testsystem-2 (WLAN) immer noch mittelstarke Echos und Hall welche auf den Aufnamen der DoorPi's zu hören sind

Optimierung-3 (Optimierung an den DoorPi's )

Installation vom Debian Paket wondershaper auf Testsystem 1 und 2

Angaben sind in “Kilobits per second”, kbps

# apt-get install wondershaper

dann weiter auf Testsystem 1

# wondershaper eth0 2048 2048

# sudo doorpi_cli --trace

dann weiter auf Testsystem 2

# wondershaper wlan0 2048 2048

# sudo doorpi_cli --trace

Ergebnis Testsystem-1 (Lokals LAN) keine Echos mehr, trockener Sound

Ergebnis Testsystem-2 (WLAN) minimale Echos (leichter Hall) welche nicht mehr stören

Um verschiedene Shaping Einstellungen zu testen kann man mittels

# wondershaper clear eth0

seine akutelle Optimierung abstellen und eine neue Bandbreite vorgeben mittels

# wondershaper eth0 xxx xxx

Welche Werte für Euch wirksam sein könnten, müsst ihr einfach durch eigene Tests herausfinden.

Fazit:
Alle via Netzwerkkabel angebundenen Systeme weisen bei mir zumindest weniger Echo und Hall auf als jene Sprechstellen welche via WLAN angebunden sind.

Viel Erfolg

Aldafera aka Harald

Schönen Abend Thorsten,

jop Deine Anfrage ist richtig.

Solange Du keine Konfiguration in ein Startscript hinterlegst sind nach einem Reboot oder nach einem

# wondershaper clear wlan0

alle Einstellungen wieder weg.

Noch ein paar Hintergründe betreffend WLAN...

Weshalb ich mich auf das Netzwerk gestürzt habe und nicht auf mögliche Hardwareprobleme von Soundkarte, Micro und Lautsprecher ist historisch bedingt.

Mein Probblem hier sind die Entfernungen welche ich zu überbrücken habe. Am Anfang hatte ich hier nur einen Sammlung von alten Fritz Boxen mit welchen ich über WLAN Brücken die einzelnen Gebäude anfahren konnte.

Also habe ich für die Tierärzte alte Handys mit dem FritzBox! Phone bereitgestellt, in meinem Handy hatte ich noch eine Sim-Karte drin.

Wann immer ich angerufen wurde und ich nahm den Anruf über die Fritz Box mit FritzBox! Phone entgegen, glaubten die Leute ich stehe in der Mitte einer Turnhalle - Hall und Echos ohne Ende....... Grübel

Gleiches Handy ohne VoIP Client direkt angerufen über GSM... kein Echo, kein Hall, kein Knacken..... Grübel

Anruf über Festnetz aber Dect über FritzBox ... kein Echo, kein Hall, kein Knacken..... Grübel

Also konnte es einfach nicht die Hardware sein.....

Einmal ankommender Anruf über die Fritz mit WLAN und dann über Fritz mit Dect und dann über GSM..

Probleme gabe es nur wenn WLAN und lokales VoIP im Spiel war.

Eine andere Beobachtung konnte ich machen, als ich mit Messer und Gabel am Küchentisch die DoorPi's zusammengebaut und diese mit WLAN gekoppelt hatte.

Seit der FritzBox Firmware Version 5.x wird ja angezeigt wieviel WLAN Bandbreite jedes Gerät im Augenblick verwendet.....

Als meine Frau mit Android Phone, Apple IPhone und Apple Tablett bewaffnet vor der Haustüre stand (alle WLAN on), ging mit dem DoorPi über WLAN am Haus gar nix mehr...

Das ganze Netwerk war "irgendwie" in Unruhe, weil wohl jeder Teilnehmerknoten im WLAN eine Info bekam, ihr müsst die verfügbare Bandbreite jetzt neu aufteilen.

Es dauerte bis zu 15 Minuten, bis das Ruhe eingekehrt war und die "Hackordnung" im WLAN neu ausgehandelt war.

Unser neues Netzwerk hier kommt jetzt über Glasfaser und Backup mit Kupfer, die Komponenten von Cisco, also habe ich
Cisco mal verständigt, die haben mir den Hinweis gegeben, das die Cisco Firmware Möglichkeiten von TOS und Cos bietet, welche
ich für die jeweiligen Endknoten auf Portebene aktivieren kann.

Ein VIOP Call produziert sehr viele kleine UDP Packete, welche manchmal zum Problem führen können, deswegen sollten diese priorisiert
behandelt werden, das geht bei der FritzBox aber nur wenn die Pakete ins Internet geroutet werden.

Eine weitere Empfehlung kam dann aus der VoIP Abteilung von Cisco, die Endknoten wenn möglich in der Bandbreite zumindest mal versuchen fest zu steuern.

Also hab ich den Raspis einfach lokal gesagt, ihr habt für Up- und Downstream genau die Bandbreite, damit gibt es zwischen der
FritzBox und den Raspis eine klare Abmachung, keine Verhandlungen mehr über die Bandbreite.

Im weiteren wie ich heute erfahren habe, kann man die Optimierungen von LinPhone auf dem Raspi nicht einfach so verwenden, also auch hier der Ansatz über eine feste Bandbreite erstmal Ruhe zu bekommen.

Es gibt weitere Möglichkeiten TOS und COS für SIP auf dem Raspi zu steuern, ich bin da erstmal nicht tiefer rein, da mittlerweile alle
Raspis am Kabel hängen.

Hoffe es hilft dennoch weiter.

Schönen Abend noch Harald aka Aldafera