VoLTE in Pixel vs Samsung Phones

Night Photography from Wikimedia Image

When you are implementing mobile core services, and struggling with ridiculous 3GPP standards, (don’t panic, if you work with those docs, you can understand what I am saying! ), you should be grateful if you have a production reference capture. In this step, you probably can test some of your functions and at least try to achieve the same output or data structure.

But in the next step, you need to test it in the field with a real network, sim card, and handset. This step is not very straight forward and because of that, some companies sell testers for these types of mobile services, like SIGOS. But after all, production is something else :) so don’t be so happy if everything seems OK in the lab environment.

From my experience, testing services with real phones from different brands, lets you see various behaviors and then add correct handlers into your implementation. Do not forget that you can not find these things in the 3GPP standards, especially in IMS and VoLTE, because it’s very device dependent.

I guess you know the context now, then let’s deep dive into the main subject of this post: VoLTE behaviors in Google Pixel vs Samsung. I did various tests with Pixel 3a and 6Pro, Samsung S8+, and Samsung S22. Different models of each brand don’t have much difference as they are using the same IMS client app, but the two brands are quite different. I found a few of them and have listed them below:

1- IPSec

The first thing you need to have for VoLTE is IPSec. IPSec in Samsung phones is very straightforward. The device sends a REGISTER over TCP to P-CSCF and offered its IPSec SAs, then P-CSCF send 401 with Server IPSec SAs info and then the next REGISTER from UE would be sent over the IPSec tunnel to P-CSCF.

These tunnels would be used while registration is valid. The point is that Samsung phones send all the SIP signaling requests and responses over ESP with TCP transport, something that they agreed with REGISTER, whereas Pixel phones do not follow this rule and they send some SIP messages over ESP packets but to UDP transport!

In other words, if you want to support Pixel phones, you need to establish IPSec tunnels and listeners for both UDP and TCP.

Pixel UDP SIP ACK Image

**as you can see in the image, VIA transport is UDP, but RURI transport is TCP. It is really weird!

2- SMS over IP

As you see, Pixel needs the UDP listeners as well in P-CSCF IPSec; it seems if the size of the message is small it uses UDP otherwise it uses TCP transport messages that are encapsulated in ESP packets. Another case that is different in Pixel is SMS over IP or SMS in VoLTE. Samsung always sends SMS over TCP, while Pixel sends over UDP!

Pixel UDP SIP MESSAGE Image

3- Dedicated Bearer

One of the VoLTE requirements is the dedicated bearer; which you create a bearer for media (/signaling) when the call is established. It helps that PGW and other elements in the network respect the media traffic and provide enough bandwidth and QoS.

Pixel Dedicated Bearer Issue Image

4- SIP Headers

Another minor difference between Pixel and Samsung is using TEL URI and SIP URI. Pixel uses TEL URI for the To header but Samsung always sends the SIP URI in headers including To. It is important because if you developed an in-house SIP stack, you need to add TEL URI parsing capability into it.

to be continued…

Still might be other differences in IMS clients in these popular brands, so whenever I face with, I will update this post. Although, I will add iPhone and other tested brands soon.

updatedupdated2023-06-042023-06-04