Asterisk Sip.conf für instabile WLAN- u. Mobilfunkverbindungen optimieren

23. Februar 2023

Wenn sich Softphones auf Smartphones bei schlechten WLAN- oder Mobilfunkverbindungen ständig an- und abmelden oder die Sprache abgehackt ist, können diese Störungen durch bestimmte Einstellungen in der sip.conf des Asterisk-Servers verringert oder beseitigt werden.

Voraussetzung ist natürlich, dass man über seinen eigenen Asterisk-Server telefoniert, den man selbst optimieren kann.

Die entscheidenden Einstellungen unter [general] in meiner sip.conf:

; Jitter-Buffer in sip.conf
; http://www.asteriskdocs.org/en/2nd_Edition/asterisk-book-html-chunk/asterisk-APP-A-SECT-2.html
jbenable=yes
jbforce=yes
jbimpl=adaptive
jbmaxsize=200
jbresyncthreshold=1000

; Weitere Einstellungen

canreinvite=no
qualify=yes
qualifyfreq=15         
session-timers=refuse 
nat=force_rport,comedia

Beispiel eines Accounts für ein Softphone in der sip.conf:

[12345]
type=friend
context=telefone
secret=meingemeinespasswort
host=dynamic
username=12345
canreinvite=no
qualify=yes
nat=force_rport,comedia
port=5064
dtmfmode=rfc2833
disallow=all
allow=alaw
allow=ulaw
allow=gsm
callerid = "Arthur Frankenstein" <12345>
qualifyfreq=3
session-timers=refuse ; steht schon unter general
keepalive=5
rtpkeepalive=5

; Dieses Softphone war mit einem schwachen Signal eines Mobilfunkmastes verbunden.
; Bei qualifyfreq=10 meldete sich die Verbindung alle paar Minuten für
; genau 10 Sekungen ab. Nachdem qualifyfrequ=3 gesetzt wurde, war die Verbindung stabil.
; Das Smartphone meldete sich so gut wie nicht mehr ab.

Einstellungen des Jitterbuffers: Ein Jitterbuffer ist eine Funktion, die verwendet wird, um das Problem des Jitters bei der Übertragung von Sprachdaten über das Netzwerk zu beheben. Es puffert ankommende Audio-Pakete und spielt sie mit einer konstanten Zeitverzögerung aus, um den Jitter auszugleichen und die Audioqualität zu verbessern.

jbenable=yes aktiviert den Jitterbuffer,

jbforce=yes erzwingt die Verwendung des Jitterbuffers, auch wenn der Endpunkt ihn nicht unterstützt.

jbimpl=adaptive wählt einen adaptiven Jitterbuffer-Algorithmus aus, der die Puffergröße dynamisch an die Netzwerkbedingungen anpasst.

jbmaxsize=200 legt die maximale Puffergröße auf 200 Millisekunden fest, was für die meisten Anwendungen ausreichend sein sollte. Der Jitterbuffer in Asterisk ist ein Puffer, der dazu dient, Schwankungen (Jitter) im Netzwerk auszugleichen, um eine gleichmäßige Übertragung von Sprache sicherzustellen. Durch die Festlegung einer maximalen Puffergröße wird die Verzögerung der Sprachübertragung begrenzt, um ein optimales Benutzererlebnis zu gewährleisten. Wenn die maximale Puffergröße beispielsweise auf 200 Millisekunden festgelegt ist, kann die Verzögerung der Sprachübertragung nicht mehr als 200 Millisekunden betragen, bevor der Jitterbuffer beginnt, Daten zu verwerfen.

jbresyncthreshold=1000 legt den Schwellenwert für die Neusynchronisation des Jitterbuffers auf 1000 Millisekunden fest.

Insgesamt sollten diese Einstellungen dazu beitragen, die Audioqualität bei der Übertragung über das Netzwerk zu verbessern.

Beispiel eines Softphones: Zu sehen ist das Softphone Sipnetic für Android-Smartphones. Die kostenlose Grundversion erlaubt den gleichzeitigen Betrieb mehrerer SIP-Accounts. Nachteilig von Sipnetic ist der erhöhte Akkuverbrauch. Deshalb verwende ich zusätzlich noch SessionTalk, während Sipnetic deaktiviert ist und für den Notfall aktiviert wird.

Welchen Audio-Codec verwenden? Im Allgemeinen ist G.711 (ob ulaw oder alaw spielt keine Rolle) bei schlechter Verbindungsqualität stabiler als GSM, da G.711 eine geringere Kompressionsrate und eine höhere Bitrate hat. Das bedeutet, dass es mehr Daten überträgt und somit eine bessere Audioqualität bietet, wenn die Bandbreite verfügbar ist. Da Audiobandbreite oft keine Rolle spielt, ist G.711 wahrscheinlich die bessere Wahl, wenn die Sprachverständlichkeit und Zuverlässigkeit oberste Priorität haben.

