[reSIProcate] reTurn authentication, async and threading issues
Scott Godin
sgodin at sipspectrum.com
Sun Jan 22 12:30:58 CST 2012
Note: This message was responded to in the reTurn-devel mailing list.
On Sun, Jan 22, 2012 at 9:47 AM, Daniel Pocock <daniel at pocock.com.au> wrote:
>
>
>
> I'm just looking at how to do authentication with reTurn
>
> The current state of things:
>
> - users are configured at compile time in ReTurnConfig.cxx
>
> - users are validated by RequestHandler.cxx /
> RequestHandler::handleAuthentication
> (which calls ReTurnConfig::isUserNameValid)
>
> - the authentication is all synchronous (so RequestHandler blocks if
> there is database or network lookup)
>
> In resip/dum, we have async authentication (e.g. using the
> RADIUSServerAuthManager and RADIUSDigestAuthenticator classes)
>
> I don't mind doing the work to integrate some of that into reTurn, but
> I'd appreciate some feedback about the issue first:
>
> a) how should the async behavior be implemented?
>
> b) is TURN auth similar enough to SIP auth that we can use the
> ServerAuthManager?
>
> c) if the answer to (b) is no, does that mean we need something
> different for reTurn? Or could ServerAuthManager be further generalised
> to meet the needs of TURN?
>
> d) or could the async behavior be achieved indirectly, e.g. creating a
> new thread to handle each incoming STUN message (maybe create a thread
> from UdpServer::onReceiveSuccess) and would this be a better strategic
> solution?
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20120122/2e275f35/attachment.htm>
More information about the resiprocate-devel
mailing list