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 [s@macro-dialout-trunk: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 [s@macro-dialout-trunk: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 [s@macro-dialout-trunk: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 [s-BUSY@macro-dialout-trunk: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 [s-BUSY@macro-dialout-trunk:2] PlayTones("SIP/3909-0000ae44", "busy") in new stack
[Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [s-BUSY@macro-dialout-trunk: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 [h@from-internal:1] Macro("SIP/3909-0000ae44", "hangupcall") in new stack
[Nov 3 15:11:36] VERBOSE[7712] pbx.c: -- Executing [s@macro-hangupcall: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 [s@macro-hangupcall: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 [s@macro-hangupcall: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 [s@macro-hangupcall: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?