Implikation von "WLAN CALL" mit VCM

[Koppelfeld]

Hallo zusammen,

ein Kunde beschwert sich, daß kommende Anrufe "von modernen Handys mit 5G" direkt nach Annahme zu Verlust gingen.

Stellt sich reproduzierbar heraus: Die aktuellen Multifunktionsgeräte von Apple nutzen "WLAN Call". Das gibt es auch bei "Android", seither hat man dort auf Druck der Provider die VoIP-Telephon-Anwendung aus dem Programm genommen.

Man soll ja nicht immer meckern; mir wäre es allerdings lieber, wenn der Provider mir eine v6-Adresse für mein Mobiltelephon zuweisen würde, über die ich es dann via SIP erreichen könnte.

Aber wie auch immer: Letztendlich baut der Provider, in diesem Falle T-Mobile, eine SIP-Verbindung zum angerufenen Teilnehmer auf. Konkret ist es ein Telekom-Businessanschluß, terminiert vom VCM. Von dort aus geht es - selbstverständlich via SIP/RTP und nicht über ISDN - weiter an eine recht große TK-Anlage.

Anruf über Eifon ohne "WLAN Call": 10 von 10 Versuchen erfolgreich
Anruf über Eifon mit "WLAN Call": 10 von 10 Versuchen unmittelbar nach Gesprächsaufbau getrennt

Hat schon jemand dieses Problem gehabt und ggfs. sogar schon behoben ?

Router: LANCOM 9100+ mit der letzten aktuellen Firmware 10.42 .

[GrandDixence]

Keine Ahnung wie T-Mobile (Deutschland) das Wifi Calling aka "WLAN Call" realisiert hat. Üblicherweise wird dazu vom Mobiltelefon ein VPN-Tunnel mit IKEv2/IPSec realisiert. Der VPN-Tunnel dient der Kommunikation mit dem IMS. Siehe dazu (auch Seite 2 beachten!):
https://community.swisscom.ch/t5/Mobile ... d-p/569594

Somit wird bei korrekt konfigurierter Firewall => DENY_ALL/BLOCK_ALL-Strategie Wifi Calling unterbunden.

Wenn Wifi Calling eingesetzt werden soll, muss dafür gesorgt werden dass NAT-Traversal die Verbindung mit einem alle 15 Sekunden zu versendenden Datenpaket offen hält, oder das UDP-Aging ist entsprechend zu konfigurieren.
viewtopic.php?f=31&t=17621&p=99943#p99943

[Koppelfeld]

Auf "meiner" Seite habe ich aber gar kein NAT. Daher ja überhaupt
der LANCOM - VCM als "Application Level Gateway" zur TK-Anlage.

[tstimper]

Hi Koppelfeld,

eine Idee, das muss für Dein Szenario nicht passen, hilft aber vielleicht bei der Fehlersuche.

Wir hatten in Zusammenhang mit WLC-Tunnel und LX-APs WLAN Call Probleme.
Firmware auf den WLC-1000 und dem zentrahlen 1906VA war die 10.42.xx
Hier war das Problem folgendes, gefixt in der 10.42-RU7

Bei Verwendung eines WLC-Tunnels müssen Datenpakete eine Paketgröße
mit einem Vielfachen von 8 aufweisen. Je nach verwendeter PMTU konnte
es aber vorkommen, dass der WLAN-Controller Datenpakete mit einer
Paketgröße sendete, bei denen dies nicht der Fall war. Dies führte in
Verbindung mit Access Points mit LCOS LX-Betriebssystem dazu, dass diese
die entsprechenden Datenpakete nicht verarbeiten konnten und die Pakete
somit verworfen wurden.

Das führte sporadisch im WLAN zu VPN Dialin Fehlern, Kerberos Anmelde Fehlern, WLAN- Call Abbrüchen.

Zusätzlich haben wir WLC Tunnel, bei denen wird bei der Standard Configuration der UDP Traffic an alle WLAN Teilnehmer geschickt.

Und jetzt kommt ein Smartphone ins WLAN und will WLAN Call machen.

Es erstellt einen IKE/ IVEv2 over HTTPS Tunnel zum Provider , das ist dann (irgendwie...) UDP VOIP in UDP VPN in HTTPS TCP getunnelt.

Das Smartphone ist also im WLAN und beim Provider angemeldet. Soweit, so gut.
Problematisch wird es, wenn nun jemand dieses Smartphone anruft.

Fall1: WLC-Tunnel Fehl Konfiguration: Sollte eigentlich kein Problem sein, da durch TCP getunnelt wird und nur UDP Pakete im WLAN gefloodet werden.

Fall 2: CAPWAP LCOS - LX Missmatch -> die PMTU wird nicht beachtet, eingehende VPN und WLAN Call Pakete wirft der WLC weg.

Fall 3: irgendwo auf der Strecke ist auch noch jemand beteiligt der die PMTU herabsetzt wie z.B. VPN Tunnel, Provider,
feste Einstellung auf einem Netzwerkdevice, was auch immer..

Nun gibt es in LCOS 10.50-RU5 folgende Anpassung:

VPN
→ Für ein Interface mit noch nicht ausgehandelter MTU wurde ein Standard-
Wert von 1280 Bytes verwendet. Da die Anpassung an die MTU nicht korrekt
funktionierte, wurde weiterhin der Standard-Wert von 1280 Bytes verwendet.
Dies führte dazu, dass größere Pakete mit gesetztem ‚Don‘t fragment‘
Flag über eine VPN-Verbindung nicht übertragen werden konnten und die
Kommunikation somit stark gestört oder nur sehr langsam möglich war.

