PRI and busy trunks

Hi,

I have two PRIs (23B+1D each) defined as trunks g0 and g1 on a FPBX 2.7 running 1.6.2.11 and DAHDI 2.4.0. The 9_outside route is typical other than I have both trunks defined in it. Calls can be made on either and received on either under normal circumstances.

When the first PRI is full, the DIAL will get snagged like:

[Nov 3 15:11:32] VERBOSE[7712] pbx.c: -- Executing [[email protected]:19] Dial("SIP/3909-0000ae44", "DAHDI/g1/18124730200,300,W") in new stack [Nov 3 15:11:32] VERBOSE[7712] chan_dahdi.c: -- Requested transfer capability: 0x00 - SPEECH [Nov 3 15:11:32] VERBOSE[7712] app_dial.c: -- Called g1/18888888887 [Nov 3 15:11:33] VERBOSE[7712] app_dial.c: -- DAHDI/36-1 is proceeding passing it to SIP/3909-0000ae44 ... [Nov 3 15:11:36] VERBOSE[14307] chan_dahdi.c: -- Channel 0/12, span 2 got hangup request, cause 17 [Nov 3 15:11:36] VERBOSE[7712] app_dial.c: -- DAHDI/36-1 is busy [Nov 3 15:11:36] VERBOSE[7712] chan_dahdi.c: -- Hungup 'DAHDI/36-1' [Nov 3 15:11:36] VERBOSE[7712] app_dial.c: == Everyone is busy/congested at this time (1:1/0/0) [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:20] NoOp("SIP/3909-0000ae44", "Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 17") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:21] Goto("SIP/3909-0000ae44", "s-BUSY,1") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Goto (macro-dialout-trunk,s-BUSY,1) [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:1] NoOp("SIP/3909-0000ae44", "Dial failed due to trunk reporting BUSY - giving up") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:2] PlayTones("SIP/3909-0000ae44", "busy") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:3] Busy("SIP/3909-0000ae44", "20") in new stack [Nov 3 15:11:36] VERBOSE[7712] app_macro.c: == Spawn extension (macro-dialout-trunk, s-BUSY, 3) exited non-zero on 'SIP/3909-0000ae44' in macro 'dialout-trunk' [Nov 3 15:11:36] VERBOSE[7712] pbx.c: == Spawn extension (from-internal, 918888888887, 5) exited non-zero on 'SIP/3909-0000ae44' [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:1] Macro("SIP/3909-0000ae44", "hangupcall") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:1] GotoIf("SIP/3909-0000ae44", "1?skiprg") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Goto (macro-hangupcall,s,4) [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:4] GotoIf("SIP/3909-0000ae44", "1?skipblkvm") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Goto (macro-hangupcall,s,7) [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:7] GotoIf("SIP/3909-0000ae44", "1?theend") in new stack [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Goto (macro-hangupcall,s,9) [Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [[email protected]:9] Hangup("SIP/3909-0000ae44", "") in new stack [Nov 3 15:11:36] VERBOSE[7712] app_macro.c: == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/3909-0000ae44' in macro 'hangupcall' [Nov 3 15:11:36] VERBOSE[7712] pbx.c: == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/3909-0000ae44'

If the call to g1 fails, shouldn’t it then try g0 (or whatever trunks are enumerated in the GUI) before failing the call.

Also, the PlayTones doesn’t happen for our users either. This is probably a different issue.

Will the dialplan only crawl through the trunks if the trunks are down? I’m presuming if I had analog trunks the busy detect would work.

At no point have both trunks been full (as determined using this code): /usr/sbin/asterisk -rnx 'core show channels' 2>/dev/null | \ /bin/grep -c '^DAHDI'

Ideas?

i have never had problems with them all in one group. i have some where there are 8 in a group.

the only reason to have them separate is when you have different purposed PRIs …eg… one with some super LD rate , one with a super international rate etc …so it makes a difference how you route your outbound calls.

I put them in separate groups because they are separate D channels and I thought I might, someday, want to use them differently. Now I wish they were both in the same group – but wouldn’t the problem still exist? Or, does DAHDI handle multiple trunks better than FPBX handles DAHDI?

not a direct answer but if everything is interchangeable, why not just put both PRIs into the same group?