[Problem] VoIP über externen SIP-Anbieter: Gesprächspartner hört Knacken/Rauschen - SIM-Rufnummer störungsfrei

[daltiparmak]

Hallo,
ich habe ein reproduzierbares Audioproblem bei VoIP-Gesprächen über externe SIP-Anbieter. Der Gesprächspartner hört Knacken und Rauschen, während auf meiner Seite alles
einwandfrei klingt.

Aktuelles Setup:
- Fritz!Box 6850 5G, FRITZ!OS 8.20
- Internet über Telekom 5G-SIM
- VoIP-Anbieter: DustNet (dus.net), 2 Rufnummern (externer SIP-Anbieter)
- DECT-Telefone: FRITZ!Fon + Gigaset (beide betroffen)

Problembeschreibung:
Bei ein- und ausgehenden VoIP-Anrufen über externe SIP-Anbieter hört der Gesprächspartner (typischerweise Mobiltelefon) Knacken und Rauschen. Auf meiner Seite
(DECT-Telefon) ist die Sprachqualität einwandfrei. Die Fritz!Box-Sprachübertragung zeigt: G.711 Codec, 2–5ms Jitter, 0% Paketverlust.

Drei Vergleichstests, die das Problem eingrenzen:

1. SIM-Rufnummer über gleiche DECT-Telefone → kein Knacken
Die Fritz!Box 6850 5G hat eine SIM-Mobilfunkrufnummer, die auf die gleichen DECT-Telefone geroutet ist. Über diese Nummer (EVS-WB Codec) ist die Qualität einwandfrei.
Gleiche Telefone, gleiche DECT-Funkstrecke.
2. Früherer VOIP Anbieter (integriertes VoIP) → kein Knacken
Als ich Kunde bei den Stadtwerken war, funktionierte deren integriertes VoIP (Telefonie als Teil des Internetanschlusses) über die gleiche Fritz!Box problemlos.
3. Externe SIP-Anbieter Easybell und DustNet → Knacken
Nach dem Wechsel zu einem externen SIP-Anbieter (erst Easybell, dann DustNet) trat das Knacken auf – bei beiden Anbietern identisch.

Was ich bereits ausgeschlossen habe:
- DECT-Funkstrecke – SIM-Anrufe über identische DECT-Strecke störungsfrei
- DECT-Telefone – getestet mit FRITZ!Fon und Gigaset, beide betroffen
- VoIP-Anbieter – Problem tritt bei Easybell und DustNet identisch auf
- Fritz!Box-Modell – Problem bestand mit Fritz!Box 7590 und besteht mit 6850 5G
- Internetanschluss – Problem bestand mit Festnetz und besteht mit 5G
- IPv4/IPv6/TLS/SRTP – alle Varianten durchgetestet, kein Unterschied
- QoS/Priorisierung – VoIP als Echtzeitanwendung konfiguriert

Muster:
Das Problem tritt ausschließlich bei externen SIP-Anbietern auf (Easybell, DustNet), nicht bei integriertem Provider-VoIP (Stadtwerke Lindau) und nicht bei der
SIM-Rufnummer. Es scheint, als ob die Fritz!Box bei externem SIP den Audio-Stream anders verarbeitet oder versendet als bei integrierter Telefonie.

Meine Fragen:
1. Gibt es einen bekannten Unterschied in der Audio-Verarbeitung zwischen integriertem Provider-VoIP und externen SIP-Anbietern?
2. Gibt es Einstellungen, die die RTP-Paketierung oder Audio-Kodierung bei externem SIP verbessern?
3. Wäre eine Beta-Firmware oder ein Diagnose-Trace (SIP/RTP-Mitschnitt) möglich, um das Problem zu analysieren?
4. Kennt das jemand?

 

[tango501]

Wäre eine Beta-Firmware ... möglich, um das Problem zu analysieren?

Für die FRITZ!Box 6850 5G gibt es die Laborversion 8.24-129412 vom 20.02.2026. Diese Version bitte einmal herunterladen, das Zip-File entpacken und die Realeasenotes dort durchlesen, ob eine entsprechende Anpassung oder Fehlerbehebung mit enthalten ist. Wenn keine korrespondierenden Fehlerbehebungen mit enthalten sind, würde ich die hier vorgenannte Fehlerbeschreibung dem Herstellersupport mitteilen. Sollten dort passende Fehlerbehebungen mit enthalten sein, dann würde ich der Laborversion eine Chance geben.

FRITZ! Labor – Frisch aus der Entwicklung

