All circuits are busy

Hi,

I have the Sangoma S500’s and have set up a new installation, everything seems to be working apart from when I lift the handset to make a call sometimes it dials and other times it says all circuits are busy, so it only happens intermittently its almost like it is struggling to find an outside line but we have 2 isdn’s so 4 lines. The incoming calls are fine. I am really confused can anyone please help?

I am using Freepbx 13.0.190.19

Thanks

Not without logs. We need you to show us what happens from the time you dial till the message comes up.

Does this help?

To: “100” sip:[email protected]:5160;tag=c9f0c2a94ed4e32
Call-ID: [email protected]
CSeq: 505 NOTIFY
User-Agent: Sangoma S500 V2.0.4.15
Allow: INVITE, ACK, UPDATE, INFO, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, PRACK
Content-Length: 0

<------------->
[2017-02-21 17:10:13] VERBOSE[24154] chan_sip.c: — (9 headers 0 lines) —
[2017-02-21 17:10:13] VERBOSE[24154] chan_sip.c:
<— SIP read from UDP:10.10.10.149:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.137:5160;branch=z9hG4bK480ee3fb
From: sip:[email protected]:5160;tag=as31ab7565
To: “100” sip:[email protected]:5160;tag=445accec384ae76
Call-ID: [email protected]
CSeq: 506 NOTIFY
User-Agent: Sangoma S500 V2.0.4.15
Allow: INVITE, ACK, UPDATE, INFO, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, PRACK
Content-Length: 0

<------------->
[2017-02-21 17:10:13] VERBOSE[24154] chan_sip.c: — (9 headers 0 lines) —
[2017-02-21 17:10:13] VERBOSE[24154] chan_sip.c:
<— SIP read from UDP:10.10.10.149:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.137:5160;branch=z9hG4bK4f9a16ab
From: sip:[email protected]:5160;tag=as2fdf6ef5
To: “100” sip:[email protected]:5160;tag=fbe015b0718f77f
Call-ID: [email protected]
CSeq: 481 NOTIFY
User-Agent: Sangoma S500 V2.0.4.15
Allow: INVITE, ACK, UPDATE, INFO, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, PRACK
Content-Length: 0

<------------->
[2017-02-21 17:10:13] VERBOSE[24154] chan_sip.c: — (9 headers 0 lines) —
[2017-02-21 17:10:13] VERBOSE[24156][C-00000102] sig_pri.c: Span 2: Channel 0/2 got hangup request, cause 41
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] app_dial.c: DAHDI/i2/07966661776-80 is circuit-busy
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_dahdi.c: Hungup ‘DAHDI/i2/07966661776-80’
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [s@macro-dialout-trunk:24] NoOp(“SIP/100-0000017a”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 41”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [s@macro-dialout-trunk:25] GotoIf(“SIP/100-0000017a”, “0?continue,1:s-CONGESTION,1”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx_builtins.c: Goto (macro-dialout-trunk,s-CONGESTION,1)
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [s-CONGESTION@macro-dialout-trunk:1] Set(“SIP/100-0000017a”, “RC=41”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [s-CONGESTION@macro-dialout-trunk:2] Goto(“SIP/100-0000017a”, “41,1”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx_builtins.c: Goto (macro-dialout-trunk,41,1)
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [41@macro-dialout-trunk:1] Goto(“SIP/100-0000017a”, “continue,1”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx_builtins.c: Goto (macro-dialout-trunk,continue,1)
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [continue@macro-dialout-trunk:1] NoOp(“SIP/100-0000017a”, “TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 41 - failing through to other trunks”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [continue@macro-dialout-trunk:2] ExecIf(“SIP/100-0000017a”, “1?Set(CALLERID(number)=100)”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [07966661776@from-internal:8] Macro(“SIP/100-0000017a”, “outisbusy,”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] pbx.c: Executing [s@macro-outisbusy:1] Progress(“SIP/100-0000017a”, “”) in new stack
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_sip.c: Audio is at 11002
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_sip.c: Adding codec ulaw to SDP
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_sip.c: Adding codec alaw to SDP
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_sip.c: Adding codec g726 to SDP
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP
[2017-02-21 17:10:13] VERBOSE[3435][C-00000102] chan_sip.c:
<— Transmitting (no NAT) to 10.10.10.149:5060 —>

It’s not a complete answer, but you need to figure out why your Span2 Channel 0 is hanging up as soon as you start to dial it. @dicko might help you out here - he’s a DAHDI guru.

There are lots of things that it could be. I’d start by Googling “DAHDI hangup code 41”. Now, the fact that it’s your first line on your second trunk, there might be something in the trunk definition that’s jamming you up. I’d troubleshoot the second interface and make sure it’s working properly. I noticed that it also didn’t fail over to your second line on the second interface, so there’s something going on there.

Well it’s not dahdi per se, it is dahdi’s signalling over ISDN PRI’s (Q931) of which a reference:-

So, colloquially

http://networking.ringofsaturn.com/Routers/isdncausecodes.php

look for cause 41, which basically means that although you have a connection to your PRI provider, they can’t route that call currently, the only recourse is with said “Provider”, They will almost certainly disagree with you but from the asterisk CLI

pri set debug on span 1

should give them something to chew on. If you want to get “intense” , then

pri set debug intense span 1

more to chew on.

Good Luck, you might need it :wink:

Hi:
you have to make sure:

  1. PRI is up and active
  2. check with service provider for the outbound callerid and pridialplan if necessary.
2 Likes

Thanks I will look into it.

I remember when I first set up the system I had the same problem and changed a setting somewhere but I cannot remember what I had changed. The other day there was some problem with Dadhi and I had to restart, but after that we are having the problem. The lines are fine according to my service provider, they have checked and done a full line test.

Any other ideas as to why we might not be able to dial out? I also noticed that if we manually select the line button on the phones we are able to make calls not on the same line buttons but if we just keep on randomly pressing them we can dial out!

What did the pri log report on a failed call?