Bug #2785
closedOsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes
Added by laforge over 6 years ago. Updated almost 5 years ago.
100%
Description
OsmoHLR allows for subscriber data to be changed, but forgets to inform the VLR+SGSN about related changes (such as MSISDN, service subscription).
A quick fix is unfortunately not very simple as the ISD procedure is currently intertwined with the LocationUpdate procedure in the code :/
Related issues
Updated by laforge over 6 years ago
- Assignee set to neels
- Priority changed from Normal to High
Updated by stsp about 6 years ago
- Sends a location update sending the subscriber's initial msisdn.
- Changes the subscriber's msisdn in the HLR's database via VTY.
- Now waits and expects a communication of this new msisdn, initiated by the HLR.
The HLR runs as a gsup server loop which only responds to incoming requests from clients.
The way I understand it, to fix the problem we would need to either:
- Make the test send another location update or initiate some other GSUP communication with the HLR, and then expect to receive updated subscriber information.
- Make it possible for the HLR to initiate a new (client) connection to the VLR (server) and then send the insert subscriber data message.
Am I missing something?
Updated by neels about 6 years ago
for the record, as discussed today: the GSUP connection between {MSC,SGSN} and HLR persists, you can send messages anytime. If an {MSC,SGSN} isn't connected then per definition it is not ready to receive subscriber updates (probably down or broken).
Updated by stsp about 6 years ago
This patch fixes the external behaviour: https://gerrit.osmocom.org/7685
It may not be the perfect solution in terms of code maintainability but
already gets us one step further.
Updated by neels almost 6 years ago
- Related to Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN only added
Updated by stsp almost 6 years ago
Now waiting for review of this change: https://gerrit.osmocom.org/#/c/7992/
Updated by stsp almost 6 years ago
- Status changed from In Progress to Resolved
Above change has been merged. Closing this issue.
Updated by laforge almost 6 years ago
- Status changed from Resolved to New
I'll be reverting to the old behavior in https://gerrit.osmocom.org/#/c/osmo-hlr/+/9647, so this bug must be reopened. The new behavior was just as broken as the previuos...
Updated by neels over 5 years ago
- Related to Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLR added
Updated by neels over 5 years ago
- Assignee changed from stsp to neels
I have working patches ready on branches neels/upd_subscr (both in osmo-hlr and osmo-msc).
The remaining question is still what identification to use for GSUP clients like MSC and SGSN.
So far using the IPA_IDTAG_SERNR ('MSC-00-00-00-00-00-00') which is technically too long for the HLR db
(enlarged the storage but that is questionable).
Updated by neels over 5 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 90
Updated by neels over 5 years ago
above patch waiting for https://gerrit.osmocom.org/11232 which needs further code review, after first remarks were addressed.
Updated by neels over 5 years ago
first preparatory patch merged, now https://gerrit.osmocom.org/c/osmo-hlr/+/11233 waiting for code review.
Updated by neels almost 5 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100
