asterisk users - Nov 2012 - Simultaneous caller/callee hangup; hangup extensions execute only once; unable to determine if destination channel up

Hello

This is a question regarding whether there's any way within hangup 
extensions to determine whether the caller or callee leg (or both) of a 
bridged call has hung up.  The test case I have is running under 
Asterisk 1.8.17.0, but the behaviour is observed in 1.8.18.0 (and also 
1.6.2.18).

Within the dialplan, the Dial() application with the "F" flag, so that
once the caller hangs up, the dialplan jumps to a new priority which 
enables the called party to enter some digits which describe the outcome 
of the call.  Also, the "g" flag is used to attempt to continue 
execution of the dialplan if the called party hangs up.

Minimally, the dialplan is covered by the following:

[test]
exten => _1000,1,Set(_CALLER_HUNGUP=false)
exten => _1000,2,Set(_CALLEE_HUNGUP=false)
exten => _1000,3,Dial(SIP/${EXTEN},60,CgF(test^1000^10))
exten => _1000,4,Set(_CALLEE_HUNGUP=true)

exten => _1000,10,Set(_CALLER_HUNGUP=true)
exten => _1000,11,AGI(afterCallWork.agi)

exten => h,1,NoOp(${CALLER_HUNGUP})
exten => h,2,NoOp(${CALLEE_HUNGUP})
exten => h,3,AGI(postCall.agi)


Normally, the hangup extensions execute twice: once when the caller 
hangs up, then once more when the called party hangs up, either during 
or after the execution of afterCallWork.agi.  This second call is 
important so that clean up can be performed.

However, if the two parties hang up simultaneously (or within a 
split-second of each other), I often see only one execution of the 
hangup extensions.  Stranger still, the hangups can occur so close to 
each other that execution of the hangup extension occurs without the 
either the priority 4 or priority 10 steps being executed (it can be 
difficult replicate this, but inserting a Wait(1) call at priority 4 and 
another at priority 10 can help here).

In such cases, I see the output from the two NoOps as false and false.  
(This is difficult to replicate because of the precise timing it 
requires - it is easy if you insert Wait(1) at priority 4 and 10, but 
whether this is valid or not is debatable.  I can replicate this issue 
with just the dialplan above on a slowish server).

So I need to be able to query the status of the other channel from 
within postCall.agi, because if both parties have hung up, I may only 
get one execution of the hangup extensions, and I can go ahead and 
perform the cleanup.  Is this possible?  I've tried calling CHANNEL 
STATUS for the destination channel within postCall.agi, but even when 
the destination channel is definitely still up, the call returns an 
error "511 Command Not Permitted on a dead channel" (presumably
because
the current (caller) channel has hung up).

I can't find anything that I can use within the execution of the hangup 
extensions for the caller to determine whether the destination channel 
is still up.

Is it a bug that I only get the one call to the hangup extensions when 
both caller and callee channels hangup so close to each other that 
neither the "F" nor "g" flags have the desired effect?

Thanks in advance for any help.

John Hurst

> This is a question regarding whether there's any way within hangup
> extensions to determine whether the caller or callee leg (or both) of
> a
> bridged call has hung up.  The test case I have is running under
> Asterisk 1.8.17.0, but the behaviour is observed in 1.8.18.0 (and
> also
> 1.6.2.18).
> 
> Within the dialplan, the Dial() application with the "F" flag, so
> that
> once the caller hangs up, the dialplan jumps to a new priority which
> enables the called party to enter some digits which describe the
> outcome
> of the call.  Also, the "g" flag is used to attempt to continue
> execution of the dialplan if the called party hangs up.
> 
> Minimally, the dialplan is covered by the following:
> 
> [test]
> exten => _1000,1,Set(_CALLER_HUNGUP=false)
> exten => _1000,2,Set(_CALLEE_HUNGUP=false)
> exten => _1000,3,Dial(SIP/${EXTEN},60,CgF(test^1000^10))
> exten => _1000,4,Set(_CALLEE_HUNGUP=true)
> 
> exten => _1000,10,Set(_CALLER_HUNGUP=true)
> exten => _1000,11,AGI(afterCallWork.agi)
> 
> exten => h,1,NoOp(${CALLER_HUNGUP})
> exten => h,2,NoOp(${CALLEE_HUNGUP})
> exten => h,3,AGI(postCall.agi)
> 
> 
> Normally, the hangup extensions execute twice: once when the caller
> hangs up, then once more when the called party hangs up, either
> during
> or after the execution of afterCallWork.agi.  This second call is
> important so that clean up can be performed.
> 
> However, if the two parties hang up simultaneously (or within a
> split-second of each other), I often see only one execution of the
> hangup extensions.  Stranger still, the hangups can occur so close to
> each other that execution of the hangup extension occurs without the
> either the priority 4 or priority 10 steps being executed (it can be
> difficult replicate this, but inserting a Wait(1) call at priority 4
> and
> another at priority 10 can help here).
> 
> In such cases, I see the output from the two NoOps as false and
> false.
> (This is difficult to replicate because of the precise timing it
> requires - it is easy if you insert Wait(1) at priority 4 and 10, but
> whether this is valid or not is debatable.  I can replicate this
> issue
> with just the dialplan above on a slowish server).
> 
> So I need to be able to query the status of the other channel from
> within postCall.agi, because if both parties have hung up, I may only
> get one execution of the hangup extensions, and I can go ahead and
> perform the cleanup.  Is this possible?  I've tried calling CHANNEL
> STATUS for the destination channel within postCall.agi, but even when
> the destination channel is definitely still up, the call returns an
> error "511 Command Not Permitted on a dead channel" (presumably
> because
> the current (caller) channel has hung up).
> 
> I can't find anything that I can use within the execution of the
> hangup
> extensions for the caller to determine whether the destination
> channel
> is still up.
> 
> Is it a bug that I only get the one call to the hangup extensions
> when
> both caller and callee channels hangup so close to each other that
> neither the "F" nor "g" flags have the desired effect?
No.  I don't see this as a bug.  Priority 4 and 10 can only execute
while the channel is not hung up.  This is normal dialplan execution.
Only the h exten can execute on a hung up channel.  Since both
channels are hanging up at the same time, neither priority 4 nor 10
are able to get executed.

The new pre-dial and hangup handler features in Asterisk 11 would
be a solution to your problem.  Otherwise, I don't really see a
solution without rethinking your post call processing.

Richard