[sr-dev] [Tracker] Updated: (SER-36) Major deficiency of authentication module

Pavel Kasparek (JIRA) tracker at iptel.org
Tue Apr 27 08:49:52 CEST 2010


     [ http://tracker.iptel.org/browse/SER-36?page=all ]

Pavel Kasparek updated SER-36:
------------------------------

    Comment: was deleted

> Major deficiency of authentication module
> -----------------------------------------
>
>                 Key: SER-36
>                 URL: http://tracker.iptel.org/browse/SER-36
>             Project: SER
>          Issue Type: Improvement
>          Components: Digest Authentication
>    Affects Versions: Wishlist
>            Reporter: Jan Janak
>         Assigned To: Jan Janak
>         Attachments: auth.diff
>
>
> Folks,
> I've found that in some cases auth module performs very poorly. Namely
> in the cases when authentication is either time-consuming and/or
> expensive to perform. For example in the case when authentication is
> done using Radius while SER and Radius server is not on the same LAN.
> In such cases it is quite possible that due to delay UA will make
> several retransmits of REGISTER message, which due to the fact that
> REGISTER transactions are processes statelessly will block appropriate
> amount of SER childs and trigger appropriate amount of independent
> Radius auth requests, thus considerably increasing load of SER and
> Radius server.
> The same will happen in the case of auth DB module with remote DB server
> or even in the case when udp round-trip delay between SER and UA is more
> than 400-500 ms.
> It is logical to use statefull processing in such cases, but since usage
> of sl_send_reply is currently hardcoded in the registrar and auth
> modules, it is impossible to do that.
> Attached patch solves this problem by introducing new variable use_tm,
> which if set to 1 instructs those modules to use t_reply() instead of
> sl_send_reply() for generating replies. If there are no objections, I
> would like to commit it, as if possible merge into rel_0_9_0, since I
> believe that it is very useful feature. Since it defaults to "off" it
> should not create any new problems in the default installation.
> Thanks!
> Regards,
> Maxim

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.iptel.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the sr-dev mailing list