Change in osmo-hlr[master]: Add vty `reject-cause` to set the reject cause

Attention is currently required from: pespin, lynxis lazus. keith has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hlr/+/16808 ) Change subject: Add vty `reject-cause` to set the reject cause ...................................................................... Patch Set 11: (1 comment) Patchset: PS11: Hi @pespin. I my case, I was interested to see how the phones were actually behaving with the different LU Reject reasons. It seems like they don't really behave as in the spec. (TS24.008 4.4.4.7) I got bored of recompiling osmo-msc with hard coded reject causes and then I noticed this patch in CR from @lynxis. Given the patch originally almost made it through CR, and it seems like it was something that lynxis wanted at a c3 event for whatever reason, I decided to fix it up and submit a patchset. It might be interesting to know if lynxis remembers or still has any interest. From my point of view, there is one use case where I might want to configure the LU reject cause at runtime, which has to do with dGSM. If I reject an MS because no HLR responds to a distributed request for a home HLR; this may have happened because, 1) there is no home HLR or 2) the home HLR was offline/unreachable at the moment of the LUR. In the first case, I guess I would like the phone to go away and never LUR again, (at least until T3245 expires), in the second case, I might like it to try again rather soon. Now, as I said, accord the the spec i mentioned above, if I were to send a cause @2 "IMSI unknown in HLR" - which is the current default, I would expect: "The mobile station shall set the update status to ROAMING NOT ALLOWED (and store it in the SIM/USIM and delete any TMSI, stored LAI.... [etc] consider the SIM/USIM as invalid for non-GPRS services until switch-off or the SIM/USIM is removed or the timer T3245 expires as described in subclause 4.1.1.6." Howver, All the ME I tried DON'T do this, but rather they try again every 20 seconds up to 8 times and then continuously on what seems like the T3212 timer. However, with cause #13 the ME seems to NOT retry in the cell again, at least not immediately. Anyway, seems like one might like to do some trial and error with one's own situation in this and therefore being able to configure this via the vty might be "handy" (sorry for unintended bad pun, German speakers) We have some sites that don't have many phones trying to connect, we also have some that have 1000s, so on the busy site, I might prefer to set a cuase then makes them back off, at the expense of loosing the odd "orphan" "roaming" user (until they power cycles/toggle airplane mode) - whereas on the not busy site, I might set a reject cause like CONGESTION that allows that phone to keep trying in the hope their home HLR came back online. @pespin, if you'ld like any of the above in the commit msg for this patchset, please feel free to copy and paste, I also have a series of commits related to dGSM in the works, including documentation update, so I can include some of the above text there also. -- To view, visit https://gerrit.osmocom.org/c/osmo-hlr/+/16808 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-hlr Gerrit-Branch: master Gerrit-Change-Id: Icea39020c23fbbea9e92847df76af8986fdbf48a Gerrit-Change-Number: 16808 Gerrit-PatchSet: 11 Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: lynxis lazus <lynxis(a)fe80.eu> Gerrit-CC: keith <keith(a)rhizomatica.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: lynxis lazus <lynxis(a)fe80.eu> Gerrit-Comment-Date: Wed, 18 Jan 2023 20:48:32 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment