Why Are You Speeding Up My Wi-Fi Calling, Apple? (It Might Make Things Worse)

It's summer in Los Angeles, which can only mean one thing: Sequels!

As movie fans indulge in a third 'Avengers', a fifth 'Jurassic Park', and what feels like a seven hundreth 'Star Wars', this here blog is providing a sequel to a probably-long-forgotten Sniff Wi-Fi post called 'Why Are You Slowing Down My Wi-Fi, Apple?'

Turn down the lights, pop some popcorn, and enjoy the twists and turns of this harrowing look into Wi-Fi Calling on iPhones.

Several months ago, this blog highlighted the Wi-Fi behavior of the iPhone X using OmniPeek.  Truth be told, that post was a little bit like the latest 'Spider-Man' sequel: attention-grabbing title, some interesting content, but ultimately nothing consequential.  And just as movie fans knew that Michael Keaton's flying bird character wasn't going to beat the lead superhero,  a lot of Wi-Fi folks already knew that Apple iOS devices use Protection (called a "TXOP" in the blog post; Devin Akin corrected me, pointing out "TXOP" can refer to non-RTS/CTS communication) when transmitting Wi-Fi traffic.

At this point, some Wi-Fi folks might be feeling like movie fans who missed the last 'Jurassic Park' movie, and are wondering why Chris Pratt's character cares about Blue the Raptor: "What is Protection," they might ask.

Protection occurs when an AP or client device reserves the Wi-Fi channel for a window of time before transmitting data.  Just as Universal Studios has reserved April 10, 2020 as the release date for the next 'The Fast & the Furious' sequel, Wi-Fi devices (both clients and APs) reserve windows of time via Request-to-Send/Clear-to-Send (RTS/CTS).  Both RTS and CTS frames carry a large Duration value in their headers, thus causing all nearby Wi-Fi devices on the channel (even devices on neighboring Wi-Fi networks) to stay quiet, and avoid causing a Vin Diesel/Jason Statham style collision.  The downside of RTS/CTS (and the reason for the 'Why Are You Slowing Down...' part of the title of the prequel to this post), is that RTS and CTS frames use channel time without carrying data, much like The Rock uses screen time without being a true member of the Fast & Furious family.

But alas, things are not always what they seem.  And just as Split was a surprising entry to the 'Unbreakable' universe, the way Wi-Fi Calling is done has created a twist in the world of RTS/CTS Protection.

Behold, a recent capture of an iPhone doing Wi-Fi Calling:

Whoops.  Apologies.  That's a screenshot from the toilet scene of 'Dumb & Dumber', a movie that could have done without its sequels.

Here is the Wi-Fi Calling capture:

The Wi-Fi traffic pattern above is just as noticeable as Luc Besson's pattern of casting women he wants to hook up with in 'Transporter' sequels: Data -> Ack -> Data -> Ack.  Nary a RTS or CTS to be found.

As with the sequel to 'Terms of Endearment' (can any Sniff Wi-Fi readers even name that sub-classic?) the audience of this blog post may be asking "what's the point?"

The point is that Apple is pulling a 'Crank: High Voltage' with iPhones' Wi-Fi Calling: making it faster, but with a higher likelihood of collisions.

Removing Protection from Wi-Fi Calling doesn't make a whole lot of sense if the goal is to have collision-free calls, but then again it didn't make a whole lot of sense to set the sequel to 'Speed' on a boat.  Perhaps Apple's rationale is that the Voice category of 802.11e quality of service (QoS) is good enough to avoid collisions, similarly to how the producers of 'Speed 2: Cruise Control' felt that Jason Patric was a good enough facsimile of Keanu Reeves. 

Whatever Apple's rationale, the moral of the iPhone story is that Protection has been disabled for Wi-Fi Calling, just as the moral of 'John Wick: Chapter 2' was that John Wick will kill people using a variety of firearms, even for reasons beyond avenging a canine.

***

If you like my blog, you can support it by shopping through my Amazon link, becoming a Patron on Patreon, or by donating bitcoin to 1CcEkG8DJD6VWUr27GwtGzPWRQDFt3qgye

Thank you.

Twitter: @Ben_SniffWiFi

ben at sniffwifi dot com