In dlg_handlers.c:
function dlg_onroute():
if ( (event==DLG_EVENT_REQ || event==DLG_EVENT_REQACK)
&& new_state==DLG_STATE_CONFIRMED) {
LM_DBG("sequential request successfully processed\n");
timeout = get_dlg_timeout(req);
/* update timer during sequential request? */
if (timeout!=default_timeout) {
dlg->lifetime = timeout;
if (update_dlg_timer( &dlg->tl, dlg->lifetime )==-1)
LM_ERR("failed to update dialog lifetime\n");
}
This causes the timer on in-dialog requests only be updated if the in-dialog request has a differnt timeout than the default module timeout. Thus, if timeout_avp is not used, the timer wont be updated.
Hi Klaus,
is this perhaps related to this bug: https://sourceforge.net/tracker/index.php?func=detail&aid=1963639&group_id=139143&atid=743020
?
I've uncommented the "if" and it seems to work (a sequential request resets the timer):
/* update timer during sequential request? */
// if (timeout!=default_timeout) {
dlg->lifetime = timeout;
if (update_dlg_timer( &dlg->tl, dlg->lifetime )==-1)
LM_ERR("failed to update dialog lifetime\n");
// }
Is it so easy or are there other points to check?
It depends on the policy. Should it be allowed to change the lifetime during handling of indialog requests or should the lifetime always be prolonged by the value specified with the intial request?
klaus
Yes, obviously they are two different concepts:
1) Max call duration (current behaviour).
2) Provisional timeout (behaviour with my "patch").
IMHO option 2 makes more sense in most of the cases since the aim of the administrator is usually check if a dialog still exists.
The existance of both options would be great :)