[asterisk-users] Autofallthrough delays before hanging up calling channel?

[Tony Mountifield]

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