The INVITE that comes into the proxy contains the following:
Supported: timer,100rel,precondition,replaces
Session-Expires: 1800
Min-SE: 90
The subsequent 200 OK contains the following:
Require: timer
Supported: timer,replaces
Session-Expires: 1800;refresher=uac
I would expect the SST module to set the dialog's lifetime to 1800 seconds, but
that's not what happens.
The module configuration looks like this now:
loadmodule "sst.so"
modparam("sst", "min_se", 30)
modparam("sst", "sst_interval", 3600)
modparam("sst", "sst_flag", "SST_FLAG")
Without the sst_interval option, the dialogs' timeouts are 30 seconds from
creation. With the sst_interval option, they're 3600 seconds, and they update
to 3600 seconds in the future whenever a re-INVITE comes through (session
refresh, call hold, whatever) regardless of the Session-Expires passing
through. That doesn't seem right.
- Jeff
________________________________
From: Users <[email protected]> on behalf of Pyle, Jeff
<[email protected]>
Sent: Friday, January 13, 2023 10:56
To: [email protected] <[email protected]>
Subject: [OpenSIPS-Users] SST module dialog lifetime update problem
Hello,
This is on 3.2.10-1 installed via the Debian repo at apt.opensips.org.
I have a simple stateful proxy with dialog support routing a call from one side
to the other. Both the UAC and UAS have full session timer support. The INVITE
arrives at the proxy with Min-SE: 90 and Session-Expires: 1800. OpenSIPS' sst
module has min_se=90. The dialog is created and the SST flag is set. The first
problem is the dialog lifetime is always set to the sst module's configured
min_se value regardless of the Session-Expires value in the message. Is this a
bug, or am I doing something wrong?
Just for testing I increased the sst module's min_se to 1801, greater than the
Session-Expires from the message. Looking at sst_handlers.c around line 300,
this should send be handled a few different ways depending on various factors,
but instead the process segfaults.
Something seems unhappy here. Perhaps the two problems are related.
- Jeff
This message is subject to Fusion Connect, Inc.'s email communication policy:
www.fusionconnect.com/email-policy
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
