Ja, leider hat Samsung entgegen Ihrer Ankündigung das Problem noch nicht mit einem Update behoben. Wir fragen noch mal nach, wann das nun kommt.
@Anonym gibt es eigentlich schon News zu WiFi Calling und VoLTE für Nexus Geräte oder gar die neuen Pixel von Google (warum macht Swisscom da nicht mit? Die deutsche Telekom schaffts ja auch :))
Hab ein neues Huawei Mate 9 - bei Digitec gekauft - da Swisscom die DualSim Version nicht verkauft... ;-(
Beim ersten Aufstarten kam die Meldung dass VoLTE und Advanced Calling bei meinem Gerät jetzt verfügbar wäre... also kurz in den Einstellungen alles aktiviert...
Aber nein - das Gerät zeigt nie VoLTE an...
Also Telefon an den Kundendienst...
Antowrt das ist nur bei Geräten mit Swisscom Branding möglich. Alle anderen Geräte werden nicht unterstützt.
Und auch Wifi Calling sei nur bei Bluewin-Netzwerken möglich....
Ist das wirklich so?`Auf der Advanced Calling Seite steht nichts dergleichen...
Die Geräte-Firmware des Huawai Mate9 unterstützt aktuell nur VoLTE jedoch noch kein WiFi-Calling.
Die Firmware unterstützt jedoch Openmarket Geräte.
Auf der Advanced Calling Webseite finden sie alle Geräte, die aktuell VolTE und/oder WiFi Calling unterstützen.
@MarcoSa Habe VoLTE ausgewählt im Menu - und es passiert nichts... trotz vollem 4G Empfang.
Was kann ich noch machen?
Für eine genauere Abklärung benötige ich ihre Rufnummer via PN.
Habe auch ein Mate 9 und Volte funktioniert perfekt. Achtung, im Gegensatz z.B. zum Galaxy S7 zeigt dieses Gerät kein Volte o.ä. in der Statusleiste an. Du kannst es überprüfen in dem du einen Anruf startest. Wenn das Handy auch während des aktiven Anrufs 4G anzeigt, hast du automatisch Volte, wenn nicht wechselt das Gerät beim telefonieren automatisch auf 2G oder 3G.
ich habe ein samsung galaxy s7 und natel entry und (schon vor monaten) eine sms bekommen, dass advanced calling aktiviert wäre.
trotz div. updates konnte ich wifi-calling nicht aktivieren (die entsprechende option ist im menü nicht vorhanden).
im swisscom shop sagte man mir, das wäre mit meinem abo nicht möglich, die nette dame vom online-support meinte aber die voraussetzungen wären erfüllt und das abo würde auch passen.
was meint die geneigte community? 🙂
deleted
In einem alten/früheren Beitrag hier im Forum war mal von Ende 2017 die Rede wo auch alle Business-Abos umgeschaltet sind. Ob dieser Fahrplan noch stimmt weiss ich nicht.
Hallo @Anonym,
2 Fragen 🙂
1. Sind nur die Privatabbo's van SC für WiFi Calling und VoLTE freigeschalted ? Oder auch die Businessabbo's ? Falls nicht, ist das geplant fur dämnachst ?
2. Einkommende und Ausgehende WiFi Calling anrufe im ausland; kosten / tarif technisch, sind die wie 'CH Gespräche' ? Oder gibt es dort auch Roamingkosten ? Auch dort ist eure customer care nicht wirklich klar...
Hallo @wmeter
1. Die Abo's für Privat- und KMU-Kunden sind bereits freigeschalten. Die Abos für Enterprise-Kunden folgen nächstens, wir kommunizieren sobald der Termin bekannt ist.
2. WiFi-Calling im Ausland ist noch nicht freigeschalten, Informationen dazu folgen ebenfalls zu gegebener Zeit.
Es wird wieder spannend für Nexus und Pixel Geräte. Android 7.1.2 Beta ist draussen und wie es scheint sollen einige Provider spezifische Änderungen eingepflegt worden sein. Gibt es hier Infos von seiten Swisscom, ob Wifi Calling mit diesen Devices nun möglich endlich wird?
Das habe ich auch gesehen. Hoffentlich tut sich etwas. Ich würde dann auch die BETA installieren, um die Funktionalität zu testen.
@Anonym@MarcoSa
Wisst ihr hier vieleicht schon mehr?
Hallo Zusammen,
ich habe nach wie vor Probleme, dass Anrufe mit Wifi Calling plötzlich nicht mehr gehen. Also besser gesagt, immer noch ein paar Minuten oder einigen Anrufen kann ich keine abgehenden und eingehenden Anrufe mehr empfangen.
In der Hinweis Leiste wird das "Wifi Calling aktiv" Icon aber noch angezeigt.
ein tcpdump auf der Firewall zeigt dann nicht mehr viel aktivität.
Ich habe nun verschiedene Einstellungen der MTU und TCP MSS Size versucht, aber nix hilft....
ich kann mit Ping -f Pakete mit bis zu 1473 Bytes an das interne und externe Interface der pfsense, an den Swisscom Router und ins Internet absetzen.
der IPSec tunnel vom Handy zu Swisscom scheint noch aktiv zu sein. Also die SA's stehen...
Ich vermute aber ein Problem der MSS Size innerhalb des Tunnels.
So musste ich für einen anderen IPsec site-to-site Tunnel, die MSS Size auf 1350 innerhalb des Tunnels reduzieren (PFSense -> IPsec -> Advanced -> Maximum MSS)
Mit dem Standard Wert von 1400 war der Tunnel sehr langsam und gewisse Seiten oder Inhalte konnten nicht übertragen werden.
Daher vermute ich, dass auch beim IPsec, welches das Smartphone aufbau ein solches Problem vorliegt.
Somit müsste auch seitens Swisscom ein MSS Clamping aktiviert werden, damit diese auf 1350 anstelle 1400 fixiert wird...
Doch wo soll ich mich hier melden um das zu testen oder umzusetzen????? auf dem Smartphone werde ich es kaum anpassen können.
Danke für Antworten
Habe jetzt versucht die MTU auf dem externen PFsense Interface zu reduzierieren, bis 1400.
Das hat aber nichts mehr gebracht.
wenn ich einen abgehenden Anruf initiieren möchte, erhalte ich nur noch folgendes:
22:19:09.893308 IP 138.188.106.228.4500 > 192.168.5.135.35635: NONESP-encap: isakmp: child_sa inf2[R]
22:19:10.042276 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0x9b), length 1332
22:19:10.528141 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0x9c), length 1332
22:19:11.487862 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0x9d), length 1332
22:19:13.430598 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0x9e), length 1332
22:19:17.258679 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0x9f), length 1332
22:19:24.980079 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0xa0), length 1332
22:19:58.326931 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x1100722c,seq=0xa1), length 1332
Also keine eingehenden Packete
Ein funktionierender Anruf sieht so aus:
22:21:35.622090 IP 192.168.5.135.53705 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x9202e82d,seq=0x60), length 116
22:21:35.625260 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1ae), length 132
22:21:35.645489 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1af), length 132
22:21:35.662218 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b0), length 132
22:21:35.683829 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b1), length 132
22:21:35.704340 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b2), length 132
22:21:35.728560 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b3), length 132
22:21:35.749275 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b4), length 132
22:21:35.770222 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b5), length 132
22:21:35.781281 IP 192.168.5.135.53705 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x9202e82d,seq=0x61), length 116
22:21:35.791074 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b6), length 132
22:21:35.810220 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b7), length 132
22:21:35.837495 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b8), length 132
22:21:35.854963 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1b9), length 132
22:21:35.872917 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1ba), length 132
22:21:35.892020 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1bb), length 132
22:21:35.911166 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1bc), length 132
22:21:35.933626 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1bd), length 132
22:21:35.943515 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP-encap: ESP(spi=0x6a272c0a,seq=0x1be), length 132
22:21:35.944793 IP 192.168.5.135.53705 > 138.188.106.228.4500: UDP-encap: ESP(spi=0x9202e82d,seq=0x62), length 116
Es ist zum Haar ausreisen... und ich bin eigentlich echt abhängig von Wifi Calling auf Grund keinem Handyemfpang..
Das ganze Problem hat nichts mit MTU und MSS zu tun... sondern viel simpler ist es ein Problem des Standby Modus des Galaxy S7 (und will man den verschiedenen Einträge im Web Glauben schenken, mit anderen Samsung Smartphones und auch Geräten von anderen Herstellern).
Hat man Wifi Calling aktiv, funktionieren aus- und eingehende Anrufe, nur solange bis dass Gerät das erste mal im STandby Modus ist (auch wenn eingestellt ist, dass die Wifi Verbindung aktiv sein soll). Eingehend kommen dann keine Anrufe mehr durch, und ausgehend geht es meistens da das Handy reaktiviert wird.
pingen kann man die IP des handys jedoch die ganze zeit.
Scheint so, als müsse in der IPsec Verbindung für Wifi Calling ein kleinerer Heartbeat verwendet werden.
Ist hier irgendjemand vom Swisscom Produkte Support, welcher dieses Problem bei Samsung platzieren kann?
Gruss
@Anonym@MarcoSa
Wie sieht es mit VoLTE und Wifi Calling für Nexus Devices aus? Ich habe heute gerade ein Update für den Carrier Service erhalten: https://play.google.com/store/apps/details?id=com.google.android.ims
Bringt dieser evtl. die benötigten Änderungen?
Die Google Smartphones (Nexus und Pixel) werden nicht über die offiziellen Partner (Swisscom,etc.) in der Schweiz vertrieben. Aus diesem Grund haben wir aktuell keine Möglichkeit und auch keinen Einfluss darauf, unsere Carrier Settings in die Firmware der entsprechenden Geräte zu bringen.