asterisk users - Aug 2009 - Autofallthrough delays before hanging up calling channel?

I am seeing some curious behaviour with a 1.2.32 system, which I do not
understand and so can't work out how to fix it.

I have a PRI routed to context default. Here is the complete default
context:

[default]
exten => _9X.,1,Dial(IAX2/m1peer/${EXTEN:1})
exten => _20XX,1,Dial(IAX2/sipeer/${EXTEN})
exten => _X.,1,Dial(IAX2/m1peer/${EXTEN})
exten => _X.,2,NoOp(DIALSTATUS=${DIALSTATUS}:HANGUPCAUSE=${HANGUPCAUSE})
;exten => _X.,3,Hangup

I also have autofallthrough=yes in the [general] section.

The problem occurs when I dial an extension that returns busy. The Dial
returns immediately and goes straight on to the NoOp, which confirms
the busy status, but the system then waits 10 seconds before hanging
up the calling Zap channel, even though autofallthrough is set to yes.

Here is the verbose output:

    -- Accepting call from '' to '2001' on channel 0/1, span 3
    -- Executing Dial("Zap/63-1", "IAX2/sipeer/2001") in new
stack
  == ast_request: Original IAX2 capabilities=65535, fmt=72
  == ast_request: Negotiated IAX2 capabilities=64, fmt=64
    -- Call accepted by 192.168.0.2 (format alaw)
    -- Format for call is alaw
    -- Called sipeer/2001
    -- IAX2/sipeer-9504 is busy
    -- Hungup 'IAX2/sipeer-9504'
  == Everyone is busy/congested at this time (1:1/0/0)
    -- Executing NoOp("Zap/63-1",
"DIALSTATUS=BUSY:HANGUPCAUSE=0") in new stack
  == Auto fallthrough, channel 'Zap/63-1' status is 'BUSY'

Then a 10-second delay before this line:

    -- Hungup 'Zap/63-1'

I thought autofallthrough=yes should make it hangup immediately.

Also, the Zap channel is not receiving BUSY status, but NOANSWER instead.

If I uncomment the Hangup at priority 3, the calling line dies get hung up
immediately, but then the BUSY status still does not get propagated.

Any advice on why this delay occurs with autofallthrough=yes, and how
to eliminate it?

Thanks,
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

In article <h61ftl$nu4$1 at softins.clara.co.uk>,
Tony Mountifield <tony at softins.clara.co.uk>
wrote:
> I am seeing some curious behaviour with a 1.2.32 system, which I do not
> understand and so can't work out how to fix it.
Well, after some looking at pbx.c and some pri debugging, I discovered
what the problem was. See below.
> I have a PRI routed to context default. Here is the complete default
> context:
> 
> [default]
> exten => _9X.,1,Dial(IAX2/m1peer/${EXTEN:1})
> exten => _20XX,1,Dial(IAX2/sipeer/${EXTEN})
> exten => _X.,1,Dial(IAX2/m1peer/${EXTEN})
> exten => _X.,2,NoOp(DIALSTATUS=${DIALSTATUS}:HANGUPCAUSE=${HANGUPCAUSE})
> ;exten => _X.,3,Hangup
> 
> I also have autofallthrough=yes in the [general] section.
> 
> The problem occurs when I dial an extension that returns busy. The Dial
> returns immediately and goes straight on to the NoOp, which confirms
> the busy status, but the system then waits 10 seconds before hanging
> up the calling Zap channel, even though autofallthrough is set to yes.
> 
> Here is the verbose output:
> 
>     -- Accepting call from '' to '2001' on channel 0/1,
span 3
>     -- Executing Dial("Zap/63-1", "IAX2/sipeer/2001")
in new stack
>   == ast_request: Original IAX2 capabilities=65535, fmt=72
>   == ast_request: Negotiated IAX2 capabilities=64, fmt=64
>     -- Call accepted by 192.168.0.2 (format alaw)
>     -- Format for call is alaw
>     -- Called sipeer/2001
>     -- IAX2/sipeer-9504 is busy
>     -- Hungup 'IAX2/sipeer-9504'
>   == Everyone is busy/congested at this time (1:1/0/0)
>     -- Executing NoOp("Zap/63-1",
"DIALSTATUS=BUSY:HANGUPCAUSE=0") in new stack
>   == Auto fallthrough, channel 'Zap/63-1' status is 'BUSY'
> 
> Then a 10-second delay before this line:
> 
>     -- Hungup 'Zap/63-1'
> 
> I thought autofallthrough=yes should make it hangup immediately.
> 
> Also, the Zap channel is not receiving BUSY status, but NOANSWER instead.
The problem was that on the system in question, zapata.conf did not
have the directive priindication=outofband. Consequently, when it did
an auto fallthrough with Busy status, it indicated PROGRESS to the
calling system and played the busy tone in-band, waiting up to ten
seconds for the calling system to initiate the hangup.

The calling system was another Asterisk box with priindication=outofband,
and callprogress detection disabled, so it didn't detect the busy tone.

The solution was to enable priindication=outofband, and then on auto
fallthrough, a busy message was correctly sent via the D-channel and
the calling system hung up immediately with the correct DIALSTATUS.

Hope this helps anyone else who happens to puzzle over the same thing!

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org