Change in osmo-msc[master]: MT-forwardSM Message Reference fix.

Vadim Yanitskiy gerrit-no-reply at
Sun Mar 31 10:23:06 UTC 2019

Vadim Yanitskiy has posted comments on this change. ( )

Change subject: MT-forwardSM Message Reference fix.

Patch Set 1: Code-Review-2


Unfortunately, SM-RP-MR negotiation for MT SMS is still a weak side of the current implementation. In case of MO SMS, the MS is choosing SM-RP-MR (message reference) itself. In case of MT SMS, the situation is a bit more complex.

In commercial networks, the SMSC is not involved in SM-RP-MR allocation - it just establishes a TCAP connection to the MSC, ensuring unique InvokeID values for each MT SMS being forwarded within this connection. The MSC, in it's turn, is responsible for mapping between TCAP/InvokeID and SM-RP-MR.

In our case, TCAP/MAP is replaced by GSUP. There is no such thing like context or InvokeID in GSUP. For SS/USSD, we do emulate TCAP context using auxiliary session state and session ID IEs. For SMS, it was decided to avoid using them and expose SM-RP-MR, so it's something like InvokeID in TCAP/MAP.

This decision do come at a price. The SMSC (or any other entity sending MT SMS over GSUP) needs to guess a unique SM-RP-MR value, that isn't used on RAN yet. Only OsmoMSC can properly do this, because it knows about all SMS transactions of a subscriber and the corresponding SM-RP-MR values in use.

The proposed solution (this change) at first looked good to me, until I started to think about its corner cases... As I already noted, your change breaks MO SMS, because OsmoMSC would ignore SM-RP-MR value chosen by MS, and always send 0x00 towards the SMSC. Even if it wouldn't break MO SMS, there is still a risk of collision: imagine SMSC initiating a MT SMS with e.g. 0xde, and at the same time the same subscriber initiates MO SMS with 0xde! This would result in an unexpected behaviour as on the SMSC's side, as on the subscriber's side. Finally, we would lose a possibility to verify the MT SM-RP-MR allocation for our TTCN-3 test cases.

Currently, the SMSC is recommended to choose any spare SM-RP-MR value (e.g. 0xff), and leave it up to the MSC. OsmoMSC would assign a proper SM-RP-MR value, and use it in the response to MT SMS, i.e. OSMO_GSUP_MSGT_MT_FORWARD_SM_RESULT (triggered by RP-ACK from MS) or OSMO_GSUP_MSGT_MT_FORWARD_SM_ERROR (triggered by RP-ERROR from MS). Until there are two or more MT SMS transmissions per subscriber, the correlation is not a problem. Otherwise, one can use the session state and session ID IEs as we do for SS/USSD.

In any case, I am open for the further discussion.
File src/libmsc/gsm_04_11.c:
PS1, Line 803: trans->sms.msg_ref_gsup
This would break MO SMS, because sms.msg_ref_gsup is only initialized in case of MT SMS.
PS1, Line 844: trans->sms.msg_ref_gsup
Same here.

To view, visit
To unsubscribe, or for help writing mail filters, visit

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Ia50fd0e6c7ba7876522f49a00c55f8499c164331
Gerrit-Change-Number: 13464
Gerrit-PatchSet: 1
Gerrit-Owner: Mykola Shchetinin <mykola at>
Gerrit-Assignee: fixeria <axilirator at>
Gerrit-Reviewer: Harald Welte <laforge at>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Vadim Yanitskiy <axilirator at>
Gerrit-CC: fixeria <axilirator at>
Gerrit-Comment-Date: Sun, 31 Mar 2019 10:23:06 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: Yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gerrit-log mailing list