Hi,
On 9/10/25 5:06 PM, Neels Hofmeyr wrote:
So if there is too much complexity in marrying msc and sgsn to a common libosmo-vlr, I'd personally agree with adding a copy of the MSC's VLR into the SGSN and just make it work from there, without idealistic expectations on having a fully independent external library. I myself did once try to create libiu-client to share Iu interface handling between SGSN and MSC, which was a great idea in my nerdy dreams, but only held us back in practice. We've finally recently gotten rid of it.
I also already expressed the same concerns to lynxis in private. So yes, agree with keeping a separate copy for now.
The vlr in osmo-msc does try to do proper layer separation, with those vlr_ops callback functions and so on. So the vision *was* to be independent from the MSC's code. But did it work out? It would be interesting for me personally to take a closer look at the individual places that cause problems, to see the places where the MSC's VLR isn't properly separated, after all. Maybe we can even resolve those problems, but, I still think just keeping an own VLR copy in osmo-sgsn is a very good option, too. If we ever make important fixes to the VLR, copying those fixes over between SGSN and MSC, and otherwise allowing them to slightly diverge, will very likely be less work than constantly keeping both VLRs in sync. The VLR is not libosmocore...
I think sometimes what ends up being a bit convoluted regarding those abstractions is that still those are meant to be used as a synchronous/blocking API, while the real interface in the end is expected to be asynchronous (over the wire). So in the end if we ever switch to an external VLR we'd need to change the code quite a lot in order to convert those calls to be asynchronous. In that kind of events where we expect this final asynchronous behavior, for the future, we may want to implement an API eg. over libosmo-netif's osmo_prim_srv (which uses a unix socket internally) to already make the code asyncrhonous from the start.
Regards, Pau