[OpenSIPS-Users] SST module dialog lifetime update problem

[Pyle, Jeff]

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 <users-bounces at lists.opensips.org> on behalf of Pyle, Jeff <JPyle at fusionconnect.com>
Sent: Friday, January 13, 2023 10:56
To: users at lists.opensips.org <users at lists.opensips.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230113/2d728eff/attachment-0001.html>