SIP trunk receives calls, cannot place them

Callcentric had a major blow-up the last few days. A sophisticated DDoS attack brought them to their knees.

They have made some adjustments to their network and asked that some settings be adjusted. I have made those changes. And like I said, incoming works great.

When I place a call, I get silence for about 20-30 seconds, then “all circuits are busy” from Asterisk, and when I’m watching via the CLI, I see a “500 network failure” message.

My Asterisk is 1.8.6.0 (running with FreePBX 2.9.0.7).


context=from-pstn
fromuser=17771234567
fromdomain=callcentric.com
host=sip.callcentric.com
outboundproxy=sip.callcentric.com
insecure=port,invite
secret=[my password]
type=peer
defaultuser=17771234567
disallowed_methods=UPDATE
directmedia=no
videosupport=no
disallow=all
allow=ulaw&alaw&gsm

Here is the part of the log file where I get the network error:

[2012-10-05 19:08:27] VERBOSE[4441] pbx.c: – Executing [[email protected]:1] MacroExit(“SIP/205-000000d2”, “”) in new stack
[2012-10-05 19:08:27] VERBOSE[4441] pbx.c: – Executing [[email protected]:18] GotoIf(“SIP/205-000000d2”, “0?bypass,1”) in new stack
[2012-10-05 19:08:27] VERBOSE[4441] pbx.c: – Executing [[email protected]:19] GotoIf(“SIP/205-000000d2”, “0?customtrunk”) in new stack
[2012-10-05 19:08:27] VERBOSE[4441] pbx.c: – Executing [[email protected]:20] Dial(“SIP/205-000000d2”, “SIP/Callcentric/14144568000,300,W”) in new stack
[2012-10-05 19:08:27] VERBOSE[4441] netsock2.c: == Using SIP RTP TOS bits 184
[2012-10-05 19:08:27] VERBOSE[4441] netsock2.c: == Using SIP RTP CoS mark 5
[2012-10-05 19:08:27] VERBOSE[4441] app_dial.c: – Called SIP/Callcentric/14144568000
[2012-10-05 19:09:08] VERBOSE[2928] chan_sip.c: – Got SIP response 500 “Network Failure” back from 204.11.192.37:5060
[2012-10-05 19:09:08] VERBOSE[4441] app_dial.c: – SIP/Callcentric-000000d3 is circuit-busy
[2012-10-05 19:09:08] VERBOSE[4441] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2012-10-05 19:09:08] VERBOSE[4441] pbx.c: – Executing [[email protected]:21] NoOp(“SIP/205-000000d2”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 38”) in new stack
[2012-10-05 19:09:08] VERBOSE[4441] pbx.c: – Executing [[email protected]:22] Goto(“SIP/205-000000d2”, “s-CONGESTION,1”) in new stack
[2012-10-05 19:09:08] VERBOSE[4441] pbx.c: – Goto (macro-dialout-trunk,s-CONGESTION,1)


I probably have something configured wrong for the trunk. All I did was basically take the two lines they wanted added to the configuration and added them. Not sure if I have to make any other changes.

Not so much ISDN cause 38 :-

Cause No. 38 - network out of order.
This cause indicates that the network is not functioning correctly and that the condition is likely to last a relatively long period of time e.g., immediately re-attempting the call is not likely to be successful.

2012-10-05 19:09:08] VERBOSE[2928] chan_sip.c: – Got SIP response 500 “Network Failure” back from 204.11.192.37:5060

whois 204.11.192.37

will tell you it is CallCentric, In other words it there problem and all you can do is look at the SLA yu have with them for recompense.

I appreciate the confirmation that the problem isn’t mine.

People using non-Asterisk devices seem to be able to use the new settings and make/take calls.

I guess they (Callcentric) are still working on these issues. Hopefully they will alter their config this weekend, or at least provide alternative instructions that will make it work.

Thanks for looking at it for me!

It is possible that SIP 500, which will be normally mapped to ISDN 38, is erroneous from your provider infortunately you will have to wait for them to provide an alternative SIP setup for you as there are about 10000 things they could get be getting wrong. There is nothing you can do but get pissed off with them until they fix it. Please get pissed off with them, they broke it they need to fix it!!

Had a couple of calls go through now, I didn’t change anything on my end. Very poor call quality. Obviously Callcentric is still recovering from the DDoS attack. For all I know, the attack is still underway.