Attention is currently required from: 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 2: (1 comment) Patchset: PS2: There is definitely some confusion here. The commit message clearly states MT SMS over GSUP, which is not using the MSC's internal SMSC. The customer explicitly requested to implement this delay for the SMS over GSUP user case. Neels: what you're describing applies to the MSC's built-in SMSC. It already does deliver MT SMS just fine using the existing LU transaction (grep for `S_SUBSCR_ATTACHED`). And yes, we do check the SMS queue before put()ing the LU token. However things get a bit more complicated when using SMS over GSUP, i.e. external 3rd party SMSC. You cannot know in advance if there is pending SMS for a subscriber, and you cannot query that asynchronously because there exists no primitive for that. This is why we're adding this delay: to give the external SMSC a bit more time to deliver MT SMS, which can be sent over the existing RR connection. I did not ask the customer why or for what they want to optimize delivery of MT SMS during Location Updating, but I can imagine a use case of sending "welcome SMS" to newly registered subscribers. > Re Pau's remark, if you keep this patch with the timer delay instead of > running the SMS queue like I am suggesting, some of msc_a_fsm_cleanup() or > trans_free() should osmo_timer_del() the timer, to make very sure that the > timer cb does not try to access a freed pointer. Oh, I get the point now. Will update the patch. > (A consideration: if we ever remove the SMS queue implementation from > osmo-msc to a separate SMSC, there should be some async operation to ask for > a pending SMS before releasing a conn. [...] AFAIK, there exists no such primitive/procedure in MAP protocol. We want to keep GSUP as close as possible to MAP, so I don't think we should be adding this. There is a concept of `readyForSM`, when after an unsuccessful MT SMS delivery attempt (e.g. subscriber was not present, did not respond to paging) the MSC/VLR sets `MNRF` flag and then sends this primitive when subscriber is back online. But this is a different thing. > I guess that's well under 5 seconds or alike in usual case? You both keep mentioning this, not sure where this 5 seconds comes from. It's a configurable value, which is expected to be set to accomodate for delay between the MSC and the external SMSC. The exact value may vary depending on the expected delay between CNI components. I am even considering to allow using milliseconds instead of seconds. -- 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: 2 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: pespin <[email protected]> Gerrit-Comment-Date: Sat, 11 May 2024 11:11:43 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <[email protected]> Comment-In-Reply-To: pespin <[email protected]> Gerrit-MessageType: comment
