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

Richard Mudgett rmudgett at digium.com
Tue Nov 20 11:14:31 CST 2012


> 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



More information about the asterisk-users mailing list