David P
2018-Jun-05 06:33 UTC
[asterisk-users] How to execute priorities following a caller hangup in a successful Dial?
We're using Asterisk 14.7.6 and I have a dialplan that ends like this: same => n,Dial(SIP/${EXTEN:0:4}@peer1) same => n,Set(GLOBAL(EpochAtCallEnd)=${EPOCH}) same => n,Hangup() When peer1 hangsup, the priorities after the Dial are executed fine. But when the caller hangsup during the Dial, the cleanup steps aren't done. Why? I did read "Note that on a successful connection, in the absence of the g and G modifiers (below), the Dial command does not return to allow execution of further commands for that extension in that context." at https://www.voip-info.org/asterisk-cmd-dial/ But it seems not to apply because I'm seeing the 'g' behavior without specifying that option, and the 'G' option seems intended for a far more complicated scenario. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180604/18175e1b/attachment.html>
Antony Stone
2018-Jun-05 08:21 UTC
[asterisk-users] How to execute priorities following a caller hangup in a successful Dial?
On Tuesday 05 June 2018 at 08:33:26, David P wrote:> We're using Asterisk 14.7.6 and I have a dialplan that ends like this: > > same => n,Dial(SIP/${EXTEN:0:4}@peer1) > same => n,Set(GLOBAL(EpochAtCallEnd)=${EPOCH}) > same => n,Hangup() > > When peer1 hangsup, the priorities after the Dial are executed fine. But > when the caller hangsup during the Dial, the cleanup steps aren't done. > Why? > > I did read "Note that on a successful connection, in the absence of the g > and G modifiers (below), the Dial command does not return to allow > execution of further commands for that extension in that context." at > https://www.voip-info.org/asterisk-cmd-dial/ But it seems not to apply > because I'm seeing the 'g' behavior without specifying that option, and the > 'G' option seems intended for a far more complicated scenario.If you're getting "g" functionality without specifying it, congratulations. If you want something similar when the callER hangs up, you want to use the F option. Regards, Antony. -- The truth is rarely pure, and never simple. - Oscar Wilde Please reply to the list; please *don't* CC me.
David P
2018-Jun-05 09:33 UTC
[asterisk-users] How to execute priorities following a caller hangup in a successful Dial?
Thanks, Anthony. I added both 'g' and 'F' options. Now, when the caller hangs-up, my cleanup code is run by both the caller channel and the peer channel, but I only want the caller channel to do that. Also, when the peer hangs-up, there is no execution of the priorities following the Dial. Finally, is there a way to reset all globals, maybe as a variant of "dialplan reload"? On Tue, Jun 5, 2018 at 1:21 AM, Antony Stone < Antony.Stone at asterisk.open.source.it> wrote:> On Tuesday 05 June 2018 at 08:33:26, David P wrote: > > > We're using Asterisk 14.7.6 and I have a dialplan that ends like this: > > > > same => n,Dial(SIP/${EXTEN:0:4}@peer1) > > same => n,Set(GLOBAL(EpochAtCallEnd)=${EPOCH}) > > same => n,Hangup() > > > > When peer1 hangsup, the priorities after the Dial are executed fine. But > > when the caller hangsup during the Dial, the cleanup steps aren't done. > > Why? > > > > I did read "Note that on a successful connection, in the absence of the g > > and G modifiers (below), the Dial command does not return to allow > > execution of further commands for that extension in that context." at > > https://www.voip-info.org/asterisk-cmd-dial/ But it seems not to apply > > because I'm seeing the 'g' behavior without specifying that option, and > the > > 'G' option seems intended for a far more complicated scenario. > > If you're getting "g" functionality without specifying it, congratulations. > > If you want something similar when the callER hangs up, you want to use > the F > option. > > Regards, > > > Antony.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180605/327d3900/attachment.html>