OsmoHLR doesn't update VLR during UpdateLocation
For some reason, the VLR column in the HLR table is not updated when a subscriber performs an Update Location procedure.
#1 Updated by neels about 1 year ago
What should go in the VLR column? We have the IPAC_IDTAG_SERNR producing something like "SGSN-00-00-00-00-00-00" and "MSC-00-00-00-00-00-00". The HLR also has sgsn_number and sgsn_address columns, could be set to the same / to the remote GSUP client address, by switching on osmo_gsup_message.cn_domain...
#3 Updated by laforge about 1 year ago
In a real 3GPP HLR with MAP, it's the global title of the respective VLR which is stored.
For us, it is "any other unique identifier of the VLR", and I think it hasn't been specified yet so far.
I'm against using the IP address, as this will break all kinds of dynamic address or NAT scenarios (which currently work as GSUP is a strict client->server protocol).
IDTAG_SERNR might be an idea, maybe also some other IDTAG? We should make it user-configurable then to ensure multiple MSCs have differnet identifiers.
With the next C3 approaching, I took a look at this again.
I have a patch that stores the IPAC_IDTAG_SERNR for VLR and SGSN number in the HLR database.
The only problem is that this vlr_number is specified as 15 digits max,
while the MSC and SGSN currently send e.g. 'MSC-00-00-00-00-00-00' -- that's 21 characters.
So the current patch says "skipping 'MSC-00-00-00-00-00-00' != 'MSC-00-00-00-00'" -- mismatch because the id is truncated on its round trip through struct hlr_subscriber and the database.
Would it be a bad idea to just make the vlr_number and sgsn_number fields in hlr_subscriber longer? They are currently limited by GT_MAX_DIGITS, which makes sense if it really were a Global Title. But all it would take is to enlarge the vlr_number and sgsn_number storage in struct hlr_subscriber.
DB wise, SQLite db bootstrapping gives a length indication of VARCHAR, but in fact this is just an optional indicator, and SQLite happily stores any length of string without modifications.
Another idea would be to strip the dashes, because MSC000000000000 is exactly 15 digits.
None of this is really nice though. Any ideas? Does it need to be nice?
I think the key aspect here is that the storage is completely transparent and
can store either ACII or binary data. global titles have no good/standard ASCII
representation, as they include tons of fields like NPI, TON, which are meta-data
next to the actual digits of the 'phone number'.
OsmoHLR should ideally treat this address as an opaqua block and not attempt to
interpret its content, assume it's ASCII or follows any specific format. It's just
something the VLR and SGSN specify during IPA CCM, and which is stored in the database
and used to route later requests to that given VLR or SGSN.
Having said that, we can of course increase the size of the field in the database.