Summary:	ASTERISK-17138: [patch] Asterisk not re-registering after it receives "Forbidden - wrong password on authentication"
Reporter:	Rudi (rudolf)	Labels:
Date Opened:	2010-12-20 16:29:03.000-0600	Date Closed:	2014-01-07 13:55:03.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Registration
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-18055 Attempting to register to remote server that returns 404 causes no further registration attempts
Environment:		Attachments:	( 0) 4.patch ( 1) sip_log.txt
Description:	I found a problem with one of our providers. It looks like SIP Trunk stops re-registering after it receives Forbidden - wrong password on authentication I have asterisk version 1.4.38 and i have registertimeout=20 registerattempts=0
Comments:	By: Rudi (rudolf) 2010-12-20 16:34:18.000-0600 Same problem is with version 1.4.29.1.   Trunk re-registers after doing "sip reload". Last registration status is "585 Request Sent". By: Leif Madsen (lmadsen) 2011-01-04 13:51:15.000-0600 If you set the registerattempts to greater than 0, does it try again? Does the documentation say setting it to zero means infinite attempts? By: Rudi (rudolf) 2011-01-04 16:12:07.000-0600 No in this case it does not try again. According to documentation it sais "registerattempts=0 will force Asterisk to attempt to reregister until it can". By: schmidu (schmidu) 2011-02-01 02:54:03.000-0600 Same problem with AsteriskNow 1.7.1 Provider sipcall.ch 1. Register -> 401 Unauthorized 2. Re-Register same like 1. => The SIP-Message Header are wrong, Authorization and Password missing Any workarround? By: Holger Hornung (netview) 2011-03-06 13:49:05.000-0600 I have the same problem with provider 1und1 and asterisk 1.8.3. the attached patch will do a reregister. By: tbsky (tbsky) 2012-02-20 20:31:40.023-0600 I have the same problem with my provider under asterisk 1.8.9 they seem to restart their server every two weeks and asterisk refuse to register anymore. with the patch, asterisk will try to register again and everything become normal. is that possible to add an option so asterisk will still try to register even receive the "wrong password" respond? it seems against the RFC but it is necessary to connect with buggy providers. By: Philippe Lindheimer (p_lindheimer) 2013-01-07 12:42:48.898-0600 This has been a long term issue on Asterisk systems. A carrier can sometimes send back a 403 in error and the client is left hanging despite the user believing their configuration will retry. It might be reasonable to add a parameter that tells asterisk whether it should honor the 403 over the retry setting or something of that nature. From some discussion of the sip implementors: Be reasonable. The point of a 403 is to inform the UA that it should not re-send the REGISTER until it has reason to believe that some aspect of the situation might have changed that would permit the REGISTER to succeed. In particular, it should not automatically re-send it every few seconds. Thus, it would be reasonable to re-send under circumstances like: - the UA is explicitly ordered to by the user - the UA reinitializes due to user instruction or power-cycling - the UA is re-provisioned by some provisioning server - after an extended period, such as 1 hour, to allow for the possibility that the registration server has been re-provisioned. All of these have the property that even if the authorization problem has not been resolved, they do not present an abnormally high load to the registration server. By: Rudi (rudolf) 2013-01-08 03:45:11.704-0600 You can also do quick fix with blocking 403 messages on firewall. /sbin/iptables -I INPUT -i eth1 -p udp -m string --string "403 Forbidden" --algo bm -j DROP By: Lee Howard (faxguy) 2013-02-26 07:56:26.946-0600 SIP provider VoIPfone has informed me that it's giving out "403 Forbidden" after a period of loss of connectivity "due to the way Asterisk caches its authentication" as that trips security alarms there.  So, perhaps Asterisk should be doing something different with regards to "caching its authentication" in order to lessen the chances of tripping some security feature with a SIP provider? By: Walter Doekes (wdoekes) 2013-02-26 08:10:20.556-0600 @Lee: could you get a slightly more technical explanation with that from your SIP provider? By: Paul Belanger (pabelanger) 2013-02-26 12:37:56.219-0600 Yup, easy to reproduce.  Ran into this the other day. By: Lee Howard (faxguy) 2013-02-26 15:09:30.657-0600 @Walter... VoIPfone has responded: "Regarding your discussion with the developers, the issue is that they cache the 'nonce' (http://en.wikipedia.org/wiki/Cryptographic_nonce). This is perfectly valid, although this is rare when compared to other SIP devices registering to our platform. We do have plans to improve our auto banning system to stop systems like Asterisk being tripped up when they try to register to us after the registration has expired using a cached nonce which we longer know about, thus reject." Despite the caching of the nonce being valid I believed that users would be better-served if the nonce cache were flushed any time a registration time-out occurred. By: Kinsey Moore (kmoore) 2013-09-19 14:28:31.044-0500 For those still following this issue, I'm working on this feature for chan_sip and chan_pjsip in Asterisk trunk. You can follow progress on this branch: http://svn.digium.com/svn/asterisk/team/kmoore/retry_forbidden By: Frederic Van Espen (frederic.ve) 2014-01-02 02:25:39.548-0600 Is it at all possible that this patch wasn't ported correctly to asterisk 1.8.25.0? By looking at the changes in SVN I only see that the option is added, but it isn't used anywhere in the "case 403" response part of the code. By: Matt Jordan (mjordan) 2014-01-02 06:56:30.878-0600 No, it does not look like it was applied correctly in any of the branches. Re-opening. By: Kinsey Moore (kmoore) 2014-01-07 15:34:16.102-0600 The missing code has now been committed to latest 1.8, 11, 12, and trunk and the tests should be checking for it on those branches as well.