Re: [reSIProcate] reTurn authentication, async and threading issues
Note: This message was responded to in the reTurn-devel mailing list.
On Sun, Jan 22, 2012 at 9:47 AM, Daniel Pocock
<daniel@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel