Asterisk does not accept registration

Hello everyone!

There was a problem asterisk does not return " OK " after user authorization, and of course the phone does not receive this message and tries to register for it and so on.

If you change the IP address on the phone, the problem disappears for a while

Asterisk CLI log:

chan_sip.c:17476 check_auth: Correct auth, but based on stale nonce received from ‘Velikiy sip:300@jabber.comnet.uz;tag=2108556060’

Brief logs

16:43:52.058399 IP 192.168.5.206.5106 > 172.16.236.105.5060: SIP: REGISTER sip:jabber.comnet.uz SIP/2.0
16:43:52.058995 IP 172.16.236.105.5060 > 192.168.5.206.5106: SIP: SIP/2.0 401 Unauthorized
16:43:52.075156 IP 192.168.5.206.5106 > 172.16.236.105.5060: SIP: REGISTER sip:jabber.comnet.uz SIP/2.0
16:43:52.076078 IP 172.16.236.105.5060 > 192.168.5.206.5106: SIP: OPTIONS sip:300@192.168.5.206:5106 SIP/2.0
16:43:52.077019 IP 172.16.236.105.5060 > 192.168.5.206.5106: SIP: SIP/2.0 200 OK
16:43:52.670290 IP 192.168.5.206.5106 > 172.16.236.105.5060: SIP: REGISTER sip:jabber.comnet.uz SIP/2.0
16:43:52.670527 IP 172.16.236.105.5060 > 192.168.5.206.5106: SIP: SIP/2.0 401 Unauthorized
16:43:53.075543 IP 172.16.236.105.5060 > 192.168.5.206.5106: SIP: OPTIONS sip:300@192.168.5.206:5106 SIP/2.0
16:43:53.095356 IP 192.168.5.206.5106 > 172.16.236.105.5060: SIP: SIP/2.0 200 OK

All:

16:38:09.331016 IP (tos 0x0, ttl 62, id 2595, offset 0, flags [DF], proto UDP (17), length 721)
    192.168.5.206.5106 > 172.16.236.105.5060: SIP, length: 693
	REGISTER sip:jabber.comnet.uz SIP/2.0
	Via: SIP/2.0/UDP 192.168.5.206:5106;branch=z9hG4bK5865265211526845605;rport
	From: Velikiy <sip:300@jabber.comnet.uz>;tag=1248813375
	To: Velikiy <sip:300@jabber.comnet.uz>
	Call-ID: 38623437726409-597892105864212@192.168.5.206
	CSeq: 3 REGISTER
	Contact: <sip:300@192.168.5.206:5106>
	Authorization: Digest username="300", realm="asterisk", nonce="643e82ff", uri="sip:jabber.comnet.uz", response="8e1f28913842c2e4b9670e6e0f5b54f6", algorithm=MD5
	Max-Forwards: 70
	Expires: 3600
	Supported: path
	User-Agent: Fanvil X1S 2.4.6 0c:38:3e:48:e2:d1
	Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
	Content-Length: 0
	
16:38:09.331370 IP (tos 0x0, ttl 64, id 63813, offset 0, flags [none], proto UDP (17), length 602)
    172.16.236.105.5060 > 192.168.5.206.5106: SIP, length: 574
	SIP/2.0 401 Unauthorized
	Via: SIP/2.0/UDP 192.168.5.206:5106;branch=z9hG4bK5865265211526845605;received=192.168.5.206;rport=5106
	From: Velikiy <sip:300@jabber.comnet.uz>;tag=1248813375
	To: Velikiy <sip:300@jabber.comnet.uz>;tag=as283a08d4
	Call-ID: 38623437726409-597892105864212@192.168.5.206
	CSeq: 3 REGISTER
	Server: Asterisk PBX 18.8.0
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
	Supported: replaces, timer
	WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="19dec6b6", stale=true
	Content-Length: 0
	

