Hacker News Reader

Comment by mindslight | Hacker News Reader

Tangentially related, does anybody have experience with libre SIP over LTE (eg native Android VoIP dialer)? With the partial 4G shutdown in the US, I'm reluctant to buy a new pocket communicator. LTE data continues to work just fine, and I've already got an Asterisk setup for my home phones. VoLTE seems like it's doing the exact same thing just with the carrier's blessing, and the less proprietary crap in my life the better. My current plan is to try out SIP over wireguard [0] over LTE, and see how that treats me. The biggest problem I foresee is a lack of QoS, but given that carriers' main concern seems to be streaming video, I'm hoping that best effort on a lower bandwidth stream will work alright.

[0] Wireguard is to solve the NAT issues, make QoS predictable on different networks, and gain secure calls to home as a bonus.

View on HN

I had a friend try VoIP on a dataplan a few years ago.

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

I've been using SIP on my Android phone for a couple of months now, and QoS hasn't been an issue at all. I'm using Voip.ms so I can have SMS and MMS. There's a SMS app but it doesn't support MMS; MMS messages are emailed to me and I just log on the Voip.ms portal and message there. I use Linphone as the client, and Strongswan for VPN.

The main difference VoLTE provides is preferential network access for voice calls. In times of congestion, voice calls will still work when data might not.

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 knew there would be some layer cross-cutting prioritization. It's interesting to hear the exact details.

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

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

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.

Thank you for the reply! I'm trying to tease out what the limits of code on the application processor can do. By "data channel", I meant logical IP 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?

I strongly recommend https://jmp.chat with their Cheogram app. Almost perfect mobile replacement.

the biggest issue i ran into when trying voip with a cell phone is lack of functioning mms (and therefore also group sms). that ended up being the dealbreaker.

Check out https://jmp.chat with their Cheogram app. It supports everything you want.

Reply on news.ycombinator.com