SS/USSD: fix: properly (re)schedule NCSS session timeout
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.
For some reason, it wasn't properly resceduled in case of
subsequent SS/USSD activity, so the lifetime of a session
was limited. Let's properly (re)schedule it.
Change-Id: I11aeacf012b06d3d0b5cc6e64baecf857b645fda
Related: OS#3717
diff --git a/src/hlr_ussd.c b/src/hlr_ussd.c
index 16a197c..cc6aa8a 100644
--- a/src/hlr_ussd.c
+++ b/src/hlr_ussd.c
@@ -208,10 +208,9 @@
OSMO_STRLCPY_ARRAY(ss->imsi, imsi);
ss->session_id = session_id;
+
+ /* Schedule self-destruction timer */
osmo_timer_setup(&ss->timeout, ss_session_timeout, ss);
- /* NOTE: The timeout is currently not refreshed with subsequent messages
- * within the SS/USSD session. So X seconds after the initial SS message,
- * the session will timeout! */
if (g_hlr->ncss_guard_timeout > 0)
osmo_timer_schedule(&ss->timeout, g_hlr->ncss_guard_timeout, 0);
@@ -538,6 +537,11 @@
gsup->imsi, gsup->session_id);
goto out_err;
}
+
+ /* Reschedule self-destruction timer */
+ if (g_hlr->ncss_guard_timeout > 0)
+ osmo_timer_schedule(&ss->timeout, g_hlr->ncss_guard_timeout, 0);
+
if (ss_op_is_ussd(req.opcode)) {
/* dispatch unstructured SS to routing */
handle_ussd(conn, ss, gsup, &req);