FRITZ! Labor ✓ Neue Funktionen frisch aus der Entwicklung ✓ Aktueller Entwicklungsstand von FRITZ!Box & Co. ✓ Exklusiv bei FRITZ! ✓ Jetzt entdecken!

fritz.com

 

[Deleted member 273463]

Gibt es einen bekannten Unterschied in der Audio-Verarbeitung zwischen integriertem Provider-VoIP und externen SIP-Anbietern?

Nicht, dass ich wüsste.

Gibt es Einstellungen, die die RTP-Paketierung oder Audio-Kodierung bei externem SIP verbessern?

Nein.

Wäre eine Beta-Firmware oder ein Diagnose-Trace (SIP/RTP-Mitschnitt) möglich, um das Problem zu analysieren?

Über den Trace (direkt auf der Fritz!Box) lässt sich zumindest feststellen, ob das Telefonat deine Fritz!Box störungsfrei verlässt

(typischerweise Mobiltelefon)

Wenn du eine Festnetznummer anrufst, ist also kein Knacken zu hören? Wenn du das Knacken mit deinem Mobiltelefon nachstellen kannst, versuche doch dort mal VoLTE/VoWIFI zu deaktivieren.

 

[daltiparmak]

Update: Trace-Ergebnis – RTP-Paketverlust ausgehend ~98%

Ich habe den empfohlenen Trace durchgeführt und ein eindeutiges Ergebnis:

Setup:
- Fritz!Box 6850 5G, FRITZ!OS 8.24 (Laborversion)
- Telekom 5G SIM (MagentaMobil XL), CGNAT (10.x.x.x) + öffentliche IPv6
- SIP-Anbieter: DustNet (dus.net)

Capture-Methode:
Gleichzeitiger Mitschnitt auf rmnet_mhi0 und "1. Internetverbindung", ausgewertet mit Wireshark.

Ergebnis:

Ausgehender Stream (Fritzbox → DustNet, meine Stimme):
- Erwartete Pakete: ~2000 (bei 20ms G.711)
- Tatsächlich auf WAN-Interface angekommen: 28
- Paketverlust: ~98,6%
- Delta zwischen Paketen: bis zu 6160ms (Soll: 20ms)
- 24 Sequenzlücken, größte: 307 fehlende Pakete am Stück

Eingehender Stream (DustNet → Fritzbox, Gegenseite):
- 1770 Pakete, 0% Verlust
- Max. Jitter: 3,3ms
- Vollständig unauffällig

Schlussfolgerung:
Die Fritz!Box erzeugt intern die RTP-Pakete, sendet aber 98,6% davon nicht auf die WAN-Schnittstelle. Das Problem liegt also nicht am SIP-Anbieter, nicht am Telekom-5G-Netz und nicht am Codec – sondern in der Fritz!Box selbst beim Senden von RTP über das Mobilfunk-Interface (rmnet_mhi0).

Das erklärt auch warum:
- Ich die Gegenseite einwandfrei höre
- Der Anrufer Knacken und Aussetzer hört
- Das Problem mit jedem SIP-Anbieter auftritt (vorher auch mit easybell getestet)
- VoLTE über dieselbe SIM problemlos funktioniert

Frage an die Runde: Ist dieses Verhalten (massiver RTP-Paketverlust ausgehend über rmnet_mhi0 bei externem SIP) ein bekannter Bug der 6850 5G? Gibt es eine Möglichkeit das AVM direkt zu melden inkl. Trace-Datei?

 

[tango501]

Schlussfolgerung: Die Fritz!Box erzeugt intern die RTP-Pakete, sendet aber 98,6% davon nicht auf die WAN-Schnittstelle.

Wir hatten hier kürzlich (allerdings bei ganz anderen FB Modellen und auch mit komplett anderem Fehlerbild) Probleme mit der Paketbeschleunigung. Den Fehler hat Fritz!/AVM mittlerweile auch adressiert und eine neue Version der Paketbeschleunigung in Fritz!OS eingebaut. Frage: Welche Version der Paketbeschleunigung kommt derzeit in der Laborversion 8.24-129412 zum Einsatz? Diese Info steht in den Supportdaten. Bitte einmal die Supportdaten erstellen, lokal abspeichern und mit einem Editor öffnen. Dort nach dem Eintrag "BEGIN SECTION PA showpainfo" suchen.
Welche Version der avm_pa wird dort verwendet? Gerne dazu die Zeile hier posten.

 

[daltiparmak]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Diese Info bekomme ich raus:

Version : 2.182.1.2-release_smart24p2-smart24p2

 

