I saw that too. Hopefully something will happen. I would then also install the BETA to test the functionality.

@Anonymous@“x”#304148

Do you perhaps already know more here?

Show original language (German)
9 days later

@Tux0ne

@iptables

Hello everyone,

I still have problems with calls with Wifi Calling suddenly not working anymore. So better said, after a few minutes or a few calls I can no longer receive outgoing and incoming calls.

However, the “Wifi calling active” icon is still displayed in the notification bar.

A tcpdump on the firewall no longer shows much activity.

I have now tried various settings for the MTU and TCP MSS Size, but nothing helps….

I can use Ping -f to send packets with up to 1473 bytes to the internal and external interface of the pfsense, to the Swisscom router and to the Internet.

The IPSec tunnel from the cell phone to Swisscom still seems to be active. So the SA’s are standing…

But I suspect a problem with the MSS size within the tunnel.

So for another IPsec site-to-site tunnel, I had to reduce the MSS size to 1350 within the tunnel (PFSense -> IPsec -> Advanced -> Maximum MSS)

With the default value of 1400, the tunnel was very slow and certain pages or content could not be transferred.

Therefore, I suspect that there is also a similar problem with the IPsec that the smartphone is based on.

Swisscom would therefore also have to activate MSS clamping so that it would be fixed at 1350 instead of 1400…

But where should I get in touch to test or implement this????? I won’t be able to adjust it on my smartphone.

Thanks for answers

Show original language (German)

I’ve now tried to reduce the MTU on the external PFsense interface to 1400.

But that didn’t help anymore.

When I want to initiate an outgoing call, I only get the following:

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=0×1100722c,seq=0×9b), length 1332
22:19:10.528141 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP encap: ESP(spi=0×1100722c,seq=0×9c), length 1332
22:19:11.487862 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP encap: ESP(spi=0×1100722c,seq=0×9d), length 1332
22:19:13.430598 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP encap: ESP(spi=0×1100722c,seq=0×9e), length 1332
22:19:17.258679 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP encap: ESP(spi=0×1100722c,seq=0×9f), length 1332
22:19:24.980079 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP encap: ESP(spi=0×1100722c,seq=0xa0), length 1332
22:19:58.326931 IP 192.168.5.135.35635 > 138.188.106.228.4500: UDP encap: ESP(spi=0×1100722c,seq=0xa1), length 1332

So no incoming packets

A working call looks like this:

22:21:35.622090 IP 192.168.5.135.53705 > 138.188.106.228.4500: UDP encap: ESP(spi=0×9202e82d,seq=0×60), length 116
22:21:35.625260 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1ae), length 132
22:21:35.645489 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1af), length 132
22:21:35.662218 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b0), length 132
22:21:35.683829 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b1), length 132
22:21:35.704340 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b2), length 132
22:21:35.728560 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b3), length 132
22:21:35.749275 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b4), length 132
22:21:35.770222 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b5), length 132
22:21:35.781281 IP 192.168.5.135.53705 > 138.188.106.228.4500: UDP encap: ESP(spi=0×9202e82d,seq=0×61), length 116
22:21:35.791074 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b6), length 132
22:21:35.810220 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b7), length 132
22:21:35.837495 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b8), length 132
22:21:35.854963 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1b9), length 132
22:21:35.872917 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1ba), length 132
22:21:35.892020 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1bb), length 132
22:21:35.911166 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1bc), length 132
22:21:35.933626 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1bd), length 132
22:21:35.943515 IP 138.188.106.228.4500 > 192.168.5.135.53705: UDP encap: ESP(spi=0×6a272c0a,seq=0×1be), length 132
22:21:35.944793 IP 192.168.5.135.53705 > 138.188.106.228.4500: UDP encap: ESP(spi=0×9202e82d,seq=0×62), length 116

It’s a hassle… and I’m actually really dependent on wifi calling due to no cell phone reception…

Show original language (German)

The whole problem has nothing to do with MTU and MSS… but much more simply, it is a problem with the standby mode of the Galaxy S7 (and if you believe the various entries on the web, with other Samsung smartphones and also devices from other manufacturers) .

