Change in osmo-msc[master]: libmsc: move subscriber expiration timer T3212 to libvlr

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/.

fixeria gerrit-no-reply at lists.osmocom.org
Thu Jan 23 23:08:36 UTC 2020


fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/16934 )

Change subject: libmsc: move subscriber expiration timer T3212 to libvlr
......................................................................


Patch Set 2:

Hi Neels,

> Possible problem here is changing the meaning of the T3212 value.
> If we use T3212 as name, I guess we should also stick to the 3GPP definition of its value.

I think after the split of OsmoNiTB it has already lost its original meaning. I personally find the current description of T3212 misleading as it may seem like we're broadcasting this value in System Information Type 3, while we do not. We could of course rename it to X3212, but do we really want to do that?

> In 3GPP specs, AFAIU, this timer number is defined to be of that weird format.

That weird format only applies to the coding of its value in SI3 message, which is quite limited in terms of its maximum size (23 octets). We already accept the values in minutes, and here we never deal with the contents of SI3, so I don't see a point in using that 'compression' for the internal state...

> b) techies setting T3212 according to spec and getting a different timeout;

Fortunately, we do not accept the value of T3212 in deci-hours, as the specs. define it ;)

> a) users moving the timer to the new vty config and not understanding the different number value (would the config change?)

Well, yeah. This magic multiplication (2 * T3212 + 1) comes from the NiTB times. However, as a user when I am setting T3212 to 30 minutes, I basically expect a subscriber to expire in 30 minutes and not in 61 (currently this transformation is opaque). That's why I am printing a warning that we're emulating the old behaviour.

> (-1 just for the typo, the rest is +0)

Nice catch! Thanks!


-- 
To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/16934
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-msc
Gerrit-Branch: master
Gerrit-Change-Id: I9b12066599a7c834a53a93acf5902d91273bc74f
Gerrit-Change-Number: 16934
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <axilirator at gmail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <axilirator at gmail.com>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Thu, 23 Jan 2020 23:08:36 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200123/5cd51743/attachment.htm>


More information about the gerrit-log mailing list