Bug #2354: SMSC: Store&Forward not working for subscribed but unregistered MS - OsmoMSC - Open Source Mobile Communications

Actions

Copy link

Bug #2354

closed

SMSC: Store&Forward not working for subscribed but unregistered MS

Added by pespin almost 7 years ago. Updated about 6 years ago.

Status:

Resolved

Priority:

High

Assignee:

stsp

Category:

Target version:

Start date:

07/06/2017

Due date:

% Done:

90%

Resolution:

Spec Reference:

Description

The following issue is specific to the splitted NITB components (MSC, BSC, HLR, etc). Using NITB the following is handled correctly.

While writing osmo-gsm-tester smpp test to check use of Store&Forward mode, I run into the following scenario:

Core network + BTS is turned on, no MS available yet
An esme connects to the SMSC, and sends an SMS ("submit_sm" message with mode="Store&Forward") to an MS which is still not registered into the network (but it is subscribed, ie. it is on the database).
the SMSC should store the SMS and send a submit_sm_resp message with everything correct, but instead it sends an error:
```
smpplib.exceptions.PDUError: ('(11) submit_sm_resp: Invalid Destination Address', 11)
```

I asked Neels about this and here's his detailed answer on the topic:

<neels> pespin: makes sense, because in the NITB we have the HLR information in the local database. With the MSC we need to ask the HLR to know whether a subscriber exists -- and so far we do this only for location updating and authentication when the subscriber attaches.
<neels> pespin: it seems we need to either store all SMS unconditionally or add an FSM that asks the HLR whether to accept an SMS for a given number

The esme_ms_sms_storeforward.py test contains commnented code to trigger the issue. Once this is fixed, that part of the test needs to be uncommented and validated with it.

Related issues

Actions

Copy link

Updated by pespin over 6 years ago

Project changed from OsmoSMSC to OsmoMSC

I just realized this is not the correct project for this bug report, as I'm talking about the openbsc implementation here. Moving to OsmoMSC.

Actions

Copy link

Updated by laforge over 6 years ago

Priority changed from Normal to High

Actions

Copy link

Updated by laforge over 6 years ago

Assignee set to pespin

Actions

Copy link

Updated by laforge over 6 years ago

Assignee changed from pespin to stsp

Actions

Copy link

Updated by stsp about 6 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by stsp about 6 years ago

Status changed from In Progress to Resolved

Fixed with https://gerrit.osmocom.org/#/c/5997/

Actions

Copy link

Updated by pespin about 6 years ago

Status changed from Resolved to In Progress
Assignee changed from stsp to pespin

Re-opening and assigning to me as osmo-gsm-tester needs to be re-enabled.

Actions

Copy link

Updated by pespin about 6 years ago

Status changed from In Progress to Feedback
% Done changed from 0 to 90

Patch revert disabled part of the test in https://gerrit.osmocom.org/#/c/6150/

Actions

Copy link

Updated by pespin about 6 years ago

Status changed from Feedback to In Progress
Assignee changed from pespin to stsp

I merged the revert patch to re-enable the test but it seems it is still failing. In there we are using a different code path (smpp->smsc->msc->ms).

handle_smpp_submit in osmo-msc osmo-msc/src/libmsc/smpp_openbsc.c

you can find the pcap trace in https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/4966/artifact/trial-4966-run.tgz and inside that archive: run.2018-01-30_09-23-05/aoip_smpp/esme_ms_sms_storeforward.py/osmo-msc_10.42.42.6/pcap/

the ESME connected to the SMSC sends a submit_sm message to send an SMS to an MS which is in the subscriber db but didn't register yet (it's still powered off).

as a result, the SMS seems to fail and sends back error:

Frame 20: 84 bytes on wire (672 bits), 84 bytes captured (672 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 10.42.42.6, Dst: 10.42.42.1
Transmission Control Protocol, Src Port: 2775, Dst Port: 54168, Seq: 34, Ack: 290, Len: 16
Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Invalid destination address", Seq: 3, Len: 16
   Length: 16
   Operation: Submit_sm - resp (0x80000004)
   Result: Invalid destination address (0x0000000b)
   Sequence #: 3

you can see osmo-msc log in run.2018-01-30_09-23-05/aoip_smpp/esme_ms_sms_storeforward.py/osmo-msc_10.42.42.6/stderr

Important related bits:

[0;m20180130101806745 [1;34mDSMPP[0;m <000c> smpp_smsc.c:745 [esme-63594] smpp_pdu_rx(00 00 00 7d 00 00 00 04 00 00 00 00 00 00 00 02 00 01 01 36 33 35 39 34 00 01 01 36 33 35 39 35 36 33 35 39 34 00 03 00 00 00 00 00 00 00 00 47 6d 65 73 73 61 67 65 20 6e 72 2e 20 31 35 2c 20 73 6d 70 70 20 6d 65 73 73 61 67 65 20 77 69 74 68 20 77 72 6f 6e 67 20 64 65 73 74 2c 20 66 72 6f 6d 20 36 33 35 39 34 2c 20 74 6f 20 36 33 35 39 35 36 33 35 39 34 02 04 00 02 00 01 )
[0;m20180130101806745 [1;32mDSMPP[0;m <000c> smpp_smsc.c:727 [esme-63594] Rx SUBMIT-SM (6359563594/1/1)
[0;m[1;38m20180130101806745 [1;33mDLSMS[0;m[1;38m <0016> smpp_openbsc.c:109 SMPP SUBMIT-SM for unknown subscriber: 6359563594 (NPI=1)
[0;m20180130101807164 [1;34mDSMPP[0;m <000c> smpp_smsc.c:745 [esme-63594] smpp_pdu_rx(00 00 00 7b 00 00 00 04 00 00 00 00 00 00 00 03 00 01 01 36 33 35 39 34 00 01 01 36 33 35 39 35 00 03 00 00 00 00 01 00 00 00 4a 6d 65 73 73 61 67 65 20 6e 72 2e 20 31 36 2c 20 73 6d 70 70 20 73 65 6e 64 20 6e 6f 74 2d 79 65 74 2d 72 65 67 69 73 74 65 72 65 64 20 6d 65 73 73 61 67 65 2c 20 66 72 6f 6d 20 36 33 35 39 34 2c 20 74 6f 20 36 33 35 39 35 02 04 00 02 00 02 )
[0;m20180130101807164 [1;32mDSMPP[0;m <000c> smpp_smsc.c:727 [esme-63594] Rx SUBMIT-SM (63595/1/1)
[0;m[1;38m20180130101807164 [1;33mDLSMS[0;m[1;38m <0016> smpp_openbsc.c:109 SMPP SUBMIT-SM for unknown subscriber: 63595 (NPI=1)

so it seems the error message comes from function "submit_to_sms"

Actions

Copy link

#10