VoWiFi / WiFi Calling funktioniert über NAT64 nicht

[anflagratline]

Guten Tag, ich betreibe OpenWRT in meinem Heimnetzwerk mit IPv6-mostly. Dafür benutze ich Jool innerhalb eines netns in gegebener Konfiguration:

ip netns exec jool-w sh <<EOF
    sysctl -w net.ipv4.conf.all.forwarding=1
    sysctl -w net.ipv6.conf.all.forwarding=1
    sysctl -w net.ipv6.conf.jool-w-r.accept_ra=2
    sysctl -w net.ipv4.ip_local_port_range="32768 32999"
    ip link set dev lo up
    ip link set dev jool-w-r up
    ip addr add dev jool-w-r 192.0.2.2/30
    ip addr add dev jool-w-r fe80::64
    ip route add default via 192.0.2.1
    ip route add default via fe80:1::64 dev jool-w-r
    modprobe jool
    jool instance add --netfilter --pool6 64:ff9b::/96
    jool pool4 add 192.0.2.2 33000-65535 --tcp
    jool pool4 add 192.0.2.2 33000-65535 --udp
    jool pool4 add 192.0.2.2 33000-65535 --icmp
EOF

In allen anderen Anwendungsfällen funktioniert das NAT64 gut, auch DNS64 habe ich und fast alle Mobilen Geräte beziehen auch keine IPv4 mehr. Bei VoWiFi gibt es aber Probleme, Anrufe gehen nicht raus und einkommende werden auch nicht angezeigt. Bei ausgehenden Telefonaten wird es zwar bei der Gegenstelle angezeigt, aber auch nach dem Annahme steckt der Status bei "wird angerufen" bzw. "wird verbunden" fest. Ich habe folgende Firewall Regeln:

Ist das ein bekanntes Problem? Oder kann man das beheben?

Auf allem läuft OpenWRT, das Netzwerk besteht aus:
Fritz!Box 7530 als DSL Modem für 1&1 L2-BSA Anschluss
HP ProDesk mit Virtualisiertem OpenWRT als Hauptverwaltung
2xD-Link X1860 als AP's

Auch 802.11r funktioniert einwandfrei und sollten kein Problem sein für WiFi Calling.

Ergänzung (4. Januar 2026)

Mit Vodafone scheint es manchmal zu funktionieren, Telekom und 1&1 eher nicht. (ausgehend, eingehend besteht das gleiche Problem bei Vodafone)

 

[norKoeri]

WLAN-Telefonie basiert auf VoIP (SIP, SDP und RTP) und das stammt alles noch aus Zeiten, als es das OSI-Modell noch nicht existierte. Oder anders formuliert: Das ist ein Protokoll bei dem man nicht so einfach denken kann, also man kann die IP-Version nicht weg-abstrahieren. Zwar wird ein VPN-Tunnel mit IPSec auch (von anno dazumal) drum herum gelegt … aber trotzdem: Kannst Du uns verraten, warum Du NAT64/DNS64 machst? Nicht dass Du dort bereits auf dem Holzweg bist.

 

[Gulp]

Das OSI Modell gibt es seit 1983, SIP wurde 1999 erstmals vorgestellt .... (RFC verabschiedet 2002) ......

Grüsse

Gulp

 

[norKoeri]

Ja, toll. Wenn die Konzepte gedanklich aber nicht bekannt sind, sind Jahreszahlen für den Hut. Auch ist das RFC-Datum völlig egal, weil solche Standards ewiglich brauchen. Und das Version 2.0 war. Glaub mir einfach.

 

[anflagratline]

warum Du NAT64/DNS64 machst

Simpleres Heimnetzwerk, mein Gastnetz ist komplett IPv6 ohne IPv4 und sobald Windows mit ihrer 464XLAT implementation fertig ist wird auch vom Heimnetz IPv4 verabschiedet. Ich brauche nun mal IPv4 Intern nicht mehr.

 

[norKoeri]

IPv6-mostly, ist aber eben genau das Gegenteil, nämlich erstmal IPv6-only um IPv4-Adressen zu sparen, die man wie wild für (abertausende) Legacy-Clients im (Heim-)Netz braucht, aber nicht so viele mehr haben will. Das ist nix für uns daheim, das ist für Großkonzerne und und Hochschul-Netze.

Problem bei SDP ist nämlich, dass dort wie wild IP-Adressen hart kodiert drin stehen. Daher auch mein Hinweis auf das OSI-Modell. Ich bezweifele auch, dass alle diese neueren Standards so getestet sind, dass das berücksichtigt wurde.

Mein Tipp: Probiere mal einen normalen VoIP/SIP-Client mit einem Telefonie-Anbieter über IPv4 und dann über IPv6 und dann über Deine Translation zum Laufen zu bekommen. Das hat den Vorteil, dass Du Dank Klartext UDP-Nachrichten wenigstens mitschneiden/lesen kannst, also bei Wireshark verfolgen kannst. Vielleicht hilft das.

OpenWRT

