Debugging SIP Trunk Issues

Tags: #<Tag:0x00007f7020523518>

(Mark Moore) #1

We just had a a strange interruption to out service. Everything has been working great. There have been no updates or changes at all to FreePBX/Asterisk. All the endpoints are working, registered (have service), and can place calls internally.

Unfortunately and out of the blue, we started getting a strange “Q.850; cause=17” message whenever we tried to dial an out side line. (FWIW, all our phones are Yealink, mostly T27G and T48G.)

At the same time we started getting complaints (over cell and email) that people cannot call in as well.

I do not see anything wrong on the FreePBX Dashboard, nor on the SIP provider’s status board. So, I rebooted our server just to se if that would clear the issue.

It didn’t. After a long but regular reboot, all of the endpoints successfully (re)registered, and for a minute or so I could still get the Q.850; cause=17 error.

Now, the Q.850 message does not show up anymore, but when trying to dial out, it emadiately goes to the “All circuits are busy now. Please try your call again later” voice message. And, when trying to dial in on any of the DIDs, it just give busy signal.

Does anyone have any ideas on what logs I can look at or where else I might spelunk in oredr to find what’s failing?

Every things looks just fine, except it isn’t. :frowning:


(Jared K Smith) #2

Here are some instructions for providing additional information that will make your problem easier to debug:

(Mark Moore) #3

Thank you for the link Jared

(Mark Moore) #4

I was able to ssh into the PBX server and astrisk -rvv a little. Here’s what I got when I tried to dial out to my cell at 408-489-4272:

Connected to Asterisk 13.29.2 currently running on pbx (pid = 3016)
  == Setting global variable 'SIPDOMAIN' to ''
  == Using SIP RTP Audio TOS bits 184
  == Using SIP RTP Audio TOS bits 184 in TCLASS field.
  == Using SIP RTP Audio CoS mark 5
  == Begin MixMonitor Recording PJSIP/241-00000033
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
  == Spawn extension (from-pstn, 4084894272, 1) exited non-zero on 'SIP/fpbx-1-wmC0GUs9YwRo-00000060'
  == Everyone is busy/congested at this time (1:1/0/0)
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
  == Spawn extension (from-pstn, 4084894272, 1) exited non-zero on 'SIP/fpbx-2-wmC0GUs9YwRo-00000061'
  == Everyone is busy/congested at this time (1:1/0/0)
  == Spawn extension (macro-hangupcall, s, 7) exited non-zero on 'PJSIP/241-00000033' in macro 'hangupcall'
  == Spawn extension (from-internal, h, 1) exited non-zero on 'PJSIP/241-00000033'
  == MixMonitor close filestream (mixed)
  == End MixMonitor Recording PJSIP/241-00000033

It clearly says “Everyone is busy/congested at this time”, but there are no active lines.

It sure seems like an issue with the SIP provider, but as I mentioned before, their status page says everying is nominal.

Any ideas?


At the Asterisk command prompt, type
sip set debug on
then make a test call. The SIP traffic will appear in the Asterisk Log, along with the normal entries. Paste the relevant section at and post the link here.


“from-pstn” is the context for an inbound call, not an outbound. My initial hunch then is that this is a local call routing problem, not a problem with your provider.

(Mark Moore) #7


In both tries, the provider rejected the call; see paste lines 130 (Temporarily Unavailable) and 290 (SOFTCAP EXCEEDED).

One possibility is you exceeded the allowed minutes for the trunk and Concurrency Bursting is not enabled. See . If it’s not presently enabled, try enabling it and see if that allows your calls to go through. If so, but you didn’t have much usage, it’s possible that your system was hacked into (check your CDRs for unusual calls) or there is an accounting problem at Sangoma (contact their support).

I noticed that you are sending your caller ID as 11 digits (1877xxxxxxx). The Wiki examples show 10 digits and it’s conceivable that they are being fussy about that. You could also try dialing the call using 11 digits.

If none of the above is useful, open a ticket with Sangoma and include your SIP traces in an attachment.

On incoming, I get a reorder tone. If you have failover set up on the SIPStation portal, since that isn’t working either, that would definitely point to a problem with the account. Test whether enabling bursting allows incoming to work.

(Mark Moore) #9

Concurrency Bursting is enabled, and we are nowhere near our limits. I can provide screenshots if you let me know what would be convinging.

The CDR report is normal as ever. In fact a little slow since there are no incoming calls. Only 50 events over the last 3 hours.

The debug log is precisely why it looks to me like a SIPStation issue. Unfortunately, their sales dept is closed until Monday, so I can’t buy a support package to get someone there to check their side. :frowning:

FWIW, I tried dialing the 11 digits and it didn’t work any better.


I know almost nothing about SIPStation, but here are some general ideas that might be useful:

I assume that they have some call detail or history that you can view on their portal. Do your failed calls show up there (either incoming or outgoing)? If so, there may be some status code or other info that may tell what they think is wrong. If not, what’s the date/time of the last call? That may give a clue as to what might have changed?

Anything useful on the billing side of their portal? Perhaps a payment didn’t get processed and they think you’re past due.

I believe that some support is bundled with the trunking service. Have you tried to open a ticket?

I tried to look up how you may be able to work around the problem and get back up right away, but I’m seeing strange (perhaps incorrect) data. Your 480 number comes up as Comcast on both and . If that’s correct, are you forwarding to a different number that’s with SIPStation? If so, you can change the forwarding at Comcast to a new DID that you can get immediately from another provider.

How about the 877 numbers? They show up as InContact (Nice). Is that correct? If so, are they being forwarded to a different number? If so, you could reroute them also.

(system) closed #11

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.