Attention is currently required from: laforge, neels, pespin.
fixeria has posted comments on this change. (
https://gerrit.osmocom.org/c/osmo-msc/+/36760?usp=email )
Change subject: libmsc: add X5 timer for delaying LU transactions
......................................................................
Patch Set 3:
(2 comments)
Patchset:
PS2:
But how is the program on the other side of GSUP
supposed to know it may want to test sending SMS for that subscriber? do you mind
explaining? I think it's good to have it here. There's some sort of event
"Location Updated" sent there? (I guess to the HLR in this case?)
"Welcome SMS": keep in mind that it was just a guess from my side. It should be
possible to get an LU event notification over the CTRL interface, for instance, but I
don't think this is implemented currently.
The customer mentioned in the ticket that they simply want to optimize delivery of MT SMS
queued in their SMSC by re-using the existing RR connection. So imagine there is a pending
MT SMS for a subscriber, which is "offline" (detached).
The SMSC does not (and is not supposed to) know whether the recipient subscriber is
"online" or not, so it would attempt to perform MT SMS delivery first. The MSC
would either respond with an error immediately, knowing that the subscriber is explicitly
detached, or try to page the subscriber and respond with an error on timeout.
If MT SMS delivery fails due to unavailability of the recipient, the SMSC is supposed to
wait for the `readyForSM` notification from the MSC. The MSC is expected to send such a
notification when the subscriber is back "online" by performing Location
Updating procedure. But not unconditionally!
The VLR/MSC (and HLR too, AFAIR) needs to maintain the `MNRF (MS Not Reachable Flag)` for
each subscriber. This flag is set when MT SMS delivery fails, and this flag triggers
sending of the `readyForSM` notification. Unfortunately, this is not fully implemented in
osmo-msc.
So this is how (in general) the external SMSC entity is supposed to know that it can
attempt to deliver a MT SMS again. Regardless of the state of the `MNRF` in osmo-msc, this
new X5 timer is still useful since it allows to accomodate for non-zero link delay between
the MSC and an SMSC. This timer will play well with the `MNRF`, if we ever will have a
chance to implement it properly.
File src/libmsc/msc_a.c:
https://gerrit.osmocom.org/c/osmo-msc/+/36760/comment/202c0f8d_dc40a7b5
PS2, Line 192: osmo_timer_schedule(&msc_a->lu_delay_timer, Tval, 0);
Yes that's for sure true during the usual
operation. […]
Done
--
To view, visit
https://gerrit.osmocom.org/c/osmo-msc/+/36760?usp=email
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: Ic519cab55d65e47b2636124427dab1a1d80fab78
Gerrit-Change-Number: 36760
Gerrit-PatchSet: 3
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Thu, 16 May 2024 06:09:22 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment