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-0600Date Closed:2014-01-07 13:55:03.000-0600
Versions:Frequency of
is related toASTERISK-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
Comments:By: Rudi (rudolf) 2010-12-20 16:34:18.000-0600

Same problem is with version  
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


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 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.