Verizon Android Wi-Fi Calling

I’ve been rocking a Samsung Galaxy Note 2 for over three years, and never had any issues with it. In November 2015 I moved into a new apartment, that happens to be a concrete plutonium build castle where no 3G or 4G signal can penetrate. Then I saw in the tech news around December 2015 that Verizon was bringing Wi-Fi Calling to its service (finally), but only to the Samsung Galaxy S6 phone. So I upgraded my phone to the Galaxy S6 and have been using Wi-Fi Calling ever since.

wifi_calling_title_image

I decided to sniff some frames and see how things operate. Lets dig in…

First, here are some quick steps on how to setup Wi-Fi Calling on an Android phone. Verizon calls this ‘Advanced Calling’, which enables HD Voice and Video Calling as well as Wi-Fi Calling.

Step 1:  Go to Settings and choose Advanced Calling.

Step 2:  Activate ‘Advanced Calling’. Here you can also Enable HD Voice and Video if you so choose.

Step 3:  Choose the ‘Wi-Fi Calling’ option.

Screenshot_20160514-182910

Step 4:  Turn Wi-Fi Calling to the ON position.

Step 5:  You will need to update the Emergency Address. This address is supposed to be updated to the location of where the Wi-Fi is located (good luck with that). I just set mine to my home address.

Step 6 – Optional:  Choose ‘When Roaming’.

Step 7 – Optional:  This choice is up to you, but I prefer to have my phone use Wi-Fi over Other Cellular Networks. Click SAVE at the bottom of the screen.

Screenshot_20160514-183016

Keep in mind that just because you have Wi-Fi Calling enabled now, does not mean that your phone will always use it. I’m not positive on what variables or algorithms are set in place for the phone to make its decision on when to swap from 3G/4G to Wi-Fi. I do know that if you want to force it, all you have to do is go into Airplane Mode.

Usually when I am at home, when I make or receive a phone call it will come across over my cellular connection (which says 4G on my phone, but will usually drop to 1X after a few seconds). From the few times that I have been keeping track, the phone will switch from cellular to Wi-Fi Calling usually around 10 seconds into the call, sometimes a little later. I know when it happens every time because there is about a 3 second gap of no audio, where a ‘can you hear me’ will follow suit.

If you look on your phone you can see if it is using Wi-Fi Calling based on the icon at the top of your screen.

Screenshot_20160514-193339

Now that we have Wi-Fi Calling enabled and figured out, lets sniff some frames and packets and see what is going on under the sheets.

 

Network_1

 

Looking at the frame capture below, you can see that the average size of inbound/outbound traffic for the Encrypted Data frames are around 214 bytes.

wifi_communication_overview

As an FYI, my WLAN is set to Platinum QoS

qos_wlc

Looking into one of the frames from the Galaxy S6 upstream to the 2702_AP1, we can see the following details:

  • Frame is marked as Best Effort (WMM_UP 0)
  • Actual data size is 176 bytes

PHONE_TO_VERIZON

 

Now lets look at a frame coming from 2702_AP1 to Nolans Galaxy S6

Below you will notice the following details:

  • Frame is marked as Voice (WMM_UP 6)
  • Actual data size is 176 bytes

VERIZON_TO_PHONE

 

Now we know how Wi-Fi Calling is getting marked over the air, so lets move up in the network to see how the packets are getting handled at my router (which is a pfSense router/firewall).

First we’ll take a look at the LAN port on the pfSense router.

pfsense_LAN_communication_overview

Several key things you will notice:

  • MyGalaxy S6 is talking to IP Address 141.207.149.232
  • The Protocol is ESP and Application is IPsec

I looked up the IP Address through ARIN, it belongs to Verizon (and rightly so).

ARIN

Below we can see the packet going upstream from my Galaxy S6, heading to Verizon.

You’ll notice the following details:

  • Total packet size is 162 bytes
  • Actual ESP size is 108 bytes
  • Packet is marked 0x00 (Best Effort)
  • Packet is UDP
  • Packet is using port 4500 (IPsec-NAT-T)

pfsense_LAN_PHONE_TO_VERIZON

 

Below we can see the packet coming downstream from Verizon to my Galaxy S6.

You’ll notice the following details:

  • Total packet size is 178 bytes
  • Actual ESP size is 124 bytes
  • Packet is marked 0xB8 (EF – Expedited Forwarding)
  • Packet is UDP
  • Packet is using port 4500 (IPsec-NAT-T)

 

pfsense_LAN__VERIZON_TO_PHONE

 

Now lets take a quick peek at the frames being seen on the WAN port of my pfSense router.

pfsense_WAN_communication_overview

Below we can see the packet going upstream from my Galaxy S6, heading to Verizon.

You’ll notice the following details:

  • Total packet size is 162 bytes
  • Actual ESP size is 108 bytes
  • Packet is marked 0x00 (Best Effort)
  • Packet is UDP
  • Packet is using port 4500 (IPsec-NAT-T)

pfsense_WAN_PHONE_TO_VERIZON