G.722 ist ein hochwertiger Audiocodec, der eine bessere Sprachqualität als G.711 und GSM bietet. Er ist in der Regel jedoch bandbreitenintensiver und erfordert daher eine stabilere Netzwerkverbindung. Bei schwierigen Übertragungsverhältnissen kann die Verwendung von G.722 möglicherweise zu mehr Verzögerungen oder Aussetzern führen. In diesem Fall kann es sinnvoller sein, auf einen Codec wie GSM oder sogar G.711 auszuweichen, der eine bessere Robustheit gegenüber Netzwerkproblemen bietet.

Bei schlechter Verbindungsqualität kann der Codec Opus besonders geeignet sein, da er in der Lage ist, eine gute Audioqualität bei niedrigen Datenraten zu liefern. Opus ist ein verlustbehafteter Codec, der in der Lage ist, Sprach- und Musiksignale in hoher Qualität bei Datenraten von nur 6 bis 20 kbit/s zu übertragen. Im Vergleich dazu benötigt der G.711-Codec eine Datenrate von 64 kbit/s, um Sprache in hoher Qualität zu übertragen. Ein weiterer Vorteil von Opus ist seine Fähigkeit zur variablen Bitrate-Anpassung, was bedeutet, dass er die Datenrate dynamisch an die verfügbare Bandbreite anpassen kann.

Weitere Einstellungen in der sip.conf: Die Kombination der Einträge

canreinvite=no
qualify=yes
qualifyfreq=15
session-timers=refuse
nat=force_rport,comedia

in der sip.conf trägt insgesamt zur Verbesserung der Verbindungsqualität bei:

canreinvite=no: Diese Einstellung sorgt dafür, dass die beiden Endgeräte (z.B. Telefone) während eines Anrufs direkt miteinander kommunizieren und nicht über den Asterisk-Server geleitet werden. Dadurch kann eine bessere Audioqualität erreicht werden, da der Asterisk-Server nicht als „Flaschenhals“ fungiert. Allerdings kann dies nicht in allen Netzwerkkonfigurationen funktionieren und kann manchmal zu Problemen führen.

qualify=yes und qualifyfreq=15: Durch das Senden von regelmäßigen „qualify“-Nachrichten wird die Verbindung zwischen dem Asterisk-Server und dem Endgerät aufrechterhalten und Probleme, wie beispielsweise eine Verbindung, die aufgrund von Inaktivität getrennt wird, können vermieden werden. Die qualifyfreq gibt an, wie oft diese Nachrichten gesendet werden sollen. In diesem Beispiel ist es auf 15 Sekunden eingestellt.

session-timers=refuse: Diese Einstellung stellt sicher, dass der Asterisk-Server nicht versucht, Session Timers mit anderen SIP-Endpunkten zu nutzen. Session Timers ermöglichen es, die Dauer eines Anrufs zu überwachen und den Anruf gegebenenfalls zu beenden, wenn er zu lange dauert. Wenn dies jedoch nicht ordnungsgemäß funktioniert, kann dies zu Problemen führen, insbesondere wenn der SIP-Endpunkt keine Session Timers unterstützt.

nat=force_rport,comedia: Diese Einstellung ist wichtig, wenn der Asterisk-Server hinter einem NAT-Gateway betrieben wird. Sie sorgt dafür, dass das NAT-Gateway richtig konfiguriert wird, um die RTP-Datenpakete zwischen den SIP-Endpunkten weiterzuleiten. force_rport gibt an, dass das NAT-Gateway den RTP-Port ermitteln soll, anstatt ihn vom SIP-Endpunkt zu erhalten. comedia bedeutet, dass das NAT-Gateway in der Lage sein sollte, RTP-Datenpakete aus beiden Richtungen weiterzuleiten.

Keepalive: Die Einträge keepalive und rtpkeepalive in der sip.conf konfigurieren das Verhalten des SIP-Endpunkts bezüglich der Überwachung der Netzwerkverbindung.

keepalive gibt an, wie oft ein „keepalive“ Nachricht an den Server gesendet wird, um die Verbindung aufrechtzuerhalten. Der Standardwert ist 0, was bedeutet, dass keine keepalive-Nachrichten gesendet werden. Wenn ein Wert größer als 0 konfiguriert ist, wird der SIP-Endpunkt eine Nachricht an den Server senden, um sicherzustellen, dass die Verbindung offen bleibt. In diesem Beispiel wird alle 60 Sekunden eine keepalive-Nachricht gesendet.

