Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Alexey Kononykhin

Pages: [1]
1
Hello

Sometime our provider doesn't respond in a timely manner. For example:
1) Yate sends INVITE at 00:00
2) provider responds with SIP 100 Trying at 00:00
3) and the next SIP 183 Session Progress will be only around 30 seconds later or more (usually it's for incorrect numbers only).

If provider succeeds to send "183 Session Progress" for less then 30 seconds then all is ok but in the most cases it's not and after 30-32 seconds Yate initiates CANCEL packets and I see the next message in the log:

2019-05-10_16:25:58.463548 <sip/1252:ALL> YateSIPConnection::hangup() state=1 trans=0x7f504001da10 error='noconn' code=408 reason='Request Timeout' [0x7f504001b640]


So the question is it possible to extend the timer so CANCEL will be initiated not after 30 seconds but later? Which configuration setting (if any) is responsible for it?

Thanks ahead.

2
Yate bugs / 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

Pages: [1]