Below we can see the packet coming downstream from Verizon to my Galaxy S6.

You’ll notice the following details:

  • Total packet size is 178 bytes
  • Actual ESP size is 124 bytes
  • Packet is marked 0xB8 (EF – Expedited Forwarding)
  • Packet is UDP
  • Packet is using port 4500 (IPsec-NAT-T)

pfsense_WAN_VERIZON_TO_PHONE

And if you’ve come this far, maybe you’re willing to come a little further. You remember the name of the Protocol, don’t you?

esp

So now that we have seen all the packets for the entire path, lets figure out what some of the unknowns are.

ESP (Encapsulating Security Payload) is IP Protocol 50, meaning not based on TCP or UDP, and is used to encrypt the important data information. It is a member of the IPsec protocol suite. Keep in mind that it is not port based, so it is unable to be NAT’ed through a router. Nat’ing involves manipulation of the IP Header and TCP/UDP ports, and this poses a problem with ESP.

IPsec uses ESP and takes the original IP information and securely encapsulate it via encryption. This prevents network sniffers from uncovering its original IP Address information while it is in route.

The NAT issue above is resolved by using NAT-T (NAT-Traversal), which wraps ESP into a UDP packet, which now allows the packet to have a destination and source port.

IPsec uses port 4500 (ipsec-nat-t) for 99% of the communication between my Galaxy S6 and Verizon.

The 1% (as seen below) uses ISAKMP port 500 in order to first establish communication. This happens right after DNS resolves wo.vzwwo.com to the IP Address 141.207.149.232

pfsense_LAN_SOP

From what I can gather, the ISAKMP exchange takes place first in order for both end devices to determine if they support NAT-T. If it is found that they do indeed support NAT-T, then ISAKMP packets change from UDP port 500 to UDP port 4500 (ipsec-nat-t).

pfsense_LAN_SOP_PHONE_TO_VERIZON

I am by no means a security expert, so this was a day of learning for me, and hopefully I got it right.   ^_^

The bad news here is that my Galaxy S6 is sending Wi-Fi Calling data frames at Best Effort upstream. This is kind of….lame. Hopefully Verizon will update their driver so that its marked as Voice.

The good news is that Wi-Fi Calling is Encrypted and secure, which is great when using public open authentication wireless. Luckily Verizon is actually marking the downstream packets as Voice.

Cisco will eventually be releasing NBAR2 Protocol Pack 15. This release will support being able to mark Wi-Fi Calling via AVC profiles. Keep in mind this will only work for downstream, not upstream traffic. So it won’t fix my Galaxy S6 sending Best Effort, but it might fix another Cellular Provider not sending Voice quality packets.

NBAR

I hope you enjoyed this post. Please feel free to leave a comment below and correct me on anything I may have got wrong.

-Nolan

10 thoughts on “Verizon Android Wi-Fi Calling

  1. I turned on wifi calling on my galaxy s7 edge because without it on, my data connection would just completely drop. No calls, no texts, no net. With it on, no issues. I had to go through 2 brand new S7 edges before I figured it out. Even verizon cant figure it out.

    Like

  2. Nolan – thanks for digging into this. Two quick questions/clarifications:

    First – how often was your phone sending packets – at 20 msec intervals, 40 msec? Plus, I would assume it’s symmetric (ie receiving packets at the same rough intervals), true?

    Second, if at 20 msec intervals, would it be fair to characterize a voice call as 50 packets/sec * 172 bytes/packet = 8,600 bytes/sec; or 68,800 bits per sec.

    Thanks,

    steve

    Like

    • Steve. I just took a look at the packet capture and I do see instances of 20ms intervals from my router to my phone (meaning from Verizon side). Not sure if that’s a guarantee though. I see other intervals at 16ms. Don’t think it’s symmetrical. I see chunks of data one way, then only a single packet coming back etc.

      Like

  3. Thanks for the writeup. I’m curious how you feel it performs as a user. You mention the switchover after 10 sec. Anything else? Is the quality consistent once connected? how about when you leave the apartment while on a wifi call – does it drop the call or switch back to the cell network?

    Like

    • Quality is add good as it can be add far as I can tell. I got use to knowing I’ll have a 3 second drop out when the call first picks up (it’s switch from cell to wifi).

      One problem I noticed with recent Verizon update is I can’t seem to receive calls in Airplane mode. Only make them. So I have to leave 3G/4G on to ensure people who call don’t go straight to voicemail. Never tested walking out of a wireless cell to see what would happen. With testing though 🙂

      Like

  4. Is it possible to make wifi-calling as the preferred method while i have wifi access? Signal at my home is pretty bad. But, still verizon doesn’t switch to wifi calling. I want to force it to wifi calling? Is it possible?

    Like

  5. But then when I am outside wifi area, I have to remember turn-off airplane mode again. I tried llama profile, but it doesn’t work as if airplane mode is on, it can’t decide about the location. Any location profile might work. I was looking at Automate app. But, still no success.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s