Nuno, which pjsip version are you using? And any particular compile time macros related to authentication that you set? This shouldn't happen with recent pjsip version (by recent I mean version 10 months old or newer). We check both stale and nonce value to decide whether to resend authentication, and we set a cap on how many retries to send. After sending request with authentication, and if server keeps rejecting with 401: - if stale=true, retry until PJSIP_MAX_STALE_COUNT times (default is 3). - if state=false, and nonce changed, also retry until PJSIP_MAX_STALE_COUNT times - if stale=false and nonce doesn't change, we set authentication to fail We have a dozen of test scripts to test various scenarios related to authentication, see tests\pjsua\scripts-recvfrom directory (the nnn_reg_* files), so it shouldn't happen. Unless if there's a bug of course. :) cheers Benny On Fri, May 15, 2009 at 5:41 AM, Gang Liu <gangban.lau at gmail.com> wrote: > I saw many UAs do this way.So some sip registar will respond 403 if account > or password is wrong after 401 challenge. > > regards, > Gang > > On Fri, May 15, 2009 at 12:45 AM, Nuno Costa <ncosta at wit-software.com>wrote: > >> Hi, >> >> During recent tests, I find out a strange behavior during the >> authentication process using the Digest algorithm. >> Analyzing the problem from a high level, this is the behavior: >> 1. A REGISTER packet without any authentication header is sent to the >> server. >> 2. The server replies with a '401 Unauthorized' with an authentication >> header which includes a challenge (nonce). >> 3. The client issues a new REGISTER request with the necessary >> authentication header, including the answer to the challenge. >> 4. As the response is incorrect (because the password is incorrect), >> the server replies again with a '401 Unauthorized', but includes a new >> challenge and stale = false. >> 5. When the client receives a new challenge, it automatically restarts >> a new authentication process, by sending a new REGISTER request with the >> response to to challenge #2. >> 6. As before, the server answer with new challenge. >> 7. And the client issues a new response. >> 8. Steps 6 and 7 are repeated endless until the server locks the >> account and answer with a '403 User Not Authenticated'. >> >> Both behaviours (client and server side) seem to be correct and compliant >> with RFC 3261 (SIP: Session Initiation Protocol) and RFC 2617 (HTTP >> Authentication: Basic and Digest Access Authentication). >> Am I missing anything? >> >> Best regards, >> Nuno Costa >> >> -- >> ========================================= >> Nuno Costa >> Senior Engineer >> WIT Software S.A. >> Coimbra (Portugal), San Jose (California) >> Phone : +351 239 801030 >> Mobile: +351 91 9821825 >> Email : nuno.costa at wit-software.com >> Web: http://www.wit-software.com >> ========================================= >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090515/a36839a0/attachment.html>
