"sip reload" kills broadvoice registration for app

I installed the trixbox 2.0 and signed up for the BroadVoice service. I had all sorts of trouble getting it work and noticed that when applying configuration changes inside of FreePBX I would not be able to make calls in or out.

After much reading / searching / trial and error testing, I have found that when the FreePBX script issues a “sip reload” after a configuration change it drops the BroadVoice connection. The status for a “sip show peers” is:

Name/username Host Dyn Nat ACL Port Status
sip.broadvoice.com/XXXXX 5060 UNREACHABLE

A “sip show registry” is:

Host Username Refresh State
sip.broadvoice.com:5060 XXXXXXXXX@s 120 Unregistered

Starting and stopping Asterisk or even rebooting does not get it registered again. All I have found that works is just waiting… and waiting… after about an hour it will come back.

I sent an email to broadvoice and they said “We imagine the multiple registration attempts before expiration is what is causing the problems. Our system thinks multiple devices are logging in to use your account while we only allow 1.”

So I am thinking the “sip reload” command isn’t doing something (or undoing something) quite right, but am not sure where to go from here. I suppose I could just upgrade the Asterisk 1.2.13 to the 1.4, but don’t know if that will be the correct approach.

Has anybody else seen this? and if so, is there a workaround? My current workaround is to restart asterisk after making configuration changes and never clicking the “Apply Configuration Changes” link in FreePBX.

In case someone wants to look here is my register line:


And here is my sip_additional.conf:


My config APPEARS to work just fine as long as I don’t apply a new config or do anything that would make a “sip reload” happen.

Thanks for any advice.

I, too, have seen this problem. I’m running a plain Asterisk 1.2 installation with no GUI. If I execute a “sip reload” then Broadvoice immediately gets another registration request while the current registration hasn’t yet timed out. This triggers their security mechanism, which blocks you for an hour. The trick is to always shut down Asterisk completely anytime you want to restart it, then wait five minutes before starting it again. This is very annoying, I know, but it’s the only way I’ve found around the problem.

Incidentally, quite often the Broadvoice person you talk to doesn’t even know about this security measure! They then end up wasting a lot of time troubleshooting a problem that is Broadvoice-induced. The normal staff people can’t apparently see if you’re IP address is in the security blacklist. The second level techs, however, can, and they can clear the list as well.

I’ve recommended a change to the Broadvoice user interface to let customers list the allowable IP addresses for incoming connections, which would then never be subject to this security restriction. No word from Broadvoice on this yet, though.