Die 10.50- gibt es soweit ich sehe aber noch nicht für den LC-9100+

Noch was: wir hatten bei einigen Zweigstellen das Problem, das die Provider für den sicheren VPN Betrieb uns eine MTU von max 1300 empfohlen hat.

Zusätzlich haben wir gelernt, das es für VPN bis LCOS 10.50-RU5 der Standardwert von 1280 gilt.

Wir sind wir nun mit der 10.42 zu funktionierenden WLAN Calls gekommen?

1. WLC-Tunnel auf Bridge umstellen
2. LCOS 10.42-RU7 einspielen
3. MTU überall wo es geht auf 1250 einstellen.

Möglicherweise braucht Du testweise nur mal die MTU auf 1250 einstellen.

Wie gesagt, das muss für Dein Szenario nicht stimmen, es sieht für mich nur ähnlich aus zu dem, was wir mit WLAN Call durchlebt haben ...

Viele Grüße

ts

[Koppelfeld]

Moin und vielen Dank für die ausführliche Antwort !

Wir hatten in Zusammenhang mit WLC-Tunnel und LX-APs WLAN Call Probleme.
Firmware auf den WLC-1000 und dem zentrahlen 1906VA war die 10.42.xx

Beim Kunden geht es um _eingehende_ Rufe, und reproduzierbar mit Eifon über T-Mobile an IP-Business-Anschluß kommt es nach Gesprächsaufbau zu einem Ausfall des Tons. Manchmal hört man eine halbe Sekunde. Mit deaktiviertem "WLAN Call" hingegen klappt es dann auch mit dem Ton in beide Richtungen.

Mein Bauchgefühl sagt mir, "der VCM will einen Reinvite machen und scheitert dabei". Was wäre das schön, wenn man ihm dieses Feature abgewöhnen könnte. Mit so einer Option.

Zusätzlich haben wir WLC Tunnel, bei denen wird bei der Standard Configuration der UDP Traffic an alle WLAN Teilnehmer geschickt.

ACH DU DICKE KCKE ...
Ist das gemacht, daß diese doofen Eierfones ihren mDNS - Spökes machen können ?!?
Und was ist mit "QUIC" ? Da wird mir gerade schlagartig klar, wieso ein Kunde sich dauernd beschwert.

Und jetzt kommt ein Smartphone ins WLAN und will WLAN Call machen.
Es erstellt einen IKE/ IVEv2 over HTTPS Tunnel zum Provider , das ist dann (irgendwie...) UDP VOIP in UDP VPN in HTTPS TCP getunnelt.

Ja, man kotzt im Strahl.

Möglicherweise braucht Du testweise nur mal die MTU auf 1250 einstellen.

Möglicherweise löst das einige unserer anderen Probleme, vielen Dank nochmal !

[tstimper]

ACH DU DICKE KCKE ...
Ist das gemacht, daß diese doofen Eierfones ihren mDNS - Spökes machen können ?!?

Oh ja ……..

In unserem Fall haben wir es allerdings über ein iPhone herausgefunden, das irgendwas wie Google Home DNS suchte… (genaues müsste ich raussuchen)

Jedenfalls starteten wir mit einigen Test APs
und so ab ca 20 APs eskalierten die Probleme.
Jetzt nach der Umstellung der WLC-Tunnel auf Bridge
läuft es stabil mit über 100 APs.

Es reicht ja , das es im WLAN z.b. eine Public Spot
SSID mit WLC-Tunnel (ohne Bridge) gibt, da kann ein mDNS rufendes Smartphone das ganze WLAN killen.

Herausgefunden haben wir es über Syslog und Wireshark.

Diese UDP Verhalten hat LANCOM im LCOS 10.40 geändert,
bis 10.34 war das nicht so.

Wie gesagt, das muss mit deiner ursprünglichen Frage nichts zu tun haben ….

Wenn das WLAN nicht so groß ist, reicht vielleicht schon die MTU Anpassung.

Oder es ist wirklich auch noch ein Problem des VCM…

Viele Grüße

ts

[GrandDixence]

Das Thema (Path-)MTU wurde unter:
fragen-zur-lancom-systems-routern-und-g ... 18492.html
genügend ausführlich behandelt.

In der Regel verwendet der VPN-Tunnel zum IMS die altbekannten Ports UDP 500 und UDP 4500 (IKEv2/IPSEC mit NAT-Traversal). In diesem VPN-Tunnel wird für Wifi Calling verschlüsselt die SIP- und RTP-Kommunikation vom Mobilgerät ins Kernnetzwerk des Mobilfunknetzwerks übertragen. Für den Aufbau des VPN-Tunnels zum VPN-Endpunkt des Mobilfunknetzwerkbetreibers (zum Beispiel: T-Mobile) wird DNS verwendet. Dieser DNS-Name basiert auf der Mobilfunknetzkennzahl. Siehe dazu:
https://de.wikipedia.org/wiki/Mobilfunknetzkennzahl

Zum Beispiel für Swisscom (MCC: 228; MNC: 01):
epdg.epc.mnc001.mcc228.pub.3gppnetwork.org

Den Rest kann man selber mit Packet Capture und Wireshark herausfinden und in den verlinkten Beiträgen nachlesen...

[MoinMoin]

Moin, moin,

ich verstehe das doch richtig, daß es hier um Anrufe geht, bei denen der VCM der "angerufene" ist und irgendwo jenseits der Internetwolke irgendwer mit WLAN-Call der Anrufer? Wenn das nicht funktioniert, dann ist das sicher ein Bug. Ich weiß nur nicht, ob der schonmal von irgendwem gemeldet worden ist. Im Zweifelsfall nochmal über den Support einkippen.

Ciao, Georg