OpenWrt hat eine extrem kurze Zeit bei den NAT- bzw. hier bei IPv6 bei den Firewall-Bindings – nur 60 Sekunden. Der andere Ansatz wäre Gegenzutesten, also erstmal ganz normal mit OpenWrt und IPv4, also ob der VPN-Client für die WLAN-Telefonie oft genug seine Keepalives macht.

1&1 L2-BSA Anschluss

Hast Du noch DS-Lite oder schon Dual-Stack freischalten lassen?

 

[anflagratline]

ganz normal mit OpenWrt und IPv4

Habe ich vergessen zu erwähnen, mit IPv4 ohne DNS64 klappt alles.

Dual-Stack freischalten lassen

Habe tatsächlich von Beginn an richtiges DS.

SDP

Was genau ist mit SDP gemeint?

 

[norKoeri]

https://en.wikipedia.org/wiki/Session_Description_Protocol

 

[thomasschaefer]

Ich habe das Problem auch in mehreren IPv6 only/mostly Netzen.
Eine Lösung dazu habe ich nicht gefunden.
Lass dich nicht entmutigen von einigen warum-Fragern.
Ja, ipsec(V4) über 464xlat ist von hinten durch die Brust ins Auge.

Es gibt allerdings auch funktionierende Setups. Wenn man ein iPhone (sorry, das Gegenteil von OpenWRT) verwendet mit Telekom SIM und Hotspot - dann kommt IPv6mostly raus - und Wifi-call (im WLAN des Hotspot) geht trotzdem.

Es gibt einen offensichtlichen Unterschied, Apple setzt die MTU im Hotspot radikal runter, aber noch weit über dem Minimum.
Mehr Unterschiede habe ich noch nicht entdecken können - zwischen IPv6mostly WiFi call funktioniert und funktioniert nicht.

 

[anflagratline]

Ich habe noch vergessen zu Erwähnen, dass wenn der Anruf schon läuft und ich dann zu VoWiFi wechsel, der Anruf weiterlaufen kann ohne Probleme.

MTU im Hotspot

Auf was beläuft diese sich?

 

[Gulp]

Ja, toll. Wenn die Konzepte gedanklich aber nicht bekannt sind, sind Jahreszahlen für den Hut. Auch ist das RFC-Datum völlig egal, weil solche Standards ewiglich brauchen. Und das Version 2.0 war. Glaub mir einfach.

Ehrlich? Ich glaub Dir gerne, dass SIP nicht das Gelbe vom Ei ist, dass es älter als das OSI Modell ist, so wie beispielsweise IP aus den 70ern, ist allerdings Mumpitz! Das lässt sich im Entwurf des ersten eingereichten RFC Antrages mehr als deutlich herauslesen ..... https://datatracker.ietf.org/doc/html/rfc2543

Und daruas zitiere ich mal:

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.

Hört sich meiner Meinung aber ganz schwer nach dem Application Layer des OSI an ....... ach nee steht ja sogar da. ;-)

Glaub mir einfach!

Grüsse

Gulp

 

[thomasschaefer]

Die Diskussion über SIP (sogar mit IPv6 Adressen) ist meiner Meinung nach hier viel am Platz. Das Problem ist der ipsec Tunnel. Der verwendet IPv4.
Apple reduziert die MTU für den Hotspot auf 1450.
Im ipsec Tunnel steht dann tatsächlich nur noch 1280 zur Verfügung.

 

[anflagratline]

Ich habe es geschafft!

Meine erste Idee war es, DNS64 für die EDPG Server zu deaktivieren, das hat aber nicht wirklich funktioniert. Jetzt habe ich in meiner Jool instance die lowest-ipv6-mtu auf 1492 gesetzt, und jetzt geht alles.

jool global update lowest-ipv6-mtu 1492

Beim Gastnetz hilft dies auch, wobei ich wahrscheinlich noch die passende MTU suchen muss damit es 100% der Zeit funktioniert.
Ob das jetzt auch für andere IPv6-mostly Netze der Fehler ist, keine Ahnung, aber für mich hat es jetzt geklappt.

 

[norKoeri]

deutlich herauslesen

Das stehen gleiche Begriffe drin, die aber nichts mit dem Konzept zu tun haben. Die Idee des OSI-Modells ist, dass man Abstrahieren kann, sich nicht mehr um die Schichten kümmern muss. SIP durchstößt das absichtlich, aber eben falsch gemacht.

nach dem Application Layer des OSI an

SIP will das sein, ist es spätestens Dank SDP eben nicht mehr. Man geht durch SDP einmal den ganzen Stack runter und für RTP wieder rauf. Oder anders formuliert: Dein zitierter Text ist einfach gelogen … wenn man annimmt, die Autoren hätten das Konzept gekannt und verstanden.

Aber schön das es nicht IPv6 sondern die MTU war. Auf welcher OSI-Ebene ist die nochmal?

 

[Gulp]

Schicht 3 (Vermittlungsschicht) ...... selbst SDP ist im Session Layer (Schicht 5) angesiedelt, klar die RFC lügt .......

Aber jeder wie er will, dann bin ich halt Lügenpresse ....... macht mir nix.

Grüsse

Gulp