Hi, I am working with a SIP client, which adds "qop=auth" parameter in HTTP digest response even though sipX registrar does not use qop-options (RFC2617) to advertize qop support. Client registration fails since sipX registrar does not take into calculation the qop related parameters and as a result the response does not match. I was not able to find explicit statement in RFC2617 that use of qop by the client is forbidden if the server does not use qop-options.
After a quick inspection of the code it looks like the logic to calculate the MD5 hash with all the qop related parameters already exists in HttpMessage::buildMd5Digest. It is just a matter of mining for these values in the authentication header and passing them into the HttpMessage::buildMd5Digest method. I do not see any harm in extending the calculation to optionally take into consideration the qop parameters and it will allow more clients to interoperate with sipX. Is anybody strongly opinionated about this? Would there be an objection against me enhancing the authentication logic to include qop handling in responses. Thanks, Mark. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
