|Summary:||ASTERISK-17138: [patch] Asterisk not re-registering after it receives "Forbidden - wrong password on authentication"|
|Date Opened:||2010-12-20 16:29:03.000-0600||Date Closed:||2014-01-07 13:55:03.000-0600|
|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
|Comments:||By: Rudi (rudolf) 2010-12-20 16:34:18.000-0600|
Same problem is with version 18.104.22.168.
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
1. Register -> 401 Unauthorized
2. Re-Register same like 1. => The SIP-Message Header are wrong, Authorization and Password missing
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
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
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:
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 22.214.171.124? 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.
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.