Project

General

Profile

Actions

Feature #4307

closed

test routing SMS-over-GSUP in DGSM

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

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

100%

Spec Reference:

Description

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

Actions #1

Updated by neels over 4 years ago

Actions #2

Updated by neels over 4 years ago

  • Status changed from New to In Progress
  • Assignee set to neels
Actions #3

Updated by neels over 4 years 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.

Actions #4

Updated by laforge over 4 years 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.

Actions #5

Updated by neels almost 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 70 to 100

I was able to successfully route SMS over GSUP between MSCs with the code "parked" in osmo-hlr.git branch neels/sms-over-gsup and osmo-msc.git branch neels/sms_over_gsup .
As explained above, this was not using an external SMSC entity but did the SMS PDU mangling in osmo-hlr to transform a SUBMIT PDU to a DELIVER PDU.
The aim of this issue was to test whether DGSM is able to allow SMS routing over GSUP.

So even though the code to route SMS via osmo-hlr itself is not merged and may not be merged ever (not clear at this point), this issue itself can be closed:

  • If we really want to merge patches that allow SMS routing via GSUP without an SMSC, we should create a separate issue.
  • Some osmo-msc patches from above branch are general fixes and should probably be merged, but that is unrelated to the question whether DGSM allows SMS routing.
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)