#458 In-dialog request clobbers Dialog module timer value

[Kobi Eshun]

The dlg_onroute() callback invokes update_dlg_timer() when a "sequential request is successfully processed." There are two problems with this:

1 - It defeats the purpose of using the dialog timeout as a watchdog to limit call duration. Does it make sense to optionally suppress updates to the dialog timer?

2 - the timer is updated with a value read from the timeout AVP. Unfortunately, the AVP is at best only transaction stateful, and thus (generally) undefined for sequential requests. As a result, the default timeout parameter is used instead (12 hours by default). Presumably the value from the timeout AVP needs to be cached in dialog-persistent memory for this to work as might be expected.

This problem exists in versions 1.2 through HEAD. Cheers,
--
kobi

[Nobody/Anonymous]

Logged In: NO

This problem combined with the change from rev 2981 (call callbacks for sequential ACKs) incorrectly resets the dialog timeout value for items in the Session Timer module and the Bye2Bye patch.

[Klaus Darilion]

IMO these are no bugs:

1. the dialog module is for keeping dialog state. Thus, e.g. reINVITEs (e.g. session timer or manually) should update the lifetime, as it does (except with a bug) - see https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2174497&group_id=139143

If you want to limit the maximum call duration that would be probably a feature request.

2. Of course the AVP must be set manually also for the in-dialog requests (before calling loose_route()). To avoid this maybe it might be useful for in-dialog requests to update the timer using the initial lifetime instead of parsing AVPs agains (of course this does not allow anymore to change the lifetime value during in-dialog requests)

IMO, the lifetime value should set during dialog creation (either from module parameter or AVP) and then, for in-dialog requests, just update the timer with the same lifetime value again.