If you have WiFi calling active, outgoing and incoming calls only work until the device is in standby mode for the first time (even if the WiFi connection is set to be active). Incoming calls no longer come through, and outgoing calls usually work because the cell phone is reactivated.

However, you can ping the cell phone’s IP all the time.

Seems like a smaller heartbeat needs to be used in the IPsec connection for Wifi calling.

Is there anyone from Swisscom product support who can raise this issue with Samsung?

Greeting

Show original language (German)
a month later

@sToRmInG

The Google smartphones (Nexus and Pixel) are not sold through the official partners (Swisscom, etc.) in Switzerland. For this reason, we currently have no possibility or influence on bringing our carrier settings into the firmware of the corresponding devices.

Show original language (German)

Hello @MarcoSa

Thanks for the feedback.

But I have to contradict you here, because like us @Anonymous after a request from me ([https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-mobile-dienste/Advanced-Calling-VoLTE-und-WiFi-Calling/m-p/452979#M2191] (https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-mobile-dienste/Advanced-Calling-VoLTE-und-WiFi-Calling/m-p/452979#M2191)) had communicated ([https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-mobile-dienste/Advanced-Calling-VoLTE-und-WiFi-Calling/m-p/459421#M2318] (https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-mobile-dienste/Advanced-Calling-VoLTE-und-WiFi-Calling/m-p/459421#M2318)), There would be an option with the carrier app, but the part is still incomplete and Google has been informed about it.

@[deleted] had already asked whether anything had happened since the beta of Android 7.1.2 from Google ([https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-mobile-dienste/Advanced-Calling-VoLTE-und-WiFi-Calling/m-p/481515#M2641] (https://community.swisscom.ch/t5/Diskussionen-%C3%BCber-mobile-dienste/Advanced-Calling-VoLTE-und-WiFi-Calling/m-p/481515#M2641)), because apparently changes have already been made here.

Since the day before yesterday, the Carrier Service app has been moved to the PlayStore, but still without much functionality.

Maybe you can tell us more about Android Beta 7.1.2?

Thanks in advance.

Show original language (German)
8 days later

@Alex75

@tohil

The update to correct call forwarding on Galaxy S7 and Galaxy S7edge Openmarket devices has been provided by Samsung and is now available for download via FOTA or PC update.

Galaxy S7 edge

OS: 7.0

AP: G935FXXU1DQC4

CP: G935FXXU1DQC2

CSC: G935FAUT1DQC2

Galaxy S7

OS: 7.0

AP: G930FXXU1DQC4

CP: G930FXXU1DQC2

CSC: G930FAUT1DQC2

Show original language (German)

@MarcoSa

Hello, exactly with the update to OS 7.0 a few days ago, it now really seems to work. It took a long time, but now it seems to be OK.

Thank you very much for the update and information.

A lovely evening!

Show original language (German)

Since last week when the update to OS 7.0 for the Samsung S7 edge came out, call forwarding has been working again for me. Unfortunately, video telephony is still not possible.

Show original language (German)

Video telephony: Video over LTE (ViLTE) is not implemented in the network. Therefore it doesn’t work. But we’re currently looking at it. Ask me again in 12 months.

Show original language (German)

@Anonymous When I make a video call, the smartphone switches from 4G to 3G but then the connection is lost. Then ask again in 12 months:smileyhappy:

Show original language (German)
18 days later

@Anonymous Is there definitely nothing more coming for the unbranded S6 edge? Then I can flash your Nougat firmware straight away, which was typically released a month ago for this Samsung juice shop, while the open device is stuck on Marshmallow (with the Marshmallow update it took a full six months from the release of the Swisscom firmware to for the OTA update for free devices).

Show original language (German)
21 days later

Is “inOne Mobile Light” not supported again? SMS tells me that use with this subscription is not possible. The subscription is definitely on the new stack

…

Show original language (German)

Not at the moment. But coming later this year. We still have to build the so-called OLO tone on the new stack so that priced minutes in third-party networks are signaled to the customer. This happens in June. Then we will start migrating the subscriptions to the new stack by the end of 2017 and thus make them VolTE-capable. I would like to ensure that as many customers as possible can use VoLTE with suitable devices. We’re working on it.

Show original language (German)
8 days later