Nein, das ist einfach Unsinn. Über IPv6 geht es genauso gut, und je nach Implementierung tut auch NAT überhaupt nicht weh. Hier wird mal wieder die Unfähigkeit einiger Spielprogrammierer auf die Provider abgewälzt.
Die meisten Spiele und Konsolen kommen problemlos auch mit DS-Lite oder CGNAT zurecht. Deshalb frage ich explizit danach, was nicht geht. Denn häufig genug jagen wir hier nach einem hübschen Eintrag im Konfigurationsmenu, den in der Praxis aber niemand braucht.
1&1 ist ja auch über die Glasfaseranschlüsse der DG verfügbar.
Aber nicht überall.
Was funktioniert denn nicht auf der PS5? Wofür brauchst du den anderen NAT Typ?
Und setze die 5690 unmittelbar vor dem Verbindungsversuch auf Werkseinstellungen zurück. Auch wenn noch nichts konfiguriert war: Wenn du vorher schon einmal die Weboberfläche aufgerufen hast, setze sie zurück.
Was ist aus der Einstellung mit der maximalen Bandbreite geworden? Hat die nicht geholfen? Was ist mit dem Screenshot mit den verschiedenen Netzwerken auf eth1? Wo kommt der her, was ist dort eingestellt? Es gibt noch zahlreiche Ansätze, zu denen du keine Rückmeldung gegeben hast.
Ich kann nur maximale Bandbreite einstellen.
Das könnte genau der fehlende Wert sein.
Was sind das für Screenshots? So völlig ohne Kontext wo sie herkommen ist es schwer, zu beurteilen, was man da einstellen kann. Aber das zweite Bild mit mehreren Netzwerken auf einer Schnittstelle könnte darauf hindeuten, dass der Router ein VLAN für VoIP erwartet oder zumindest unterstützt. Auswählen solltest du es nicht, denn das gibt es im Modus "Kundeneigener Router" bei der DG nicht, da gibt es nur Internet.
Hm, sollte ich dann mal PPPOE als Verbindung einstellen?
Nein, das unterstützt die Deutsche Glasfaser nicht. Der Modus muss schon bleiben. Ich könnte mir trotzdem vorstellen, dass die Digitalisierungsbox kein VoIP ohne PPPOE machen will, weil die Telekom darüber die verfügbare Bandbreite bereitstellt. Keine PPPOE Verbindung = keine Information über die Bandbreite = "no bandwidth" bei einem Telefonat.
Ggf. kannst du auch irgendwo die verfügbare Bandbreite händisch einstellen?
2026-08-06 16:55:03.464 APP media_handler.c(1566) : media_session_prepare_audio(call=8991) failed, no bandwidth available
[...]
2026-08-06 16:55:03.464 APP_INFO iwu.c( 965) : call terminated(8991): mps_cause=media failure, sip_cause=media failureDas wiederholt sich in den folgenden Versuchen. Zwei Verdachtspunkte drängen sich auf:
Die Meldung "no bandwidth available" könnte darauf hindeuten, dass der Router glaubt, er hat nicht genug Bandbreite, um die Audio-Daten zu übertragen. D.h., entweder hat er nicht mitbekommen, dass eine Internetverbindung existiert, oder es fehlt ihm eine dedizierte zweite Verbindung für VoIP. Ist die vielleicht konfiguriert, aber nicht in Benutzung? Vielleicht erwartet das Gerät die auch einfach. Telekom Boxen zeichnen sich ja dadurch aus, Besonderheiten einfach mal vorauszusetzen, weil sie im Telekom Netz verfügbar sind. Wenn die woanders fehlen, scheitern die Funktionen. Das hat man öfter mal mit Telekom Hardware in Fremdnetzen. (Mich wundert, dass du die Verbindung überhaupt aufbauen konntest, denn Telekom nutze normalerweise PPPOE. Vielleicht ist auch die fehlende PPPOE Verbindung der Grund).
Die zweite Möglichkeit ist es, dass sich beide Seiten nicht auf einen Codec einigen konnten, vielleicht aufgrund der konfigurierten Parameter. Das könntest du noch mal überprüfen.
anrufe kommen rein:
2026-08-06 12:51:20 SIP: Incoming call (9007) via 'XXX@dg.voip.dg-w.de' from '01578XXX' to '070XXX'
edit: das erscheint alle paar sekunden mit einem neuen eintrag, die zahl in der klammer ändert sich dabei
Klingt, als ob die Aushandlung scheitert. Da könnte irgendeiner der Parameter noch nicht passen, sei es für die Codecs, die Rufnummernübermittlung oder irgendwas anderes. Wenn es keine Aussagekräftigen Fehlermeldungen gibt, dann musst du dir möglicherweise im Trace ansehen, was da schiefgeht.
Im DNS ist der von DG als alternativer DNS eingetragen.
Warum nur als alternativ? Je nach Algorithmus greift der nur, wenn der erste DNS nicht erreichbar ist, aber nicht, wenn der erste DNS keine Antwort liefert.
der Router ist im PBX
Was genau heißt das?
Dein Anschluss läuft im Modus "kundeneigener Router"?
Registration of Account 'XXXXX@dg.voip.dg-w.de' failed with error 'Not Found (0 bindings)
Das deutet tatsächlich eher auf eine falsche Konfiguration der Benutzerdaten hin, und nicht auf ein DNS Problem. Der Benutzer wird nicht gefunden, der Server schon.
Die Servicewüste war doch schon vollendet oder was genau hab ich jetzt verpasst?
Ja, da hast du was verpasst. Hier tauchen sicher zuweilen einzelne Problemfälle auf, aber über die tausenden problemlosen Supportfälle berichtet niemand. Und wenn man dann noch die dazunimmt, wo einfach nur jemand vergessen hat, den richtigen Stecker in die richtige Dose zu stecken (meistens sind es sogar die Stromkabel), dann werden solche Äußerungen eher lächerlich.
In welchem Umfang du damit Mitarbeiter, die sich wirklich den A... für die Kunden aufreißen, persönlich beleidigst, darfst du dir selber ausmalen. So viel zum Thema, auf welcher Seite die Intelligenz fehlt.
Ja, und wenn man das liest, dann weiß man auch, auf welcher Seite des Telefons die Intelligenz fehlt.
IPv6 ist Teufelszeug, einmal nicht aufgepasst, und ruck zuck ist dein Rechner aus dem Internet erreichbar
Eigentlich nicht, wenn man aufpasst. Router wie Fritzboxen sorgen auch standardmäßig dafür, dass von außen erst mal alles zu ist, und man muss explizit Dinge freigeben, die von außen erreichbar sein sollen.
Das ist bei anderen Router aber ggf. anders. Ich hab hier schon einige Fälle von Konfigurations-Überforderung auf Unify oder TP-Link Geräten gesehen, wo es schon für die Einrichtung des Internetzugangs nicht reichte, und als es dann lief, war die Firewall komplett offen. Ob es hilft, wenn man drauf hinweist? Ich hatte nicht den Eindruck, Rückmeldung auf die Hinweise gabs jedenfalls nie mehr. Wahrscheinlich war das "never touch a running system" wichtiger als eine korrekte Firewall.
Dann hast du die Box vermutlich nicht als IP-Client, sondern als Router über IP konfiguriert. Und die verteilt nun munter fremde RAs.
Ich würde eher vermuten, es gibt einen zweiten RA Verteiler im Netz. Nutzt du einen Repeater oder sowas?
Hast du mal neu getstartet? Nur durch das Deaktivieren der Funktion werden Adressen nicht entfernt, sondern lediglich nicht mehr neu hinzugefügt. Das heißt, ein wirklicher Neustart von Windows wird erforderlich (kein Herunterfahren und wieder einschalten, das ist nicht das gleiche!).
Dann würde aber auch die Kommunikation zwischen den Anschlüssen nicht mehr funktionieren - auch nicht mit öffentlichen IPv6 Adressen. Das dürfte kaum im Interesse der DG Kunden sein.
Falls das nicht klar geworden ist: Die Kommunikationsmöglichkeit der Anschlüsse untereinander ist ein Feature, kein Bug. Spätestens mit öffentlichen IPv6 Adressen sollte das selbstverständlich sein. Bei CGNAT Adressen klappt das zwar nur DG-intern, aber warum sollte es da anders sein? Um auch das noch mal ganz deutlich zu sagen: CGNAT ist kein Sicherheits-Feature!
Tja und da sind wir wieder:
Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)
Immer noch besser, als fehlerhafte IPv6 Adressen zu verteilen. Mit der Fehlermeldung gibt es gar kein IPv6 in deinem Heimnetz, und kann damit auch nicht für gescheiterte IPv6 Verbindungen sorgen. Mit deiner Einstellung kannst du ggf. Probleme im Heimnetz verursachen - siehe den Parallelthread mit den Android Apps.
Und wir hatten auch schon Fälle, da hat es nach einiger Zeit plötzlich mit der IPv6 Adresse geklappt.
Du hast immer noch falsche Einstellungen für die DG, deine IPv6 Adresse ist nicht von denen. So ist das Ticket natürlich hoffnungslos, und wir hier können auch nichts erkennen.
Übrigens: Es gibt Anbieter, die öffentliche IP-Adressen im DG Netz anbieten. Technisch machen die nichts anderes, als die Daten der öffentlichen IP auf die CGNAT IP des Kunden zu routen.
Da kann man sich schon fragen, warum und wozu?
Um das hier zu verhindern:
Das wird halt besonders gefährlich, wenn man hier von einigen "Experten" liest, dass sie ein Netzwerk-Kabel vom LAN Anschluss ihres Routers zum Modem vor dem Router ziehen, um Diagnose-Daten auszulesen. Damit stellt man nämlich eine Verbindung auf Schicht 2 zum Provider her. Würde der das dann nicht blocken, passiert das, was im Heise Artikel beschrieben ist.
Unabhängig davon landen die Daten im Netz des Providers. Das würde ich auch nicht wollen.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
