Project

General

Profile

Actions

Bug #3710

closed

hlr_ussd.c hardcodes "MSC-00-00-00-00-00-00" twice

Added by neels over 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
11/26/2018
Due date:
% Done:

100%

Spec Reference:

Description

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.


Related issues

Related to OsmoMSC - Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCMResolvedstsp06/23/2018

Actions
Related to OsmoMSC - Feature #3618: Inter-MSC hand-over supportResolvedneels10/02/2018

Actions
Actions #1

Updated by neels over 5 years ago

  • Related to Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCM added
Actions #2

Updated by neels over 5 years ago

Actions #3

Updated by neels over 5 years ago

  • Status changed from New to Feedback
  • Assignee set to fixeria
  • Priority changed from Normal to High

fixeria, do you have plans for this already?

Actions #4

Updated by fixeria over 5 years ago

  • Assignee deleted (fixeria)

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.

Actions #5

Updated by neels almost 5 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.

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...)

Actions #6

Updated by osmith almost 5 years ago

  • Status changed from Feedback to In Progress
Actions #7

Updated by osmith almost 5 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)

Actions #8

Updated by neels almost 5 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.

Actions #9

Updated by neels almost 5 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)

Actions #10

Updated by osmith almost 5 years ago

Actions #11

Updated by osmith almost 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 60 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)