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
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
