Re: [asterisk-users] Simultaneous caller/callee hangup; hangup extensions execute only once; unable to determine if destination channel up
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
[asterisk-users] 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 -- _ -- 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
Re: [asterisk-users] Simultaneous caller/callee hangup; hangup extensions execute only once; unable to determine if destination channel up
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 -- _ -- 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