Hi all,
I was thinking about how to deal with the so called "evil twins" in the distributed hlr, and also how to have a subscriber-create-on-demand situation at the same time as a having an mslookup client.
The problem being that if we have mslookup client + fallback to create-on-demand if no HLR responds for an IMSI, we will eventually create a duplicate because the HLR that owns the IMSI is not contactable at the time of an IMSI ATTACH attempt.
Anyway, just in terms of investigating the situation on my HLRs, I added features [1] - so far, an ability to do a gsup.hlr lookup and not exit on the first age:0 - so that I can see all HLRs that respond as having the imsi in local HLR, and also to ask via mDNS for HLRs that have an IMSI, but only if it's active on that HLR, that is, it has nam_cs/nam_ps
So this is really asking about what people feel about expanding the D-GSM features in osmo-hlr, as I think it may be the case that rhizomatica/TIC are the only people that use it?
Hi Keith,
I just saw that this still had no follow-up
On Fri, Dec 16, 2022 at 01:04:35PM -0600, Keith wrote:
So this is really asking about what people feel about expanding the D-GSM features in osmo-hlr, as I think it may be the case that rhizomatica/TIC are the only people that use it?
I think in general most people indeed don't use those features. However, if your changes only affect the DGSM part, I think it makes sense to have them upstream. Otherwise there's no chance for any of us (developers, other users) to run the same code as you are. If the changes are more complex and affect larger portions of non-DGSM code, we'd have to see in review whether it makes sense to merge this to master, or not.
Regards, Harald
-
Harald Welte -
Keith