Hi, A few years ago, I adapted the RADIUS client code from SER to work in reSIProcate and specifically the SIP proxy, repro I'm now reviewing the code to work out how to extend it for reTurn, the TURN server and to see if any other changes are necessary. Things have changed slightly since reSIProcate originally adopted RADIUS support. The original implementation is based on http://tools.ietf.org/html/draft-sterman-aaa-sip-04 and that works with FreeRADIUS (or it did work at the time) although the draft is now expired. Since that time, RFC 5090 has emerged I notice various differences in the RFC, e.g. the RADIUS server must provide nonces: http://tools.ietf.org/html/rfc5090#section-2.1.5 and may also provide other values. reSIProcate currently generates it's own nonces and passes all the auth parameters to FreeRADIUS for verification. This brings me to some questions: Is anybody already working on migrating FreeRADIUS to the RFC variation of DIGEST support? If so, will older clients stop working? How to handle STUN/TURN? I notice STUN only uses "nonce" and not "qop" or any of the other values, yet RFC 5090 suggests that a RADIUS server can demand that the challenge uses those attributes. I'm also not sure just what value for "method" would be used with STUN. However, it would seem desirable to support STUN/TURN from a single RADIUS server. STUN auth (inherited by TURN) is described here: http://tools.ietf.org/html/rfc5389#section-10.2 This all leaves me feeling that STUN/TURN may need it's now module in FreeRADIUS. Regards, Daniel