Hey Alex,
On 10.10.2011 19:53, Alex Balashov wrote:
Not only that, but the fix is not trivial. Contrary to how it may appear to a non-developer, this problem cannot be solved by just making a little patch.
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
Agreed that fixing the issue for locally sent responses is somewhat tricky. Apart from trying to link stateless responses to transactions, however, there are other, less perfect solutions. For instance, you could allow reusing dialogs on arrival of a subsequent INVITE if the initial INVITE wasn't forwarded yet (and therefore must have been replied to locally). It's probably not trivial to implement but keeps the required modifications to a single module.
Then again, you can work around such cases by not tracking dialogs for which you know you are going to respond statelessly to (and therefore require no tracking) in the first place. It's not perfectly elegant from a usability point of view but it works.
By the way, I came across this bug from a specific scenario where authentication takes place behind the dialog-tracking proxy; that is, a 407 was received from upstream and forwarded back to the caller. In such scenarios, the approach I devised in the bug report should do well and not involve too much work.
Cheers,
--Timo