[SR-Users] limiting concurrent calls with dialog module

[Timo Reimann]

Am 08.10.2011 um 21:44 schrieb Iñaki Baz Castillo:
> 2011/10/3 Jon Bonilla <manwe at aholab.ehu.es>:
>> Due to a couple of bugs in the dialog module I'd suggest you to run this code
>> after the user auth has been successfull. You'll need to call dlg_manage()
>> function first.
>> 
>> The other bug makes the dialog not being freed if you send a sl reply generated
>> by the proxy. You should call t_newtran + t_reply to send a statefull reply to
>> the user.
> 
> Mixing two points above into a single one:
> 
> - Just call dlg_manage() after the authentication and authorization
> has been made.
> 
> As a recommendation, call dlg_manage() just before t_relay() and you
> are done (and you will avoid both bugs explained by Jon).

This works around most issues w.r.t. to the dialog module. However, there's at least one case which cannot be covered: If a proxy behind the one tracking a dialog returns a status code that must not render the dialog as failed (e.g., 407), as of the current implementation the dialog *will* transition into the failure state. According to the standard, this must not occur.

As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible. Overall, I believe that dialog module usage should be more robust and work out of the box; that is, it shouldn't matter where you place dlg_manage(), things should just work and handle the tricky cases intelligently. That's something for the long run though. For the time being, the two hints you gave can definitely be considered good practice regarding the dialog module.


Cheers,

--Timo


[1] http://sip-router.org/tracker/index.php?do=details&task_id=146