#293 Dialogs with SSTenabled use default timeout

1.5.x
closed-fixed
modules (454)
5
2010-07-22
2010-06-15
Artem Osmerkin
No

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.

Discussion

  • 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

     
    • assigned_to: nobody --> bogdan_iancu
     
    • status: open --> closed-fixed
     
  • Fix is on SVN.

    Thanks and regards,
    Bogdan