hlr_ussd.c hardcodes "MSC-00-00-00-00-00-00" twice
hlr_ussd.c in two places has a hardcoded MSC identity of "MSC-00-00-00-00-00-00", which we should get rid of as soon as possible.
Related: for inter-MSC handover, the MSC identification must become configurable, and will certainly not remain the above.
As soon as we do that, hlr_ussd.c will break, IIUC.
#5 Updated by neels about 2 years ago
- Assignee set to osmith
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.
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...)
#7 Updated by osmith about 2 years ago
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)
#8 Updated by neels about 2 years ago
- Assignee changed from osmith to neels
- % Done changed from 0 to 90
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.
#9 Updated by neels about 2 years ago
- Assignee changed from neels to osmith
- % Done changed from 90 to 60
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)