PHphh·Jan 22, 2025
In Using eSIMs with devices that only have a physical SIM slot via a 9eSIM SIM carphhusson
ims
Kotlin2023–2025
phhusson / ims
ims
Discover this repository through its Hacker News conversations.
2Distinct people
4Mentions
0Explicit recommenders
185GitHub stars
What to know before exploring
What it is
A public description has not been verified.
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month4 dated mentions
Observed mentions: 2023-07-20 13:41:57 UTC to 2025-01-22 17:28:03 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Jul 2023 | 2023-07-01 00:00:00 UTC | 2023-08-01 00:00:00 UTC | 2 | 0 | 2 |
| Aug 2023 | 2023-08-01 00:00:00 UTC | 2023-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2023 | 2023-09-01 00:00:00 UTC | 2023-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2023 | 2023-10-01 00:00:00 UTC | 2023-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2023 | 2023-11-01 00:00:00 UTC | 2023-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2023 | 2023-12-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| Jan 2024 | 2024-01-01 00:00:00 UTC | 2024-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2024 | 2024-02-01 00:00:00 UTC | 2024-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2024 | 2024-03-01 00:00:00 UTC | 2024-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2024 | 2024-04-01 00:00:00 UTC | 2024-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2024 | 2024-05-01 00:00:00 UTC | 2024-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2024 | 2024-06-01 00:00:00 UTC | 2024-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2024 | 2024-07-01 00:00:00 UTC | 2024-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2024 | 2024-08-01 00:00:00 UTC | 2024-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2024 | 2024-09-01 00:00:00 UTC | 2024-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2024 | 2024-10-01 00:00:00 UTC | 2024-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2024 | 2024-11-01 00:00:00 UTC | 2024-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2024 | 2024-12-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2025 | 2025-01-01 00:00:00 UTC | 2025-02-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
4 sourcesI'd rather say the issue is NOT that basebands need hardening (ok they do need it), but that we should stop putting things there.
The article mentions parsing XML, doing DNS, IMS, TCP and IP stacks. As far as I know, all of those are down for one single purpose which is VoLTE (And VoWifi, and other related features which all go under the umbrella of "IMS"). On top of that, they also need to do IPSec (should be pretty safe) and SIP (gosh wait too much string handling). The remote Pixel security flaw few months ago was in that VoLTE stack.
This stack should NOT be in an embedded closed source un-auditable system. It should be in a "dumb" sandboxed opensource app in a sandboxed language.
This is exactly what I'm doing: https://github.com/phhusson/ims This is a FLOSS VoLTE + VoWifi[1] implementation for Android written in kotlin with no nativ
Read the rest
e code [2].
I'm not recommending it for anyone (I managed to make my first outgoing call with it yesterday), it has real issues (you do want baseband cooperation on various parts, like QoS or roaming to 3G, which I'm choosing to ignore), but I think software IMS is the way of the future.
In addition to security, this allows for a lot of de-obsoleting:
- It helps *a lot* for custom Android ROMs, and compatibility with annoying carriers
- I can integrate top-notch audio codecs (EVS) without breaking a sweat, and deployed for everyone in a jiffy (heck I don't even to reboot user's smartphone's to apply the change, I can just deploy it over Play Store)
- I can integrate modern voice improvements
- I can enable VoWifi on 3G smartphones (Granted, I'm not sure that's extremely useful)
- I can enable features that didn't exist when that smartphone model got released like Cross-Sim VoWifi (you have your french main SIM, you're in the US with a local eSIM, you can do VoWifi of the french SIM over the local eSIM to have cheap 4G voice calls)
I see some movement in AOSP source code that make me think Google will release an opensource IMS within two years, so I'm hopeful my work will be able to go to the trash.
[1] I'm kinda cheating for the wifi part, because it's provided by AOSP, I barely lifted the little finger to enable it.
[2] Okay, I added rnnoise for the sake of having a denoising, but it's fixed-size-data-in fixed-size-data-out, so I feel safe there.
PS: I know that my knowledge of 3GPP is pretty thin, so if knowledgeable people want to tell me which parts will still need to remain in modem, I'm curious.
PS2: I'm putting this just in case: For GNU/Linux smartphones (or desktops with SIM card reader), you should be able to use that C+py stack to have userspace vowifi: https://github.com/phhusson/doubango
I hope that someday we will be able to use VoLTE on a Samsung device with an Android OS like LineageOS, /e/OS, etc.
phh ( https://github.com/phhusson/ims , see his comment on this post) and martinetd ( https://github.com/martinetd/android_ims/branches ) are working on this for some time.
In Open Source IMS ClientContext: IMS means VoLTE + VoWifi (+ other stuff), which is how you do calls and SMS over LTE, which is mostly "just" SIP
This move of Voice and SMS to an IP protocol is IMO pretty interesting for opensource community because it means we can largely reduce the footprint of the modem to "just" giving IP connections.
The main contributors to opensource IMS client should to be "secure smartphones", long before people doing "let me opensource my baseband", because running a super-privileged SIP client is very dangerous (even Pixels, no matter the OS, got security flaws in it few months ago), but that's clearly not what I'm seeing. (There are also other security considerations justifying an opensource IMS client, like forcing the encryption of VoLTE)
As someone who spend a lot of time making an Android opensource IMS client ( https://github.co
Read the rest
m/phhusson/ims ), this wiki page isn't really news: I've had this setup (Doubango IMS client, which is a C embedded-leaning opensource client + VoWifi tunnel) running on my desktop using an Android smartphone as a SIM card reader more than a year ago ( https://github.com/phhusson/doubango/blob/master/README-phh ), which is well, just the same age as that wiki page. Except that I've been using it over real carriers, not just software ones.
If someone has some time to spend on it, for GNU/Linux smartphones, Doubango IMS client should be pretty straightforward to get to work, what's missing is "only" plumbing.
Either way, if the people who are working on that are here, please say hi so we can share our war stories :-)