<p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">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.</p><p style="white-space: pre-wrap; word-wrap: break-word;">In any case, I am open for the further discussion.</p><p>Patch set 1:<span style="border-radius: 3px; display: inline-block; margin: 0 2px; padding: 4px;background-color: #ffd4d4;">Code-Review -2</span></p><p><a href="https://gerrit.osmocom.org/13464">View Change</a></p><p>2 comments:</p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0;"><p><a href="https://gerrit.osmocom.org/#/c/13464/1/src/libmsc/gsm_04_11.c">File src/libmsc/gsm_04_11.c:</a></p><ul style="list-style: none; padding: 0;"><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/13464/1/src/libmsc/gsm_04_11.c@803">Patch Set #1, Line 803:</a> <code style="font-family:monospace,monospace">trans->sms.msg_ref_gsup</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">This would break MO SMS, because sms.msg_ref_gsup is only initialized in case of MT SMS.</p></li><li style="margin: 0; padding: 0 0 0 16px;"><p style="margin-bottom: 4px;"><a href="https://gerrit.osmocom.org/#/c/13464/1/src/libmsc/gsm_04_11.c@844">Patch Set #1, Line 844:</a> <code style="font-family:monospace,monospace">trans->sms.msg_ref_gsup</code></p><p style="white-space: pre-wrap; word-wrap: break-word;">Same here.</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.osmocom.org/13464">change 13464</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.osmocom.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.osmocom.org/13464"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: osmo-msc </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: Ia50fd0e6c7ba7876522f49a00c55f8499c164331 </div>
<div style="display:none"> Gerrit-Change-Number: 13464 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Mykola Shchetinin <mykola@pentonet.com> </div>
<div style="display:none"> Gerrit-Assignee: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Reviewer: Harald Welte <laforge@gnumonks.org> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins Builder (1000002) </div>
<div style="display:none"> Gerrit-Reviewer: Vadim Yanitskiy <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-CC: fixeria <axilirator@gmail.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Sun, 31 Mar 2019 10:23:06 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>
<div style="display:none"> Gerrit-HasLabels: Yes </div>