Occasionally "all circuits are busy now", altough enough lines are available

General Help
1

Hello,

occasionally our users report getting “all circuits are busy now”, although we have enough lines available.

We have 4 ISDN channels, so 8 parallel calls should be possible:

voip*CLI> dahdi show channels
Chan Extension Context Language MOH Interpret Blocked State Description
pseudo default default In Service
1 from-digital de default In Service
2 from-digital de default In Service
4 from-digital de default In Service
5 from-digital de default In Service
7 from-digital de default In Service
8 from-digital de default In Service
10 from-digital de default In Service
11 from-digital de default In Service

Log Excerpt:
[2015-01-26 10:03:43] VERBOSE[2373] chan_sip.c: Really destroying SIP dialog ‘[email protected]:5060’ Method: OPTIONS
[2015-01-26 10:03:44] VERBOSE[2407][C-000011b6] sig_pri.c: – Span 1: Channel 0/1 got hangup request, cause 34
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] app_dial.c: – DAHDI/i1/0177XXXXXXX-532 is circuit-busy
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] chan_dahdi.c: – Hungup ‘DAHDI/i1/0177XXXXXXX-532’
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] pbx.c: – Executing [s@macro-outisbusy:2] GotoIf(“SIP/43-00001bf6”, “0?emergency,1”) in new stack
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] pbx.c: – Executing [s@macro-outisbusy:3] GotoIf(“SIP/43-00001bf6”, “0?intracompany,1”) in new stack
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] pbx.c: – Executing [s@macro-outisbusy:4] Playback(“SIP/43-00001bf6”, “all-circuits-busy-now&pls-try-call-later, noanswer”) in new stack
[2015-01-26 10:03:44] VERBOSE[10836][C-000011b6] file.c: – <SIP/43-00001bf6> Playing ‘all-circuits-busy-now.slin’ (language ‘de’)

I checked the given time and there was only 1 incoming call at this time, so I don’t understand why it gives me “all circuits are busy now”. A few seconds later another try the call worked. It happens rarely, but often enough to annoy users.

Any Idea to dig into this problem?

2

search this space for ‘glare’

3

So the problem may be collision. I’ll try to use trunk G0 instead of g0 with Group 0 Descending then.

Although I don’t understand why the freepbx wiki states collision on analog lines. As far as I understand, ISDN is not analog actually.

Maybe it helps.

4

Well. that’s true but you have multiple BRI’s so they are granular by only two not eight, the d-channel is the arbitrator of available b-channels within that span, and there are many variations of ISDN signalling choices that can and will occasionally throw up a “glare” condition, perhaps if a simultaneous inbound call appears on the d-channel, you are clean out of b-channels and you loose :wink: , you will even see that less occasionally on PRI’s, but they have more redundancy so tend to recover to another b-channel without call loss, it is always good policy to have your outbound calls hunt conversely to your inbound calls both within the span and within the “group” container.