Running on FreePBX 2.9.0.7, installed from freepbx distro cd.
I got a message today from the office that they could not place calls anymore - says ‘all circuits are busy’. If you try to call in, you get a busy signal.
This is completely out of the blue. No configuration changes have been made in weeks, no handset additions/changes, etc. I have checked our internet service - nothing has changed, not even IP. Trunk registration shows green, 6 channels, the phones attached to the PBX no problem, and it’s been up for weeks without issue. The billing cycle hasn’t even completed yet and I know the card used is good. What else could it be that’s doing this? I even rebooted the asterisk server to see if that would somehow clear it up and it came back and seems happy as ever - except that the situation stays the same, calls out say circuits are busy and calls in get a busy signal.
Some recent log messages from /var/log/asterisk/full are as follows, and looks like the problem may exist on the provider end of things. Is there anything I can do?
– Executing [s@macro-dialout-trunk:20] Dial(“SIP/333-00000009”, “SIP/fpbx-2-f81014a1/12102795544,300,”) in new stack
[2011-09-29 16:03:00] VERBOSE[4641] netsock2.c: == Using SIP RTP TOS bits 184
[2011-09-29 16:03:00] VERBOSE[4641] netsock2.c: == Using SIP RTP CoS mark 5
[2011-09-29 16:03:00] VERBOSE[4641] app_dial.c: – Called fpbx-2-f81014a1/12102795544
[2011-09-29 16:03:00] VERBOSE[3087] chan_sip.c: – Got SIP response 480 “Temporarily Unavailable” back from 50.56.59.168:5060
[2011-09-29 16:03:00] VERBOSE[4641] app_dial.c: – SIP/fpbx-2-f81014a1-0000000b is circuit-busy
[2011-09-29 16:03:00] VERBOSE[4641] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2011-09-29 16:03:00] VERBOSE[4641] pbx.c: – Executing [s@macro-dialout-trunk:21] NoOp(“SIP/333-00000009”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 19”) in new stack
[2011-09-29 16:03:00] VERBOSE[4641] pbx.c: – Executing [s@macro-dialout-trunk:22] Goto(“SIP/333-00000009”, “s-CONGESTION,1”) in new stack
The only contact method they provide is via email (regardless of support need - tech vs sales, etc), which I have used and given them the same log excerpt used here. The auto-responder indicates an SLA of 24hrs, since it arrived a couple minutes after 5pm EST.
There server is up, it is actually sending back a temp unavailable message.
They are not much of a provider, just running a server at rackspace (I did a trace route on the IP).
I would consider a more responsive provider.
There server is up, it is actually sending back a temp unavailable message.
They are not much of a provider, just running a server at rackspace (I did a trace route on the IP).
Nothing works. inbound goes straight to busy signal, outbound gets the ‘all circuits are busy’ message, or I saw one recently go by from one of the night staff saying that call from extension 75 was rejected because it could not be found in the context ‘from internal’.
So if this is some sub-contracted provider, how do I figure out who my trunks actually go through and get OFF them so I can get this system working again?
That’s a slicehost account at rackspace (the IP you provided) unless I made a type.
I would find it hard to believe that bandwidth servers are on shared servers at Rackspace. Maybe this is a downstream local provide. Are all calls failing? Does inbound work?
No - that was a call from an internal extension (device 75 is a desk in the sleep lab) trying to call out and getting rejected because it was not part of the ‘from internal’ context. I have never messed with the contexts, steered well clear and didn’t even install the ‘custom context’ module.
It’s possible that part may be mucked up because I tried to purge/recreate my trunk/route configurations in hopes that it might kick something loose, but still no dice and I will have to look at it in the morning. For now we are dead in the water and the problem started around 4pm out of the blue killing off both dial-in and dial-out ability, and the logs were spitting out that ‘all circuits busy’ message.
The trunks are funneled through gateways - ‘trunk1.phonebooth.net’ and ‘trunk2.phonebooth.net’ - the SIPSTATION module only registers the two gateways but acknowledges six ‘channels’ (which normally are individual trunks, if I understand right).
When asterisk starts up, it registers with the two gateways I mentioned above and creates two trunks using a username-hash that is auto-generated and configured by the sipstation module using a provided key that came from the store/account-info URL I mentioned above. These two trunks have - up until now - worked with up to the 6 channel limit without issue (except for overriding in-progress calls that I was asking for help about before).
It really did go all quite well when it was first activated and put together, but seems to have gone belly up today. I’ve tried to report a problem to them but the only method possible is via ‘[email protected]’ - the only way to reach a person is via a phone number provided for service cancellation, or via their ‘professional services’ group for $150/hr and the problem there is that it’s not my problem, it’s outside me.
Man that’s frustrating, hopefully this will get resolved soon. You could get outbound up and running fairly quickly with one of the PAYG (pay-as-you-go) providers. Voip.ms, Callcentric, Voxbeam come to mind, but there are plenty of others. Yes it will cost a few bucks, but many have low minimums plus having a secondary provider is a good idea. And PAYG means no recurring charges and you can sit on whatever balance you have.
This won’t help your inbound, although does Sipstation provide an online dashboard with an option to (at least temporarily) forward inbound until this gets worked out?
If they have an inbound forwarding option, that would be great if I could get outbound up on an alternate provider. The office runs primarily off of one number (it’s all IVR and extensions when someone calls) so that would be great.
I don’t use Sipstation so I don’t know what ability they have to manage your account online. Forwarding to someone in the office’s cell would be the easiest option in this situation. Some of the PAYG providers can have you up and making outbound calls in minutes after signing up, although most will restrict the number of channels until the account is verified. $25 (or less) should be about the most you should spend initially.
One thought- does Sipstation use user/password authentication (are there username, secret fields in the trunk peer details?) or IP authentication? If the ISP changed the IP & Sipstation uses IP auth, that would cause failures.