Yate server > Yate bugs

SIP REGISTRATION failure 401 Unauthorized

(1/1)

Alexey Kononykhin:
Hello

I have a strange situation with line registration to DIDLogic provider.
Initial logon SIP REGISTRATION sequence works fine (REGISTER->401 Unauthorized->REGISTER (with Auth)->200 OK) a lot of the next SIP REGISTRATION too but starting from some moment provider starts to decline the registration.

After some investigation I found the next. The second SIP REGISTRATION packet generated by Yate contains Authorization header:

--- Quote ---Authorization: Digest username="...", realm="sip.nyc.didlogic.net", nonce="XJILtlySCooP26WY/Xl8+TGKaUdK4Hux4B93tYA=", uri="sip:sip.nyc.didlogic.net", response="6bff40c0c46f75122e3d7479a6233061", algorithm=MD5, qop=auth, nc=0000004e, cnonce="b00b8ee42d705f142ed79eec4566bb0c"

--- End quote ---
with parameter nc=0000004e (at this packet). The value of nonce-count (value of nc=...) is increased after the each SIP REGISTRATION sequence. And as soon as it's increased to 0x00000100 and higher DIDLogic starts to decline authorization.

Of course the problem of nonce-count higher then  0x00000100 is the question to DIDLogic but I'd like to discuss the question of increasing of nonce-count value.
As far as I understand the description of nonce-count at https://tools.ietf.org/html/rfc2617:

--- Quote ---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.

--- End quote ---
The value of nonce-count has to be unique for SIP REGISTRATION requests with the same nonce value. If nonce value is changed (SIP server returned new nonce value) the value of nonce-count has to be started from 0x1 (00000001) back.

Any ideas about it?

Best regards
Alexey

Navigation

[0] Message Index