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 <[email protected]> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: laforge <[email protected]> Gerrit-Reviewer: neels <[email protected]> Gerrit-Reviewer: pespin <[email protected]> Gerrit-Attention: neels <[email protected]> Gerrit-Attention: laforge <[email protected]> Gerrit-Attention: pespin <[email protected]> Gerrit-Comment-Date: Thu, 16 May 2024 06:09:22 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <[email protected]> Comment-In-Reply-To: pespin <[email protected]> Comment-In-Reply-To: fixeria <[email protected]> Gerrit-MessageType: comment
