Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

fixeria, do you have plans for this already?

Hi neels,

fixeria, do you have plans for this already?

Actually, I was (and most likely am) not going to work on this part.
This code was written by Harald, while I have no any experience with
such identities... So, unassigning.

osmith can you please have a look at this?
The MSC-00-00... is related to the MSC's IPA unit name, the same that we use in GSUP for routing.

Question 1:
What parts are affected by this? In other words, does current MO USSD work, i.e. can I have a custom osmo-msc IPA name and can still do *#100# successfully?
If only some rarely used part of USSD is broken by this, then this issue is not of such high priority.

If all USSD routing back to the MS is broken by this, then this "blocks" inter-MSC handover in such a way that
as soon as two distinct osmo-msc are connected to the same osmo-hlr, only one named "MSC-00-00..." will get the USSD replies and we urgently need to fix this.
(AFAICT USSD worked out fine with custom MSC IPA names in the ttcn3 tests, so my guess is this is not so urgent...)

In other words, does current MO USSD work, i.e. can I have a custom osmo-msc IPA name and can still do *#100# successfully?

I've built current master of everything, set a different ipa-name in osmo-msc.cfg, and *#100# does not work anymore (see HLR log below). When removing ipa-name, it works as expected again.

20190401161902202 DSS DEBUG 901700000024461/0x20000002: Process SS (BEGIN) (hlr_ussd.c:476)
20190401161902202 DSS DEBUG Found IUSE 'own-msisdn' (prefix '*#100#') for USSD Code '*#100#' (hlr_ussd.c:132)
20190401161902202 DSS INFO 901700000024461/0x20000002: USSD CompType=Invoke, OpCode=ProcessUssReq '*#100#' (hlr_ussd.c:423)
20190401161902202 DSS INFO 901700000024461/0x20000002: Tx USSD 'Your extension is 101' (hlr_ussd.c:276)
20190401161902202 DLGSUP DEBUG Cannot find route for addr MSC-00-00-00-00-00-00 (gsup_send.c:38)
20190401161906669 DLINP DEBUG connected read/write (ipa.c:390)
20190401161906669 DLINP DEBUG 127.0.0.1:53634 message received (ipa.c:346)
20190401161907024 DLINP DEBUG connected read/write (ipa.c:390)
20190401161907024 DLINP DEBUG 127.0.0.1:53636 message received (ipa.c:346)
20190401161926670 DLINP DEBUG connected read/write (ipa.c:390)
20190401161926670 DLINP DEBUG 127.0.0.1:53634 message received (ipa.c:346)
20190401161927025 DLINP DEBUG connected read/write (ipa.c:390)
20190401161927026 DLINP DEBUG 127.0.0.1:53636 message received (ipa.c:346)
20190401161932203 DLINP DEBUG connected read/write (ipa.c:390)
20190401161932204 DLINP DEBUG 127.0.0.1:53636 message received (ipa.c:346)
20190401161932204 DSS NOTICE 901700000024461/0x20000002: Process SS ERROR (END) (hlr_ussd.c:584)

Oh, didn't realize you are already on this. Sorry for stealing, but
while I had a setup of two MSC, trying to figure out which phone had which number, I was annoyed by this not working and fixed it.
Please see https://gerrit.osmocom.org/#/c/osmo-hlr/+/13479 as a proposal.

osmith, I notice there are still routing problems in my patch, especially for error handling. Take a look in the gerrit review, maybe you can continue with this?
(still route MT USSD by IMSI and vlr_number from the db, but, for MO USSD we can use the VLR number of whoever sent the request, which might be necessary for errors where we can't find the IMSI or a valid vlr_number)

neels, is this the right approach? https://gerrit.osmocom.org/#/c/osmo-hlr/+/13515/