[Home]

Summary:ASTERISK-04501: 0004343: REGISTER "deadlock" between SPA's and Asterisk/Non-SPA Interoperability
Reporter:Jeremy (r00t)Labels:
Date Opened:2005-06-29 08:25:07Date Closed:2011-06-07 14:02:42
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:As discussed here: http://bugs.digium.com/view.php?id=4343
I did not see a way to reopen bug 4343 so following advice gotten in #asterisk-dev I am issuing this new report. Sorry if this was incorrect.

"After a random period of time (minutes to days), asterisk starts denying authentication requests from SPA boxes with a 403 Forbidden result. The cause of this error is twofold. First, for some reason, the nonce value gets out of sync (stale) between the Sipura and Asterisk. Thus, the MD5 hash provided by the sipura box does not match the hash calculated by Asterisk. Second, the Sipura simply retries the same request, with the same nonce, instead of taking the 403 Forbidden result to mean that it should start over. This appears to make the call never expire since the sipura retries faster than the call times out. As a result, you end up in a state where the SPA asks to be registered, and asterisk says no. lather. rinse. repeat."

My asterisk server started showing
Jun 29 07:40:27 NOTICE[10063]: chan_sip.c:5606 check_auth: stale nonce received from 'sipura <sip:sipura@tcecnc.com>'

I came across bug id 4343 after a google search. I saw a patch had been submitted and merged. I checked my verion number: Asterisk CVS-HEAD-06/05/05-03:56:53. It appeared I should have already had the patch. To be sure I upgraded to version: 2005-06-29 08:56:26. Unfortunately for me the problem remains. I have included output of "sip debug" below. I will be idling in #asterisk-dev and #asterisk-bugs, username nine76. Feel free to contact me anytime. I am more than willing to provide any helpful information. Thanks.

****** ADDITIONAL INFORMATION ******

<-- SIP read from 210.4.57.125:33891:
REGISTER sip:tcecnc.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-2fc5997a
From: sipura <sip:sipura@tcecnc.com>;tag=e8b1ac431a883bd0o0
To: sipura <sip:sipura@tcecnc.com>
Call-ID: 88c5924f-9820ad34@192.168.1.3
CSeq: 93 REGISTER
Max-Forwards: 70
Authorization: Digest username="sipura",realm="asterisk",nonce="60d6b5a6",uri="sip:tcecnc.com",algorithm=MD5,response="3ed734fbff798a880158bad474661deb"
Contact: sipura <sip:sipura@192.168.1.3:5060>;expires=37
User-Agent: Sipura/SPA2000-2.0.13(g)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura


--- (13 headers 0 lines)---
Using latest request as basis request
Transmitting (NAT) to 210.4.57.125:33891:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-2fc5997a;received=210.4.57.125;rport=33891
From: sipura <sip:sipura@tcecnc.com>;tag=e8b1ac431a883bd0o0
To: sipura <sip:sipura@tcecnc.com>
Call-ID: 88c5924f-9820ad34@192.168.1.3
CSeq: 93 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Contact: <sip:sipura@24.164.80.140>
Content-Length: 0


---
Transmitting (NAT) to 210.4.57.125:33891:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-2fc5997a;received=210.4.57.125;rport=33891
From: sipura <sip:sipura@tcecnc.com>;tag=e8b1ac431a883bd0o0
To: sipura <sip:sipura@tcecnc.com>;tag=as3a306cd7
Call-ID: 88c5924f-9820ad34@192.168.1.3
CSeq: 93 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Contact: <sip:sipura@24.164.80.140>
WWW-Authenticate: Digest realm="asterisk", nonce="04ec639f"
Content-Length: 0


---
Scheduling destruction of call '88c5924f-9820ad34@192.168.1.3' in 15000 ms
tcecnc*CLI>
<-- SIP read from 210.4.57.125:33891:
REGISTER sip:tcecnc.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-2fc5997a
From: sipura <sip:sipura@tcecnc.com>;tag=e8b1ac431a883bd0o0
To: sipura <sip:sipura@tcecnc.com>
Call-ID: 88c5924f-9820ad34@192.168.1.3
CSeq: 93 REGISTER
Max-Forwards: 70
Authorization: Digest username="sipura",realm="asterisk",nonce="60d6b5a6",uri="sip:tcecnc.com",algorithm=MD5,response="3ed734fbff798a880158bad474661deb"
Contact: sipura <sip:sipura@192.168.1.3:5060>;expires=37
User-Agent: Sipura/SPA2000-2.0.13(g)
Content-Length: 0
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: x-sipura


--- (13 headers 0 lines)---
Using latest request as basis request
Sending to 192.168.1.3 : 5060 (NAT)
Transmitting (NAT) to 210.4.57.125:33891:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-2fc5997a;received=210.4.57.125;rport=33891
From: sipura <sip:sipura@tcecnc.com>;tag=e8b1ac431a883bd0o0
To: sipura <sip:sipura@tcecnc.com>
all-ID: 88c5924f-9820ad34@192.168.1.3
CSeq: 93 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Contact: <sip:sipura@24.164.80.140>
Content-Length: 0


---
Jun 29 08:57:21 NOTICE[10359]: chan_sip.c:5606 check_auth: stale nonce received from 'sipura <sip:sipura@tcecnc.com>'
Transmitting (NAT) to 210.4.57.125:33891:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.3:5060;branch=z9hG4bK-2fc5997a;received=210.4.57.125;rport=33891
From: sipura <sip:sipura@tcecnc.com>;tag=e8b1ac431a883bd0o0
To: sipura <sip:sipura@tcecnc.com>;tag=as3a306cd7
Call-ID: 88c5924f-9820ad34@192.168.1.3
CSeq: 93 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Contact: <sip:sipura@24.164.80.140>
WWW-Authenticate: Digest realm="asterisk", nonce="6017ebde" , stale=true
Content-Length: 0


---
Scheduling destruction of call '88c5924f-9820ad34@192.168.1.3' in 15000 ms
Comments:By: Olle Johansson (oej) 2005-07-03 14:07:53

Asterisk correctly tells the SIPURA that it is out of sync, that it is using a stale nonce. Is there anything else we should do to wake it up?
By: Jeremy (r00t) 2005-07-05 20:16:12

I was under the impression the patch would allow the sipura to re-register and avoid the deadlock. For myself, the stale nonce continues and the sipura cannot re-register. Hence the deadlock remains. If this is the sipuras fault I'm sorry for bringing the issue here. If in fact the patch is allowing others sipuras to re-register and avoid the deadlock I must be missing something?

Thanks oej! Appreciate your assistance.
By: Kevin P. Fleming (kpfleming) 2005-07-05 21:26:05

We are already sending 'stale=true' to the SPA; if that's not adequate for it to realize there is a new nonce needed, then it is badly broken.

I would double-check that you have the latest known-working firmware for your SPA, and get in contact with some other users who are not having this problem to see what may be different about your environment.