Hi Neels,
On Tue, Oct 10, 2017 at 03:12:37PM +0000, neels [REDMINE] wrote:
Say the operator changes the subscriber's MSISDN in the HLR database,
the MSC may still maintain the old MSISDN in the VLR memory. If
possible, we should tell the VLR about the change.
correct. An "insert subscriber data" is required to update the data in
the serving VLR + serving SGSN.
We could send out notifications to all connected GSUP clients.
I don't think this is a good idea, as (at least with normal MAP
semantics) it would create the subscriber record in all VLRs/SGSNs
unconditionally. I would'nt want to create a "update only, don't
create" flag, as that doesn't exist in MAP semantics.
In fact, the message should only be sent to the current serving VLR +
serving SGSN, which the HLR should be tracking anyway (in order to be
able to route incoming MT-SMS/calls to the right VLR).
But what if there are bulk changes?
Like changing every subscribers phone number? I think that's somewhat
unlikely? I don't think we should have to care about this now.
Or are you referring to changing 6 parameters of a single subscriber,
and you want to avoid 6 consecutive insert subscriber data?
In that case one might prefer to wait for the next full location
updating instead...
I wouldn't want us to spend too much time worrying about this at the
moment. It's unclear if (e.g. in the context of LTE support), we'd be
phasing out OsmoHLR in favor of a GPUP-to-DIAMETER translator and a
DIAMETER capable HSS. Community Cellular Manager is using their own
python GSUP server, too.
For sure, we should track and document known limitations, but before
taking action we have to think about how far we want to take OsmoHLR in
its current form. This is an open discussion.
