VoWiFi
computer.rip
computer.rip
Also, the simultaneous data + voice story is kinda more complicated. You couldn't do simultaneous voice+data on 2G phones. You could do it on UMTS/HSDPA for sure (it was one of the marketing points...). Then when LTE came, for a time phones could not do phone calls over LTE (VoLTE) (something which I was told was just a "missing software thing") so they had to drop down to some 3G standard during any phone call. If your 3G standard didn't have support for simultaneous voice+data, like it used to be on CDMA networks, then you just didn't have data (see CDMA iPhone 5). But it was just fine on GSM ones.
I don’t think the author made this claim at all. He just mentioned that he thinks that Google are using eUICC to make roaming on Google Fi cheaper than traditional roaming agreements. And he’s basing this on the fact that the dat connection can drop out for a little while as the phone roams internationally, presumably because it’s reprogramming the eUICC.
I would assume that if you’re running a service like GoogleFi, where the phone number isn’t associated with an actual phone network, then you can do international roaming cheaper because you just setup direct agreements with local telecoms to provide local data access, and then route the “shadow number” assigned to the SIM to a local Google endpoint. Thus you can create a setup where international roam is achieved by having local only carrier agreements, and doing clever call routing to local Google forwarding numbers, which Google then routes over its own network to the destination country, where a local Google endpoint then pushes the call back into the local telco network.
Doing this completely removes the need to have a traditional roaming agreement where carrier backhaul alien subscribes back to their home carrier, charging a hefty fee for the privilege. And instead replaces it all with local only call and data routing, with Google infrastructure providing international transit, and Google software masquerading the local subscriber identities, so GoogleFi customers don’t see the messy details underneath.
VoLTE roaming agreements do not exist everywhere, so it is still very common to fall back to 3g for calls when roaming.
VoLTE, for example, has been around in concept for longer than LTE, but it has had a complex standards history that I did not try to really explain because it would get lengthy. "VoLTE" and "IMS" can actually refer to different systems (not all VoLTE uses IMS) but it all gets sort of vague and contextual. LTE phones with VoLTE capability have been around basically as long as LTE has been in service in the US, but for a long time were mostly proprietary systems that required per-carrier support. This is still true to some extent but US carriers and device vendors are now much more converged on an IMS-esque architecture than they were even just a few years ago, so it's now a lot more likely that you can e.g. switch to a different carrier and still have VoLTE work... although not guaranteed!
One hint that might help reveal how Google Fi handles this is the source of web traffic on my phone... web requests from my phone in Mexico are coming from an IPv4 address registered via ARIN to Airlinq with a contact address in the UK! Airlinq has some kind of relationship to Hong Kong ISP Hutchison and it seems like the takeaway is that they offer a "global cellular mobility" solution. My guess is that Telcel is being used as the mobile provider (I did some checking of intercept recordings which confirms my voice calls at least are going via Telcel) and IP traffic is being routed via Airlinq, whom Google presumably contracts to handle international IP connectivity. Normally, in the US, my traffic emerges via IPv6 from T-Mobile. This is an indication that my traffic is not being tunneled back to the "home" provider as is the typical case with roaming.
Maybe, but as far as I can tell Google Fi is just a T-mobile MVNO (they used to also use Sprint, but T-mobile bought Sprint ~2 years ago). My direct-with-Tmobile service also includes free international roaming in a ton of countries, so it would make sense if Google just took advantage of the agreements T-mobile already has in place.
Most LTE phones could do HSDPA+ during voice calls but some couldn't. I'm not sure why, it may have just been a simplifying decision by the vendors. This was more of an issue in the very early days of LTE, e.g. my hazy memory is that the HTC Thunderbolt completely dropped data during voice calls.
*Unless visiting countries that have providers with woefully misconfigured dial plans, say, Nigeria...
But the advice to always dial calls in 'international' format is helpful.
Note most modern dialing programs (and likely all of the VoLTE-capable ones) will silently add some prefix to your calls anyway, so it's really hard to know what's going on behind the scenes. But you usually can't dial your provider's special phone numbers "as if your calls where backhauled to their network through VoIP" when you are roaming, even with VoLTE. To e.g. check voicemail you will still need to dial your provider's roaming-specific number, which will come with an international prefix.
Maybe the reason is either:
1. The phone doesn't always know the international prefix.
2. This raises the risk of accidental long-distance calls and may piss of users.
To be honest I'm surprised that phones doesn't do this automatically when you type in a local number.
Maybe phones don't necessarily know the current international prefix?
[0] Wireguard is to solve the NAT issues, make QoS predictable on different networks, and gain secure calls to home as a bonus.
> The biggest problem I foresee is a lack of QoS,
Bingo. QoS for voice is about jitter and consistency of your stream.
> I'm hoping that best effort on a lower bandwidth stream will work alright.
Lets put it this way: you don't care if your webpage loads 0.2 seconds slower. But a few random 0.2 second delay in your conversations will make them utterly, and completely unintelligible. Low QoS is something data can afford because little "sprints" of high bandwidth is good for webpages and streaming video.
But "live", and "realtime" voice communications, the jitter is just too awful.
If no one else is on the cell-tower, you might be fine. But every now and then, you'll just get completely terrible phone calls that are unusable.
VoLTE calls also have a coverage advantage to them over data. Cellular networks have different handover settings for VoLTE (QCI 1/5) where the device can hold onto its RF longer while a call is ongoing and still allow the call to work using techniques like TTI bundling. The codecs used for VoLTE require very little bandwidth and thus can still operate in extremely poor conditions.
And if you're wondering why carriers don't just offer the same for data, it's because customers using data in cell-edge cases would be disappointed with the experience even with the extra handover settings and TTI bundling. That combined with the extra PHY resources being allocated to a situation where data just might not arrive 70% of the time makes it more worth it to allocate those resources to VoLTE specifically especially when they might be critical like in E911 scenarios.
I assume there's no way to specify different QCIs for data packets or even the whole connection ? That's all specified by the closed source radio firmware?
If I'm reading things right, it implies that IMS (eg modern SMS/MMS running over IP) actually uses a different data channel that gets a higher priority? So when one is entering hostnames in say APN setup, all that traffic is going on a different channel? And thus one probably can't just enter their own server info to self-host text messages (modulo obtaining network identity/connectivity) ?
From the application layer? I don't believe so outside of the phone's native dialer/closed source firmware.
>If I'm reading things right, it implies that IMS (eg modern SMS/MMS running over IP) actually uses a different data channel that gets a higher priority?
I believe all IMS traffic is going to be higher priority regardless of if that's voice or SMS. They're both carrier-provided SIP messaging so if SMS over IMS is configured, it would use the same APN, go through the same CSCFs, and get priority. It's all the same PHY connection though. There's not a fully separate set of wireless channels for voice and data like it was in the CDMA standard where there were CDMA carriers for voice and EVDO carriers for 3G data.
You wouldn't be able to just host your own SMS though. You'd need a private APN from the network operator to do anything like that. Other systems hosted by the operator (HSS and MME) are what allow you onto the network.
Is it correct to say that IMS runs completely on/behind the locked down radio firmware, with the application processor then just getting access to an API that deals in high level "text messages" ? As opposed to the alternative where the servers I set in APN->MMSC/MMS Proxy are used directly by software on the application processor... Which I assume is not the case? And if I set MMSC to my own server, the resulting IP packets wouldn't be routed to the Internet because they're transmitted on a separate IP network from the application-processor-facing Internet access?
So barring some feature of the BP<->AP API to do so, there would be no way for software running on the AP to set various priorities on its own Internet-bound packets?
For non North Americans: the telephone networks use an international numbering plan so Canada, the US, and about 18 smaller countries use a single numbering scheme and issue area codes out of the same pool. So for me in the US dialing Canada or Bermuda is the same as dialing somewhere in the US.
It is much nicer than the international dialing system where each country has its own rules about what parts of the number are area, local exchange, etc. I wish the old ATT had designed a larger scale numbering plan that could have been worldwide and everyone could have adopted it.
(Imagine if IP addresses were different lengths and subnets were described differently based on the country of connection)
You dial a number that is +1 and looks like a normal 10 digit phone number.... and bam, you're paying $3/minute to call Canada (back when everyone charged more for Canada) or Bermuda that is still expensive I think on every carrier.
Everyone could use 10 digit dialing and have their own country codes still... it's silly that 19 countries are sitting behind +1 and that they might have a significant surcharge to call.
It’s trivial for computers. For example, using Google’s libphonenumber [0]. For example, Poland uses `000 000 000` for mobiles, and `00 000 00 00` for landlines. libphonenumber knows how to handle this [1]:
<!-- Mobile, pager and a few fixed-line numbers.
(70 numbers are formatted as per mobile numbers, based on information from some Polish people). -->
<numberFormat pattern="(\d{3})(\d{3})(\d{3})">
<leadingDigits>
21|
39|
45|
5[0137]|
6[0469]|
7[02389]|
8(?:
0[14]|
8
)
</leadingDigits>
<format>$1 $2 $3</format>
</numberFormat>
<!-- 9-digit fixed-line numbers. -->
<numberFormat pattern="(\d{2})(\d{3})(\d{2})(\d{2})">
<leadingDigits>
1[2-8]|
[2-7]|
8[1-79]|
9[145]
</leadingDigits>
<format>$1 $2 $3 $4</format>
</numberFormat>
[0]: https://github.com/google/libphonenumber
[1]: https://github.com/google/libphonenumber/blob/master/resourc...In Canada our data is stupidly expensive such that as a fairly small data user I was considering getting a PAYG "global data plan" instead of a monthly local phone plan (I don't use a local number anyways, so I just need data). And while it would be cheaper for me (and be extraordinarily cheaper when traveling) basically all of these sims have a "home" country that traffic is routed to. Not only is this slower but it also results in funny behaviour for sites that try to optimize/block users based on GeoIP.
If one of these global sim providers could do local egress I would be all over that plan.
But with 5G there is a mode for routing IP traffic directly to the internet during roaming, without sending it „home“ first. Let’s see if providers will implement that.
At&t users will feel the same pain.
I switched to TMO and a garbage unlocked Nord N200 for now
I miss my Xiaomi's cameras...