PRI Dial when channel hanging up

[TechnicalJohn]

Here's my current config:
* Running Asterisk Version : Asterisk 1.4.21.2
* Asterisk Source Version : 1.4.21.2
* Zaptel Source Version : 1.4.12.1
* Libpri Source Version : 1.4.7
* Addons Source Version : 1.4.7

I have a Digium TE122 connected to T1 with 23 channels. I also have a Vitelity trunk for backup.

Everything works fine most of the time, but of course there's an intermittent problem. If a call is finished and Asterisk is hanging up the channel, and at the same second an outgoing call is initiated then the outgoing call will fail resulting in Asterisk rolling over to the Vitelity trunk. I turned on PRI Debug and here's the relevant parts of the log:

[2009-10-01 08:18:00] VERBOSE[24594] logger.c: q931.c:3784 q931_receive: call 33462 on channel 21 enters state 12 (Disconnect Indication)
[2009-10-01 08:18:00] VERBOSE[24594] logger.c: -- Channel 0/21, span 1 got hangup request, cause 18
[2009-10-01 08:18:00] DEBUG[27059] chan_zap.c: Set option AUDIO MODE, value: ON(1) on Zap/21-1
[2009-10-01 08:18:00] DEBUG[27059] chan_zap.c: Not yet hungup... Calling hangup once with icause, and clearing call
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: q931.c:2925 q931_release: call 33462 on channel 21 enters state 19 (Release Request)
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: > Protocol Discriminator: Q.931 (8) len=9
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: > Call Ref: len= 2 (reference 694/0x2B6) (Originator)
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: > Message type: RELEASE (77)
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: > [08 02 81 92]
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: > Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0 Location: Private network serving the local user (1)
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: > Ext: 1 Cause: No user responding (18), class = Normal Event (1) ]
[2009-10-01 08:18:00] DEBUG[27059] chan_zap.c: Set option AUDIO MODE, value: OFF(0) on Zap/21-1
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: -- Hungup 'Zap/21-1'
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: == Everyone is busy/congested at this time (1:0/0/1)
[2009-10-01 08:18:00] DEBUG[27059] app_macro.c: Executed application: Dial
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: -- Executing [s@macro-dialout-trunk:20] Goto("SIP/1234-b7c61cc0", "s-CHANUNAVAIL|1") in new stack
[2009-10-01 08:18:00] VERBOSE[27059] logger.c: -- Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)

And then after the dial command has started...

[2009-10-01 08:18:00] VERBOSE[24594] logger.c: < Protocol Discriminator: Q.931 (8) len=5
[2009-10-01 08:18:00] VERBOSE[24594] logger.c: < Call Ref: len= 2 (reference 694/0x2B6) (Terminator)
[2009-10-01 08:18:00] VERBOSE[24594] logger.c: < Message type: RELEASE COMPLETE (90)
[2009-10-01 08:18:00] VERBOSE[24594] logger.c: q931.c:3724 q931_receive: call 33462 on channel 21 enters state 0 (Null)
[2009-10-01 08:18:00] VERBOSE[24594] logger.c: NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
[2009-10-01 08:18:00] VERBOSE[24594] logger.c: NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null

Notice the time stamp, all this happens during the same second (of course must be different milliseconds).

This problem has been there since I installed the system, but it was so intermittent and I didn't have time until now to devote some time to diagnosing the symptoms.

So here are my questions:

• Is this a bug that has been fixed in Asterisk or libpri or zaptel?
  • If so, what's the best method to upgrade so I don't get dahdi(or is dahdi safe now)?
• Is this some sort of configuration problem with zapata or zaptel?

My initial thought was to try to create a second ZAP trunk that the dial command would fail over to, but I thought twice about that and figured it would do the same thing since it seems that the whole span is being held up until the channel gets cleared.

Thanks for any help or pointers in the right direction.

 

[jmullinix]

One thing to try would be to change the trunk definition in FreePBX to a big "G". You probably have Zap (Dahdi) trunk g0 on the machine now. Change that to G0.

The upper-case "G" tells Asterisk to start at channel 23 and work down on outbound calls. The lower-case "g" starts at channel 1 and works up.

 

[TechnicalJohn]

That's one of the first things I did because I did notice that incoming calls were starting from channel 1 and so the problem was more frequent. It did help to decrease the frequency of collisions.

However, after I made the change to "G", I monitored the logs for a day or so and noticed the behavior that I posted. It's not that incoming calls are colliding with outgoing, but that ending outgoing calls are colliding with new outgoing calls.

So any other ideas?