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

[John Hurst]

On 20/11/12 17:14, Richard Mudgett wrote:
>> 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
>
> --
>

Thanks for the info Richard.  I guess we need to be looking at Asterisk 11.
Is there no way to determine whether another channel is up from within 
an h exten?

Thanks again

John
Signature
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20121121/9d17333c/attachment-0001.htm>