FRITZ!OS 07.01 oder 06.85 (FRITZ!Box 7590, 7490, 7362 SL)
Yealink xx.84.00.10 oder xx.83.00.50 (SIP-T41S)
So, ich habe die obigen Konstellationen nachgetestet. Wobei ich der Einfachheit „IPv6-only“ im Yealink eingestellt habe. Ich bekomme eine IPv6-Adresse aber der (Default-) Gateway bleibt leer („::“ im Web-Interface, „::/64“ im Telefon-Interface; Ticket 70178). Eine (öffentliche) IPv6-Adresse bekomme ich auch nur falls
fritz.box » Heimnetz » Netzwerkeinstellungen » IPv6-Adressen » (DHCPv6-Server im Heimnetz) DNS-Server, Präfix und IPv6-Adresse zuweisen (Ticket siehe oben). Dafür muss die FRITZ!Box auch noch (komplett) neu gestartet werden – ein Software-Bug seitens AVM (Ticket 2316273). Kannst Du das nachstellen?
Wirklich Sinn macht das nicht, denn das Yealink macht auf der SIP-Ebene immer noch kein IPv6. Erst wenn Du im Yealink DHCPv6 ausschaltest und die Adressen manuell einträgst, dann klappt IPv6. Jedenfalls bei mir. Das war IPv6-only. Dual-Stack habe ich jetzt nicht weiter getestet.
Übrigens: Bei meinen Speedport NEO (Firmware 2.5.002.6) klappt IPv6 (mit Gateway) falls Yealink » Web-Interface » Advanced » Network » ICMPv6 Status: Enabled. Aber beim Speedport klappt dann die automatische DNS-Erkennung in IPv6 nicht. Stattdessen muss ich die DNS manuell zuweisen (oder Dual-Stack wählen und den DNS aus IPv4 nehmen).
Einen DHCPv6-Server braucht man nur …
Schön. Aber Du erzählst das den Falschen.
Das Problem ist, dass Tisch-Telefone aktuell IPv6 noch nicht ordentlich implementiert haben. Wenn Du in einem Tisch-Telefon sein „IPv6“ aktivierst, dann verhält es sich anders als die großen Betriebssysteme (Windows, macOS, Ubuntu, …). Außerdem sind die Implementierungen mit Software-Bugs nur so gespickt. Was die Lage ganz schlimm macht: Kein Hersteller erklärt, welches Szenario er überhaupt getestet hat:
- IPv6-only SIP-Server,
- IPv6-only lokales Netz,
- IPv4/IPv6 Dual-Stack.
Alle drei Szenerien sollten gehen. Ähnliches bei der Ermittlung der Adressen:
- DHCPv6-Server für IPv6-Adresse und DNS-Server,
- SLAAC mit DNS-Server über DHCPv6-Server (Standard-Einstellung einer FRITZ!Box wegen Windows 7 und 8) oder
- SLAAC mit DNS-Server über RDNSS (RFC 5006; inzwischen unterstützt von den großen Betriebssystemen).
Wegen dieser fehlenden Dokumentation kann selbst ein engagierter Administrator sein Netz nicht gezielt umstellen. Deswegen muss ein Admin sich durch jeden Software-Bug durchwurschteln.
Deiner Beschreibung nach fangen die Probleme erst mit IPv6 an.
IPv6 ist an sich eine tolle Sache. Es wird nicht alle „NAT“-Probleme lösen, weil Viele unter NAT auch Probleme verstanden, die eigentlich auf die Firewall bzw. deren Intrusion-Detection zurückzuführen sind. Mit IPv6 hast Du (hoffentlich) weiterhin eine Firewall.
Das Problem ist nicht „IPv6“ sondern deren aktuelle Umsetzung in den Tisch-Telefonen. Du rennst in Software-Bugs, Fehler der Hersteller. Bei einigen Herstellern gehen IPv6-only SIP-Server nicht, bei einigen gehen IPv6-only Netze nicht, bei einigen muss DNSv6 manuell zugewiesen werden (obwohl das Web-Interface etwas andere vorgaukelt) und so weiter. Bei allen meinen 14 getesteten Implementierungen brauchte ich DHCPv6, um DNS zuzuweisen. Bisher konnte ich nur bei Snom (
8.9.3.96) und Digium D-Series Phones (
2.7.0) auf DHCPv6 verzichten, um auch die IPv6-Adresse zuzuweisen (Standard-Einstellung einer FRITZ!Box). Aber diesen beide können aktuell kein IPv6-only im lokalen Netz und die Ergebnisse im Dual-Stack-Betrieb waren entsprechend durchwachsen.
Die Latenz ist in der Öffentlichkeit anscheinend kein großes Thema
Hier bei mir schon. Die Leute fallen sich gegenseitig ins Wort, weil die Verzögerung zu groß ist. Cisco hat einen ellenlangen
Artikel zu dem Thema. Aber wie Du schreibst, ist dafür nicht der Echo-Canceller sondern üblicherweise haufenweise Puffer in der Software die Ursache. Wenn dann noch irgendeine Voice-Activity-Detection (VAD) im Audio-Codec herumlungert … aber das Thema wäre ein eigener Thread wert.
Cisco, zumindest die SPA-Serie, ist aber für uns ungeeignet.
Vermutlich auch ein eigener Thread wert. Obwohl ich aktuell Snom-Fan bin, würden mich die genauen Gründe interessieren. Nur zur Info: Cisco hat die SPA-Serie neu aufgelegt als
3PCC …