| Summary: | ASTERISK-04339: [patch] REGISTER "deadlock" between SPA's and Asterisk/Non-SPA Interoperability | ||
| Reporter: | Kevin P. Fleming (kpfleming) | Labels: | |
| Date Opened: | 2005-06-03 15:14:42 | Date Closed: | 2011-06-07 14:02:45 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | 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. I will carefully sidestep the whole "the sipura is broken also" issue.<br /> <br /> Based on other discussions among the VoIP community, most notably the vovida bug at http://bugzilla.vovida.org/bugzilla/show_bug.cgi?id=605], certain non-sipura clients will assume that a 403 response means "go away, come back never". Sipura being different of course assumes 403 means "come back in 5 seconds and try the exact same request again". (Yes, I will be submitting a bug to sipura as well).<br /> <br /> From everything I've read, it sounds like responding with a 401 is the more interoperable way to handle a nonce mismatch. It also appears to fix the sipura issue (see below). ****** ADDITIONAL INFORMATION ****** The attached patch is my attempt to fix this issue by checking nonce during the authentication phase, and if it doesn't match (i.e. it's stale), asterisk then replies with a 401 with a new nonce. This appears to be working in my environment, but it's hard to tell because of the randomness of the events. I will post updates over the next few days. | ||
| Comments: | By: Russell Bryant (russell) 2005-06-13 16:33:49 fixed in 1.0 By: Digium Subversion (svnbot) 2008-01-15 15:38:04.000-0600 Repository: asterisk Revision: 5902 U branches/v1-0/channels/chan_sip.c ------------------------------------------------------------------------ r5902 | russell | 2008-01-15 15:38:04 -0600 (Tue, 15 Jan 2008) | 2 lines handle stale authentication nonces more properly (bug ASTERISK-4339) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5902 | ||