rtpkeepalive definiert, wie oft der SIP-Endpunkt „keepalive“ RTP-Pakete sendet, um sicherzustellen, dass die RTP-Verbindung ebenfalls offen bleibt. Wenn dieser Wert nicht konfiguriert ist, wird der Standardwert von 0 verwendet, was bedeutet, dass keine RTP-keepalive-Pakete gesendet werden. In diesem Beispiel wird alle 45 Sekunden ein RTP-keepalive-Paket gesendet.

Die Verwendung von keepalive-Nachrichten kann dazu beitragen, Verbindungsprobleme aufgrund von Inaktivität zu vermeiden und sicherzustellen, dass die Verbindung zwischen dem SIP-Endpunkt und dem Server aufrechterhalten wird.

Diese Einträge können sinnvoll sein, insbesondere wenn die Mobilfunkverbindung nicht stabil ist und es häufig zu Paketverlusten oder Unterbrechungen kommt. Durch das Einstellen von Keepalive-Parametern wird die Verbindung aufrechterhalten und die Wahrscheinlichkeit von Verbindungsabbrüchen verringert. Allerdings sollten die Werte nicht zu hoch eingestellt werden, da dies unnötig viel Bandbreite verbrauchen kann. Eine typische Einstellung für Keepalive-Intervalle bei Mobilfunkverbindungen wäre beispielsweise 30 bis 60 Sekunden.

Einträge in der rtp.conf: Die Einstellung rtpchecksums bestimmt, ob RTP-Pakete mit einem CRC-Checksumme versehen werden, um deren Integrität zu gewährleisten. Wenn diese Einstellung aktiviert ist, wird der Empfänger feststellen, ob das empfangene RTP-Paket korrekt ist, indem er die CRC-Prüfsumme berechnet und sie mit der im Paket enthaltenen Prüfsumme vergleicht. Wenn es keine Übereinstimmung gibt, wird das Paket als beschädigt angesehen und verworfen.

Die Einstellung strictrtp bestimmt, ob der Empfänger RTP-Pakete akzeptiert, die nicht den RFC-Richtlinien entsprechen. Wenn diese Einstellung aktiviert ist, werden Pakete, die nicht den Spezifikationen entsprechen, wie z.B. RTP-Pakete mit falscher Versionsnummer oder fehlenden oder ungültigen SSRC-Identifikatoren, abgelehnt.

In der Regel sollten Sie diese Einstellungen aktiviert lassen, um sicherzustellen, dass die RTP-Pakete korrekt und in Übereinstimmung mit den Standards übertragen werden. Wenn Sie jedoch bei Verbindungsproblemen Paketverluste feststellen, können Sie versuchen, die rtpchecksums-Einstellung zu deaktivieren, um die Übertragung von beschädigten Paketen zu vermeiden. Die strictrtp-Einstellung sollte normalerweise aktiviert bleiben, um sicherzustellen, dass nur gültige Pakete empfangen werden.

Wenn Sie rtpchecksums=no in der rtp.conf setzen, werden die RTP-Pakete ohne Prüfsummen akzeptiert, was dazu führen kann, dass beschädigte Pakete durchgelassen werden. Dies kann zu einer schlechteren Audioqualität führen oder sogar dazu führen, dass das Audio überhaupt nicht mehr übertragen wird.

Es ist normalerweise besser, rtpchecksums=yes zu verwenden, um sicherzustellen, dass die RTP-Pakete fehlerfrei sind und eine gute Audioqualität aufrechterhalten wird. Wenn Sie jedoch Probleme mit der Übertragungsqualität haben und vermuten, dass Pakete verloren gehen, können Sie rtpchecksums=no ausprobieren, um zu sehen, ob dies das Problem löst. Beachten Sie jedoch, dass dies die Audioqualität beeinträchtigen kann.

Auf einem Raspberry Pi lässt sich ein kompletter Telefonserver betreiben, der seinen Teilnehmern über Landesgrenzen hinweg kostenloses Telefonieren von unterwegs oder daheim ermöglicht.
Asterisk-Telefonserver auf einem Raspberry Pi – Installation, Konfiguration, Programmierung, SIP, IAX2, AGI-Skripte, Sicherheit und Tipps zum praktischen Betrieb – 2.11.2022: Diese Seite richtet sich an jene, welche einen Asterisk-Telefon-Server auf einem Raspberry Pi betreiben möchten und später ein kleines Netzwerk aus Asterisk-Servern planen, um ein eigenständiges Telefonnetz aufzubauen. Los geht es mit der Installation von Raspbian und Asterisk auf einem Raspberry Pi und dann nach Lust und Laune immer tiefer in die Programmierung von Asterisk. Die Themen werden laufend erweitert.

Selbstverständlich muss es nicht unbedingt ein Raspberry Pi sein. Andere Linux-Rechner gehen auch. – weiter