[tango501]

In den anderen Modellen kommt mittlerweile Version 2.182.1.3-release_smart24p2-smart24p2 zum Einsatz. Was man als Workaround testweise probieren kann, ist die Hardwarebeschleunigung zu deaktivieren. Die Deaktivierung hat zumindest bei den anderen Modellen mit der alten avm_PA das Problem gemildert. Die Deaktivierung wird allerdings nicht permanent gespeichert. Nach einem Neustart oder POR ist die PA wieder aktiv und müsste wieder manuell deaktiviert werden.

 

[KunterBunter]

Ausgehender Stream (Fritzbox → DustNet, meine Stimme):
- Erwartete Pakete: ~2000 (bei 20ms G.711)
- Tatsächlich auf WAN-Interface angekommen: 28
- Paketverlust: ~98,6%

Jetzt wird mir auch klar, warum du das immer als DustNet bezeichnest.

 

[daltiparmak]

Jetzt wird mir auch klar, warum du das immer als DustNet bezeichnest.

dus.net natürlich Der Vergleich passt aber!

 

[PeterPawn]

@Hardware-Beschleunigung:
Der Mitschnitt auf der FRITZ!Box wäre zu diesem Punkt aber auch nicht wirklich aussagekräftig … denn damit die Pakete, die über die Hardware-Beschleunigung direkt expediert werden (dazu dürfen Sie aber ihre Quelle gar nicht im Router selbst haben, was bei DECT-Telefonen ja schon mal der Fall wäre, wenn die nicht irgendwo "weiter hinten" im LAN erzeugt werden (auf einer weiteren Box), wovon in #1 nichts steht), überhaupt aufgezeichnet werden können, müssen Sie ja den Weg über die CPU nehmen - entweder im Original (womit sie eben NICHT mehr über die Hardware-Beschleunigung laufen) oder zumindest als Kopie, die an die CPU (zur Aufzeichnung) weitergereicht wird.

Eine Aufzeichnung würde also per se schon mal das Gesamtsystem so verändern, daß Rückschlüsse auf die Hardware-Beschleunigung als mögliche Ursache reine Spekulation wären - abgesehen davon, ist für den schon etwas älteren IPQ4019 m.W. bisher nicht bekannt, daß es auch dort Probleme mit der Implementierung des PA geben würde.

Nur weil man einen Hammer als Werkzeug hält, muß nicht alles ein Nagel sein. Und wer weiß schon, ob es nicht am Ende doch am Netzteil liegt … alternativ käme ja auch noch der Stromanbieter als Fehlerquelle in Frage und der wurde noch gar nicht "abgefragt". *SCNR*

@daltiparmak:
Wende Dich dazu einfach an den AVM-Support, den man über die Website der Firma FRITZ! erreichen kann.

Der Paketmitschnitt ist zwar ein Anhaltspunkt, aber im FRITZ!OS gibt es mehrere (virtuelle) Interfaces und die für die erste, zweite, usw. "Internet-Verbindung" sind i.d.R. nur solche virtuellen Interfaces, auf denen auch nicht zwangsläufig der gesamte Traffic sichtbar sein muß.

Außerdem schreibst Du zwar von verschiedenen Versuchen mit den Parametern für eine Rufnummer, aber nicht, ob Du die Einstellung "Anmeldung immer über eine Internetverbindung" (https://fritzhelp.avm.de/help/de/FRITZ-Box-6850-5G/avm/024p2/hilfe_fon_internet) aktiviert hast. Diese verändert tatsächlich das (interne) Routing der Telefoniedaten (i.d.R. zwar nur für SIP als Sitzungssteuerung, aber die Mobilfunk-Modelle sind m.W. in dieser Hinsicht gar nicht gut genug untersucht von der "Community') - aber sie SOLLTE für die Nummern der externen SIP-Anbieter aktiviert sein und wäre damit tatsächlich ein Unterschied im (internen) Routing.

Sichtbar ist das dann in der voip.cfg in einer Sicherung im sipiface-Parameter für diese Nummer. Das klingt zwar dem Namen nach eher nach "das ist nur für SIP", aber dieser Parameter existiert schon deutlich länger, als es Mobilfunk-Geräte bei AVM/FRITZ! gibt und es ist nicht unmöglich, daß den jemand bei der nachträglichen Implementierung für die 68xx-Geräte auch für RTP-Entscheidungen verwendet haben könnte.

Da für praktisch JEDES Paket, was auf der Box erzeugt wird (und das wird es, wenn der Payload von der DECT-Schnittstelle stammt), auch die Routing-Entscheidung erneut getroffen wird, ist es durchaus denkbar, daß bei "automatischer Auswahl des VoIP-Interfaces" (sipiface_automatic) nur ein Teil der RTP-Pakete auf dem passenden Interface landet (üblicherweise ist das allerdings wirklich die "1. Internetverbindung") und dann wird er der Rest weder (per Internet) gesendet, noch aufgezeichnet.

Dein Mitschnitt kann also als Anhaltspunkt dienen, aber die tatsächliche Konfiguration der (nein: aller!) Interfaces und die Konfiguration der (zusätzlichen) Rufnummern braucht es auch noch für eine halbwegs belastbare Interpretation der Ergebnisse. Das findet man alles in der Support-Datei … solltest Du die Infos dort mit uns teilen (wollen), brauchst Du nur die Rufnummern zu maskieren (und "teilen" meint gleichzeitig "teilweise" - sprich die relevanten Abschnitte und nicht einfach die gesamte Support-Datei) - der Rest (alles das, was mit "$$$$" beginnt) läßt sich ohnehin von Dritten nicht (ohne weiteres) entschlüsseln.

Ich würde jedenfalls bei den geschilderten Symptomen (VoIP klappt nicht, Mobilfunk bzw. früher Festnetz schon) auf eine Konfiguration mit virtuellem Interface für die Telefonie (das heißt dann üblicherweise auch gleich voip) und daraus folgendem falschen Routing für RTP-Pakete ausgehen.

 

[Karl.]

Ich würde das Problem anders angehen und schauen, ob ein Umschalten der SIP Rufnummer auf v4 oder v6, dabei ne öffentliche IPv4 Adresse oder der IPv6 only APN Abhilfe schaffen.

 

[tango501]

Fritz!Box 6850 5G, FRITZ!OS 8.24 (Laborversion)

Bitte einmal bei der FRITZ!Box 6850 5G die aktuelle Laborversion 8.24-130082 vom 06.03.2026 installieren.

FRITZ! Labor – Frisch aus der Entwicklung

FRITZ! Labor ✓ Neue Funktionen frisch aus der Entwicklung ✓ Aktueller Entwicklungsstand von FRITZ!Box & Co. ✓ Exklusiv bei FRITZ! ✓ Jetzt entdecken!

fritz.com

 

[PeterPawn]

Ich würde das Problem anders angehen und schauen

Du hast aber schon gelesen, daß die Symptome früher mit einer 7590 bei den Stadtwerken Lindau (sicherlich DSL, denn wenn's Fiber war, würde man vermutlich nicht auf 5G wechseln) identisch waren? Wo wären denn beim DSL diese Probleme dann zu suchen? IP-Protokolle (für SIP und RTP) hat er ja schon durch (steht so jedenfalls in #1) und die Adressvergabe bei anderen APNs kann es da ja eigentlich nicht gewesen sein?

Leute, was haltet ihr davon, zu den jeweiligen Vorschlägen bzw. Vermutungen wenigstens auch noch eine - zumindest in Ansätzen - plausible Theorie zu liefern, die die beschriebenen Symptome erklären KÖNNTE? Bei IPv4-/IPv6-Problemen in der SIP-Signalisierung käme erst gar keine Verbindung zustande und auch bei derartigen Problemen für die in den SDP-Daten angebotenen RTP-Streams käme GAR NICHTS bei der Gegenstelle an - und zwar auch kein "Knacken/Rauschen", weil eben gar keine Pakete übertragen würden. Wenn es hier nur ein Teil des gesamten Streams ist, kann das jedenfalls nur schwer an einem "version mismatch" beim IP-Protokoll liegen … wenn man's auch nicht völlig ausschließen kann oder sollte, aber nicht jedes Pferd ist gleich ein Zebra und man sollte es erst mal als Pferd ansehen, bevor es exotischer wird.

Auch Vorschläge für Firmware-Updates mögen ja immer wohlfeil erscheinen (und sind auch billig zu erteilen - wenn man ohnehin im Laborzweig unterwegs ist, allerdings auch leicht umzusetzen und werden vermutlich nicht schaden, wenn's derselbe Zweig ist) - nur erklärt eben auch das nicht wirklich, warum es bei der 7590 zuvor schon dieselben Probleme gab und die jetzt plötzlich mit einer Labor-Firmware für die 6850-5G beseitigt wurden (wobei da wohl für die SIM-Nummern mit der 8.2x neue Leistungsmerkmale unterstützt werden, aber das traf ja auf die alte 7590 auch noch nicht zu und dadurch bedingte Änderungen können also auch nicht die Ursache gewesen sein, daß es schon mit der 7590 zuvor nicht klappte).

Bei anderen dürften jedenfalls auch Rufnummern bei easybell oder dus.net zuvor schon funktioniert haben (vermutlich auch für Kunden der Stadtwerke Lindau, wobei das tatsächlich "die Besonderheit" sein könnte, auch wenn's unwahrscheinlich erscheint), sonst hätten wir mehr solcher Fälle, schon aus den zurückliegenden Zeiten der weiten Verbreitung der 7590.

Zwar ist auch meine Vermutung "etwas dünn", wenn es gar kein zusätzliches Telefonie-Interface bei den Stadtwerken gab (bei der Mobilfunk-Box müßte es eins geben, aber auch das ist nicht 100% sicher und bedarf der Recherche/Bestätigung) und damit auch bei sipiface_automatic alles über das "internet"-Interface geht - aber das ist ja leicht zu klären/erkennen und ehe man jetzt das gesamte Konstrukt durch irgendwelche (erratischen) Änderungen (oder Vorschläge für solche) komplett(!) verändert, sollte man zuerst versuchen, den Ist-Zustand so genau wie möglich festzuhalten (Support-Datei erzeugen und "weglegen").

Witzigerweise hat sich auch noch niemand dafür interessiert (obwohl sonst so vieles "abgefragt" wird), wie der Wechsel von der 7590 auf die 6850-5G genau erfolgte - hier könnte ja auch (z.B. wg. SmartHome-Zubehör) die Konfiguration von der 7590 (zumindest teilweise, auch für die SIP-Nummern) übernommen worden sein und das würde zumindest erklären können, warum die Gespräche über Rufnummern der "externen" SIP-Provider bei beiden Modellen gleichermaßen problematisch sind. Der Assistent wird sicherlich beim Wechsel von 7590 auf 6850-5G eher seltener genutzt bzw. wird vermutlich nicht wirklich ausgiebig getestet sein - zumindest nicht mit zusätzlichen Rufnummern, die nicht vom Anbieter des Anschlusses bzw. der SIM-Karte sind.

 

[daltiparmak]

Der AVM Support hat mich gebeten, die neueste Lab Version 8.24-129412 zu installieren. Mit dieser taucht das Problem nicht mehr auf!

 

[tango501]

neueste Lab Version 8.24-129412

Wann genau (Datum) kam denn diese Info vom Support? Mittlerweile gibt es für die FRITZ!Box 6850 5G die Laborversion 8.24-130082 vom 06.03.2026.

FRITZ! Labor – Frisch aus der Entwicklung

FRITZ! Labor ✓ Neue Funktionen frisch aus der Entwicklung ✓ Aktueller Entwicklungsstand von FRITZ!Box & Co. ✓ Exklusiv bei FRITZ! ✓ Jetzt entdecken!

fritz.com

 

[daltiparmak]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Entschuldige, genau diese Version ist es: 8.24-130082, mit der oben beschriebenen Version ging es noch nicht!

 

[daltiparmak]

Also zwischenzeitlich ging es 1-2 Tage, seit heute wieder die gleichen Probleme. Ich habe in der Fritzbox nichts verändert/konfiguriert in der Zeit.
AVM Support fordert gerade Support-Daten an, und Paektemitschnitte

 

[daltiparmak]

Heute stelle ich fest, wenn ich von aussen auf meine Nummer anrufe, dass kein Mobilgerät klingelt.
Beim zweiten Versuch, klingelt 1 von 3 angeschlossenen Geräten einmal, danach wieder nicht.

Ich dreh hier langsam durch...

 

[stsoft]

"DECT Eco" aktiv? -> Aus machen, macht genau solche Probleme.

 

[daltiparmak]

"DECT Eco" aktiv? -> Aus machen, macht genau solche Probleme.

Nein, ist nicht aktiv.

heute hat Fritz Support geschrieben:

Seitens Ihrer FRITZ!Box 6850 5G konnten wir keine Ursachen für die Auffälligkeiten in der Telefonie ausmachen. Da nicht alle SIP-Verbindungen betroffen waren, liegt der Schluss nahe, dass Besonderheiten Ihres Internetzugangs in Zusammenhang mit den betroffenen SIP-Anbietern eine Rolle spielen. Ich würde empfehlen, das Problem nochmals mit Ihrem Internetanbieter zu erörtern.

wird das zum Passierschein A38?

Grüsse