11 May
2024
11 May
'24
1:11 p.m.
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 <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: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Sat, 11 May 2024 11:11:43 +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>
Gerrit-MessageType: comment