Project

General

Profile

Feature #4307

test routing SMS-over-GSUP in DGSM

Added by neels about 2 months ago. Updated about 2 months ago.

Status:
In Progress
Priority:
High
Assignee:
Target version:
-
Start date:
12/04/2019
Due date:
% Done:

70%


Description

route an SMS via osmo-hlr directly to the target MSC and see what happens.

History

#1 Updated by neels about 2 months ago

#2 Updated by neels about 2 months ago

  • Status changed from New to In Progress
  • Assignee set to neels

#3 Updated by neels about 2 months ago

  • % Done changed from 0 to 70

SMS-over-GSUP is intended this way:
- MSC sends a SUBMIT PDU in a GSUP MO-forwardSM message to HLR
- HLR routes to SMSC
- SMSC figures out whether / when / how often to attempt delivery
- SMSC "translates" to a DELIVER PDU and sends in a GSUP MT-forwardSM message to HLR
- HLR forwards to current VLR+MSC of the recipient

(A slightly open question for me is whether the SMSC always knows the recipient's IMSI,
because a MO-forwardSM message must yield the sender's IMSI, but an MT-forwardSM must yield the recipient's IMSI)

I tested this without an SMSC. The patch might be useful to merge, but it is controversial:
osmo-hlr must be taught to translate a SUBMIT PDU into a DELIVER PDU on the fly.
If that is acceptable, osmo-hlr could route SMS between osmo-msc instances without an SMSC.
This should of course be a config item that says "off" by default.
The controversial part is that we would again teach an osmo program about SMS that is not supposed to be responsible for that.

One problem for this to work poperly is the response path: when the MT osmo-msc succeeded,
a GSUP MT-forwardSM RESULT needs to go back to the source, suddenly doesn't.
I still need to figure out whether osmo-msc omits to send one or whether osmo-hlr fails to route it to the sender.

That said, there is a profound effect of the above tests on the osmo-hlr proxy code.
I stumbled over my proxy+remote_hlr API design and uncovered that it is rather clumsy (directly gluing the two together),
and refactored the remote_hlr code so that it is also usable for SMS without home-HLR proxying.
In turn the proxy needed adjustment to work with that.
The result is actually more straightforward code paths with proper API separation.

Also found some quirks that I note-to-self'd on gerrit.
Still need to test routing response and finish up the refactored patch for gerrit.

#4 Updated by laforge about 2 months ago

On Tue, Dec 10, 2019 at 12:56:11PM +0000, neels [REDMINE] wrote:

(A slightly open question for me is whether the SMSC always knows the recipient's IMSI,
because a MO-forwardSM message must yield the sender's IMSI, but an MT-forwardSM must yield the recipient's IMSI)

In 'real' networks you have MAP SendRoutingInfoForSM for that. It is executed with MSISDN and returns the
IMSI (and the MSC (or SMS gateway) address.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)