16:38:09.828992 IP (tos 0x0, ttl 64, id 63935, offset 0, flags [none], proto UDP (17), length 586)
    172.16.236.105.5060 > 192.168.5.206.5106: SIP, length: 558
	OPTIONS sip:300@192.168.5.206:5106 SIP/2.0
	Via: SIP/2.0/UDP 172.16.236.105:5060;branch=z9hG4bK19bf0f87
	Max-Forwards: 70
	From: "asterisk" <sip:asterisk@172.16.236.105>;tag=as67a1f396
	To: <sip:300@192.168.5.206:5106>
	Contact: <sip:asterisk@172.16.236.105:5060>
	Call-ID: 5a0e585508c75a405f9698372ad5e02e@172.16.236.105:5060
	CSeq: 102 OPTIONS
	User-Agent: Asterisk PBX 18.8.0
	Date: Mon, 12 Sep 2022 11:38:08 GMT
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
	Supported: replaces, timer
	Content-Length: 0
	
16:38:09.842965 IP (tos 0x0, ttl 62, id 2603, offset 0, flags [DF], proto UDP (17), length 592)
    192.168.5.206.5106 > 172.16.236.105.5060: SIP, length: 564
	SIP/2.0 200 OK
	Via: SIP/2.0/UDP 172.16.236.105:5060;branch=z9hG4bK19bf0f87
	From: "asterisk" <sip:asterisk@172.16.236.105>;tag=as67a1f396
	To: <sip:300@192.168.5.206:5106>;tag=1305025771
	Call-ID: 5a0e585508c75a405f9698372ad5e02e@172.16.236.105:5060
	CSeq: 102 OPTIONS
	Contact: <sip:192.168.5.206:5060>
	Supported: 100rel, replaces, timer
	User-Agent: Fanvil X1S 2.4.6 0c:38:3e:48:e2:d1
	Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
	Accept: application/sdp, message/sipfrag, application/dtmf-relay
	Content-Length: 0
	


16:38:10.354074 IP (tos 0x0, ttl 62, id 2637, offset 0, flags [DF], proto UDP (17), length 721)
    192.168.5.206.5106 > 172.16.236.105.5060: SIP, length: 693
	REGISTER sip:jabber.comnet.uz SIP/2.0
	Via: SIP/2.0/UDP 192.168.5.206:5106;branch=z9hG4bK5865265211526845605;rport
	From: Velikiy <sip:300@jabber.comnet.uz>;tag=1248813375
	To: Velikiy <sip:300@jabber.comnet.uz>
	Call-ID: 38623437726409-597892105864212@192.168.5.206
	CSeq: 3 REGISTER
	Contact: <sip:300@192.168.5.206:5106>
	Authorization: Digest username="300", realm="asterisk", nonce="643e82ff", uri="sip:jabber.comnet.uz", response="8e1f28913842c2e4b9670e6e0f5b54f6", algorithm=MD5
	Max-Forwards: 70
	Expires: 3600
	Supported: path
	User-Agent: Fanvil X1S 2.4.6 0c:38:3e:48:e2:d1
	Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
	Content-Length: 0
	
16:38:10.354593 IP (tos 0x0, ttl 64, id 63946, offset 0, flags [none], proto UDP (17), length 602)
    172.16.236.105.5060 > 192.168.5.206.5106: SIP, length: 574
	SIP/2.0 401 Unauthorized
	Via: SIP/2.0/UDP 192.168.5.206:5106;branch=z9hG4bK5865265211526845605;received=192.168.5.206;rport=5106
	From: Velikiy <sip:300@jabber.comnet.uz>;tag=1248813375
	To: Velikiy <sip:300@jabber.comnet.uz>;tag=as283a08d4
	Call-ID: 38623437726409-597892105864212@192.168.5.206
	CSeq: 3 REGISTER
	Server: Asterisk PBX 18.8.0
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
	Supported: replaces, timer
	WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="19dec6b6", stale=true
	Content-Length: 0
	

The registrant should immediately respond with the updated nonce from the 401, not wait a second and then respond with the stale one, again. Maybe the 401’s are not reaching it, and it is retransmitting because of an apparent missed response.