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…

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

@tohil

Can you please PM me with your phone number.

@Anonymous@“x”#304148

What about VoLTE and Wifi Calling for Nexus Devices? I just received an update for the carrier service today: [https://play.google.com/store/apps/details?id=com.google.android.ims](https://play.google.com/ store/apps/details?id=com.google.android.ims)

Does this possibly bring the required changes?

@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.

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.

@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

@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!

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.

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.

@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).

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

…

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.

@Anonymous
When will VoLTE finally come to business customers?

@Gipri with a CMN (Business Enterprise) contract (Swisscom) it works (Samsung S5 with Android 6)

I can’t say anything about business customers. Sorry.

Real?
Then it probably has something to do with the iPhone 😞

Hello Gipri

If you have any questions about your business cell phone, please contact the responsible fleet manager or mobile manager at your company directly. Thank you very much for your understanding.

After Samsung unexpectedly did it faster than last year, I installed the “normal” Nougat update for my free S6 edge (AUT). Lo and behold, there is now an option for WiFi calls in the call settings (but not for VoLTE). I haven’t gotten around to testing it yet because I don’t have a landline or a second device; But it won’t work on the network side, will it?