| < Previous by Date | Date Index | Next by Date > |
| Thread Index | Next in Thread > |
Hi, I am having in the field a complaint that arises when the SIP Proxy issues a 401 with a WWW-Authenticate header including a 'qop' parameter. Per RFC 2617 when the client receives a WWW-Authenticate header with a 'qop' parameter it must issue the Authorization header with a 'nc' parameter: nonce-count This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay. See the description below of the construction of the request-digest value. Also the format of the value is specified in the RFC: nonce-count = "nc" "=" nc-value nc-value = 8LHEX .... LHEX = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" The problem is that our User Agent with reSIProcate is sending nc-values with uppercase hex digits as example below: Authorization: Digest username="2278",realm="nps.com",nonce="3988adcb771a50d624e7224f8c13e62e", uri="sip:nps.com",response="2d7a33a36ab1080ae3809e2099a868e4",cnonce="07cddd2ac21d0a41a362ed92e77f30ab", nc=0000000A,qop=auth,algorithm=MD5 Notice that "nc=0000000A" instead of the compliant lowercase hex "nc=0000000a" That behaviour is causing registration failure. How can that issue be solved in reSIProcate ? Regards, Julio. |