There are numerous tools and clients such as SIPp (http://sipp.sourceforge.net/) and X-Lite (http://www.counterpath.com/xlite-overview.html); however I'm not sure which support qop. Keep in mind that some products are more lenient than others concerning non compliances.
A common qop problem relates to quotes. You can compare your headers to rfc2617 section 3.5 or post them to the list. You can verify that the UAC is generating the correct digest response by following the rfc2617 algorithm and using "http://gtools.org/tool/md5-hash-generator/". A decent summary of rfc2617 is within "http://en.wikipedia.org/wiki/Digest_access_authentication"; however the rfc better reflects the quote removal. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Stephen C. Steel > Sent: Tuesday, January 08, 2008 5:17 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] Authorization with qop=auth > > I have been testing a SIP application, and I've been having > trouble with authorization. Most servers seem to send a basic > "WWW-Authenticate:" header without an entry for qop, and the > application authenticates with these servers without any problem. > > One particular SIP/PSTN gateway service provider has a server > which includes qop="auth" in the "WWW-Authenticate:" header > of its responses. > The application seems to respond appropriately: the resulting > "Authorization:" header now includes qop=auth, as well as > entries for cnonce and nc. However, these requests always generate a > "401 Unauthorized" response. So, either my credentials are > wrong, or the application is calculating the response > incorrectly, or the server is verifying the response incorrectly. > > I'm quite sure I have the correct credentials (user and > password) for this service. If I use an older version of the > application that doesn't support qop, it authenticates fine. > > Is there a publicly available known-good server I could test > my application against to help decide whether my application > or the server is at fault. > > Thanks, > Stephen C. Steel > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors