While SST module is activated, dialogs still use default timeouts.
I have conducted some investigation. It seems like there is a miscommunication between SST and the core - SST set AVP of one type but Dialog module get another one.
Please have a look at the following snippets of code.
set_timeout_avp() in sst_handlers.c
Here we are passing PV_VAL_INT.
pv_val.flags = PV_VAL_INT;
pv_val.ri = value;
if (timeout_avp->setf(msg,&timeout_avp->pvp,EQ_T,&pv_val)!=0) {
LM_ERR("failed to set new dialog timeout value\n");
} else {
rtn = 0;
}
get_dlg_timeout() in dlg_handlers.c
Here we got PV_VAL_INT flag cleared. Therefore, we use defaut timeout.
if( timeout_avp && pv_get_spec_value( req, timeout_avp, &pv_val)==0
&& pv_val.flags&PV_VAL_INT && pv_val.ri>0 ) {
return pv_val.ri;
}
return default_timeout;
It seems as the reason of such a behaviour is in pv_set_avp() in pvar.c
We are trying to evaluate another flag PV_TYPE_INT instead of PV_VAL_INT before assigning values to newly added AVP:
if(val->flags&PV_TYPE_INT)
{
avp_val.n = val->ri;
} else {
avp_val.s = val->rs;
flags |= AVP_VAL_STR;
}
Else branch is executed and then, when we call pv_get_avp, we have wrong set of flags and no value assigned to ri member.
It is possible that changing (val->flags & PV_TYPE_INT) with (val->flags & PV_VAL_INT) is nedded, but Iam not sure that it will not cause any side effects.
Hi Artem,
The right fix will be in SST module, to replace :
pv_val.flags = PV_VAL_INT;
with
pv_val.flags = PV_VAL_INT| PV_TYPE_INT ;
if you could test and report if ok , I will upload the fix on SVN asap.
Thanks and regards,
Bogdan
Fix is on SVN.
Thanks and regards,
Bogdan