Author Topic: SIP REGISTRATION failure 401 Unauthorized  (Read 6889 times)

Alexey Kononykhin

  • Newbie
  • *
  • Posts: 2
    • View Profile
SIP REGISTRATION failure 401 Unauthorized
« on: March 20, 2019, 03:49:48 AM »
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"
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.
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