This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Vadim Yanitskiy gerrit-no-reply at lists.osmocom.orgVadim Yanitskiy has posted comments on this change. ( https://gerrit.osmocom.org/13464 ) Change subject: MT-forwardSM Message Reference fix. ...................................................................... Patch Set 1: Code-Review-2 (2 comments) 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. https://gerrit.osmocom.org/#/c/13464/1/src/libmsc/gsm_04_11.c File src/libmsc/gsm_04_11.c: https://gerrit.osmocom.org/#/c/13464/1/src/libmsc/gsm_04_11.c@803 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. https://gerrit.osmocom.org/#/c/13464/1/src/libmsc/gsm_04_11.c@844 PS1, Line 844: trans->sms.msg_ref_gsup Same here. -- To view, visit https://gerrit.osmocom.org/13464 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings 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 pentonet.com> Gerrit-Assignee: fixeria <axilirator at gmail.com> Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org> Gerrit-Reviewer: Jenkins Builder (1000002) Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com> Gerrit-CC: fixeria <axilirator at gmail.com> 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: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190331/dc3a3c4d/attachment.htm>