[SR-Users] limiting concurrent calls with dialog module

Timo Reimann timo.reimann at 1und1.de
Tue Oct 11 10:52:13 CEST 2011


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



More information about the sr-users mailing list