> 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?