Age | Commit message (Collapse) | Author | Files | Lines |
|
It may happen that either the MS or an ESME would become
unresponsive, e.g. due to a bug, or a dropped message.
This is why we have SS session timeout, that prevents
keeping 'stalled' sessions forever.
Let's introduce a VTY option, which can be used to configure
this timer (by default it's set to 30 seconds):
hlr
...
! Use 0 to disable this timer
ncss-guard-timeout 30
Change-Id: I971fc2cee6fd46d4d5d6dac6c634e0b22fff183d
Related: OS#3717
|
|
Change-Id: I70a5c7c83c2356b779fb1ea7ffe07ccc1e279c22
|
|
Change-Id: I2b9485be08c6cbf188ed1f4059ff28ab65c61dbf
|
|
Change-Id: Iba9470e11af2f2609486b9b0b6bfa3207b883a3a
|
|
There are some requests that are best served inside the HLR, as it
has access to subscriber information such as MSISDN and IMSI.
This unfortunately required quite some restructuring of the USSD
related structures including the VTY syntax for adding routes.
The default config file has been updated to replicate the *#100#
built-in behavior of old OsmoNITB.
Closes: OS#2566
Change-Id: I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9
|
|
We don't want any SS session to run for more than 30s. The timeout
is currently not refreshed.
If we need more comprehensive timeout handling, using osmo_fsm for SS
sessions might make sense.
Change-Id: I5c9fb6b619402d2a23fea9db99590143d85ac11a
|
|
Change-Id: I3cfd7cd401ea32b7e92f1124d129099d9f7dc6e6
|