[asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[David P]

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
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[Antony Stone]

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.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[David P]

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.st...@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.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[Eric Wieling]

Use hangup handlers, they work around the issues with the 'h' extension.

On 06/05/2018 05:33 AM, David P wrote:

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 
> 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.





--
http://help.nyigc.net/

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[David P]

Thanks, Eric. I just tried a hangup handler, but it's showing a similar
problem: When the peer hangs-up, the hangup handler is not invoked and the
caller channel remains open.

 same =>
n(callPeer),Set(GLOBAL(Peer${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount}
+ 1])
 same =>
n,Set(CHANNEL(hangup_handler_push)=handleHangupByCallerOrPeer,doesntMatter,1(args))
 same => n,Set(DialForPeer=SIP/${EXTEN:0:4}@${PeerBeingConsidered})
 same => n,Dial(${DialForPeer})
 same => n,Hangup()

[handleHangupByCallerOrPeer]
exten => _.,1,NoOp(${PeerBeingConsidered}: Entered
handleHangupByCallerOrPeer Calls ${Peer${IndexIntoPeers}CurrentCallsCount})
 same =>
n,Set(GLOBAL(Peer${IndexIntoPeers}CurrentCallsCount)=$[${Peer${IndexIntoPeers}CurrentCallsCount}
- 1])
 same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
 same => n,Return()

I've also tried replacing the Dial above with:

 same => n,Dial(${DialForPeer},,g)

Cheers,
David

On Tue, Jun 5, 2018 at 7:38 AM, Eric Wieling  wrote:

> Use hangup handlers, they work around the issues with the 'h' extension.
>
> On 06/05/2018 05:33 AM, David P wrote:
>
>> 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.st...@asterisk.open.source.it > 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.
>>
>>
>>
>>
> --
> http://help.nyigc.net/
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[Eric Wieling]

Don't use the _. pattern.  Ever.

The call has two channels so it needs two hangup handlers, something 
like this, though I've not tested it.


[some_context]
exten => _X.,1,Noop
 same => n,Set(CHANNEL(hangup_handler_push)=my_caller_hangup_handler)
 same => n,Dial(SIP/number@peer,b(pre_dial^s^1))
 same => n,Hangup

[pre_dial]
exten => s,1,Set(CHANNEL(hangup_handler_push)=my_called_hangup_handler)
 same => Return

See: https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
and https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers


On 06/05/2018 03:37 PM, David P wrote:
Thanks, Eric. I just tried a hangup handler, but it's showing a similar 
problem: When the peer hangs-up, the hangup handler is not invoked and 
the caller channel remains open.


  same => 
n(callPeer),Set(GLOBAL(Peer${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount} 
+ 1])
  same => 
n,Set(CHANNEL(hangup_handler_push)=handleHangupByCallerOrPeer,doesntMatter,1(args))

  same => n,Set(DialForPeer=SIP/${EXTEN:0:4}@${PeerBeingConsidered})
  same => n,Dial(${DialForPeer})
  same => n,Hangup()
[handleHangupByCallerOrPeer]
exten => _.,1,NoOp(${PeerBeingConsidered}: Entered 
handleHangupByCallerOrPeer Calls ${Peer${IndexIntoPeers}CurrentCallsCount})
  same => 
n,Set(GLOBAL(Peer${IndexIntoPeers}CurrentCallsCount)=$[${Peer${IndexIntoPeers}CurrentCallsCount} 
- 1])

  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
  same => n,Return()

I've also tried replacing the Dial above with:

  same => n,Dial(${DialForPeer},,g)

Cheers,
David

On Tue, Jun 5, 2018 at 7:38 AM, Eric Wieling > wrote:


Use hangup handlers, they work around the issues with the 'h' extension.

On 06/05/2018 05:33 AM, David P wrote:

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
mailto:antony.st...@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.




-- 
http://help.nyigc.net/







--
http://help.nyigc.net/

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[David P]

This has been super-helpful, Eric. However, the handleHangupByPeer priorities
below are still not run when the peer hangs-up. The last line in the cli
when the peer hangs-up is still:
Strict RTP learning complete - Locking on source address
(Although sometimes there is also: Retransmission timeout reached on
transmission)

 same =>
n(callPeer),Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount}
+ 1])
 ; Ensure that hangup by caller/inbound-channel will invoke
handleHangupByCaller.
 same => n,Set(CHANNEL(hangup_handler_push)=handleHangupByCaller,s,1(args))
 same => n,Set(AddressToReachPeer=SIP/${EXTEN:0:4}@${PeerBeingConsidered})
 ; Ensure that the channel of the peer (i.e. outbound-channel) is
configured with hangup handler.
 same =>
n,Dial(${AddressToReachPeer},,b(beforeDialingPeerConfigureItsChannelForPeerHangupHandling^s^1))
 same => n,Hangup

[beforeDialingPeerConfigureItsChannelForPeerHangupHandling]
exten => s,1,Set(CHANNEL(hangup_handler_push)=handleHangupByPeer,s,1(args))
 same => n,Return

[handleHangupByPeer]
 ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is decremented
after hangup, and end-of-call-epoch is set.
exten => s,1,NoOp(${PeerBeingConsidered} peer channel: Entered
handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCallsCount})
 same =>
n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${IndexIntoPeers}CurrentCallsCount}
- 1])
 same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
 same => n,Return

[handleHangupByCaller]
 ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is decremented
after hangup, and end-of-call-epoch is set.
exten => s,1,NoOp(${PeerBeingConsidered} caller channel: Entered
handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCallsCount})
 same =>
n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${IndexIntoPeers}CurrentCallsCount}
- 1])
 same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
 same => n,Return


When the caller hangs-up, handleHangupByCaller is run first, then
handleHangupByPeer
runs. (And strangely, the value of global CB${IndexIntoPeers}CurrentCallsCount
isn't accessible in handleHangupByPeer.)

Cheers,
David


On Tue, Jun 5, 2018 at 12:58 PM, Eric Wieling  wrote:

> Don't use the _. pattern.  Ever.
>
> The call has two channels so it needs two hangup handlers, something like
> this, though I've not tested it.
>
> [some_context]
> exten => _X.,1,Noop
>  same => n,Set(CHANNEL(hangup_handler_push)=my_caller_hangup_handler)
>  same => n,Dial(SIP/number@peer,b(pre_dial^s^1))
>  same => n,Hangup
>
> [pre_dial]
> exten => s,1,Set(CHANNEL(hangup_handler_push)=my_called_hangup_handler)
>  same => Return
>
> See: https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
> and https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers
>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[David P]

FWIW, I added the following after the Dial, and it doesn't appear in cli
after peer hangup:

same => n,NoOp(After Dial ${AddressToReachPeer})

I also tried putting 'g' before the 'b'.

I also tried removing the context headers of the hangup handlers and
predial handler, and just referring to those by extensions. No difference.

On Tue, Jun 5, 2018 at 3:17 PM, David P  wrote:

> This has been super-helpful, Eric. However, the handleHangupByPeer priorities
> below are still not run when the peer hangs-up. The last line in the cli
> when the peer hangs-up is still:
> Strict RTP learning complete - Locking on source address
> (Although sometimes there is also: Retransmission timeout reached on
> transmission)
>
>  same => 
> n(callPeer),Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount}
> + 1])
>  ; Ensure that hangup by caller/inbound-channel will invoke
> handleHangupByCaller.
>  same => n,Set(CHANNEL(hangup_handler_push)=handleHangupByCaller,s,
> 1(args))
>  same => n,Set(AddressToReachPeer=SIP/${EXTEN:0:4}@${PeerBeingConsidered})
>  ; Ensure that the channel of the peer (i.e. outbound-channel) is
> configured with hangup handler.
>  same => n,Dial(${AddressToReachPeer},,b(beforeDialingPeerConfigureItsC
> hannelForPeerHangupHandling^s^1))
>  same => n,Hangup
>
> [beforeDialingPeerConfigureItsChannelForPeerHangupHandling]
> exten => s,1,Set(CHANNEL(hangup_handler_push)=
> handleHangupByPeer,s,1(args))
>  same => n,Return
>
> [handleHangupByPeer]
>  ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is
> decremented after hangup, and end-of-call-epoch is set.
> exten => s,1,NoOp(${PeerBeingConsidered} peer channel: Entered
> handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCallsCount})
>  same => n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${
> IndexIntoPeers}CurrentCallsCount} - 1])
>  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
>  same => n,Return
>
> [handleHangupByCaller]
>  ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is
> decremented after hangup, and end-of-call-epoch is set.
> exten => s,1,NoOp(${PeerBeingConsidered} caller channel: Entered
> handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCallsCount})
>  same => n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${
> IndexIntoPeers}CurrentCallsCount} - 1])
>  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
>  same => n,Return
>
>
> When the caller hangs-up, handleHangupByCaller is run first, then 
> handleHangupByPeer
> runs. (And strangely, the value of global CB${IndexIntoPeers}CurrentCallsCount
> isn't accessible in handleHangupByPeer.)
>
> Cheers,
> David
>
>
> On Tue, Jun 5, 2018 at 12:58 PM, Eric Wieling  wrote:
>
>> Don't use the _. pattern.  Ever.
>>
>> The call has two channels so it needs two hangup handlers, something like
>> this, though I've not tested it.
>>
>> [some_context]
>> exten => _X.,1,Noop
>>  same => n,Set(CHANNEL(hangup_handler_push)=my_caller_hangup_handler)
>>  same => n,Dial(SIP/number@peer,b(pre_dial^s^1))
>>  same => n,Hangup
>>
>> [pre_dial]
>> exten => s,1,Set(CHANNEL(hangup_handler_push)=my_called_hangup_handler)
>>  same => Return
>>
>> See: https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
>> and https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers
>>
>>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[David P]

FYI, we found that our peers don't hangup properly. But we would still like
to know how to get the peer's hangup handler to fire upon peer hangup,
because right now it corrupts our globals by firing after the caller's
hangup handler.

On Tue, Jun 5, 2018 at 5:40 PM, David P  wrote:

> FWIW, I added the following after the Dial, and it doesn't appear in cli
> after peer hangup:
>
> same => n,NoOp(After Dial ${AddressToReachPeer})
>
> I also tried putting 'g' before the 'b'.
>
> I also tried removing the context headers of the hangup handlers and
> predial handler, and just referring to those by extensions. No difference.
>
> On Tue, Jun 5, 2018 at 3:17 PM, David P  wrote:
>
>> This has been super-helpful, Eric. However, the handleHangupByPeer priorities
>> below are still not run when the peer hangs-up. The last line in the cli
>> when the peer hangs-up is still:
>> Strict RTP learning complete - Locking on source address
>> (Although sometimes there is also: Retransmission timeout reached on
>> transmission)
>>
>>  same => 
>> n(callPeer),Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount}
>> + 1])
>>  ; Ensure that hangup by caller/inbound-channel will invoke
>> handleHangupByCaller.
>>  same => n,Set(CHANNEL(hangup_handler_push)=handleHangupByCaller,s,1(
>> args))
>>  same => n,Set(AddressToReachPeer=SIP/${EXTEN:0:4}@${PeerBeingConside
>> red})
>>  ; Ensure that the channel of the peer (i.e. outbound-channel) is
>> configured with hangup handler.
>>  same => n,Dial(${AddressToReachPeer},,b(beforeDialingPeerConfigureIt
>> sChannelForPeerHangupHandling^s^1))
>>  same => n,Hangup
>>
>> [beforeDialingPeerConfigureItsChannelForPeerHangupHandling]
>> exten => s,1,Set(CHANNEL(hangup_handler_push)=handleHangupByPeer,s,1(
>> args))
>>  same => n,Return
>>
>> [handleHangupByPeer]
>>  ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is
>> decremented after hangup, and end-of-call-epoch is set.
>> exten => s,1,NoOp(${PeerBeingConsidered} peer channel: Entered
>> handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCallsCount})
>>  same => n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${I
>> ndexIntoPeers}CurrentCallsCount} - 1])
>>  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
>>  same => n,Return
>>
>> [handleHangupByCaller]
>>  ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is
>> decremented after hangup, and end-of-call-epoch is set.
>> exten => s,1,NoOp(${PeerBeingConsidered} caller channel: Entered
>> handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCallsCount})
>>  same => n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${I
>> ndexIntoPeers}CurrentCallsCount} - 1])
>>  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
>>  same => n,Return
>>
>>
>> When the caller hangs-up, handleHangupByCaller is run first, then 
>> handleHangupByPeer
>> runs. (And strangely, the value of global 
>> CB${IndexIntoPeers}CurrentCallsCount
>> isn't accessible in handleHangupByPeer.)
>>
>> Cheers,
>> David
>>
>>
>> On Tue, Jun 5, 2018 at 12:58 PM, Eric Wieling  wrote:
>>
>>> Don't use the _. pattern.  Ever.
>>>
>>> The call has two channels so it needs two hangup handlers, something
>>> like this, though I've not tested it.
>>>
>>> [some_context]
>>> exten => _X.,1,Noop
>>>  same => n,Set(CHANNEL(hangup_handler_push)=my_caller_hangup_handler)
>>>  same => n,Dial(SIP/number@peer,b(pre_dial^s^1))
>>>  same => n,Hangup
>>>
>>> [pre_dial]
>>> exten => s,1,Set(CHANNEL(hangup_handler_push)=my_called_hangup_handler)
>>>  same => Return
>>>
>>> See: https://wiki.asterisk.org/wiki/display/AST/Pre-Dial+Handlers
>>> and https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers
>>>
>>>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to execute priorities following a caller hangup in a successful Dial?

[Eric Wieling]

Keep it as simple as you can.

​[test]
exten => 12345678900,1,Noop( Set callER hangup handler
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Set(CHANNEL(hangup_handler_push)=test_caller_hangup,${EXTEN},1)
 same =>
n,Dial(SIP/pbx-nyigc/4408,60,gb(test_pre_dial^${EXTEN}^1)F(test_intercept_callee,${EXTEN},1))
 same => n,Noop(### Running post Dial() dialplan on callER
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Gosub(test_intercept_caller,${EXTEN},1)
 same => n,Hangup

[test_pre_dial]
exten => _X.,1,Noop( Set callEE hangup handler
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Set(CHANNEL(hangup_handler_push)=test_callee_hangup,${EXTEN},1)
 same => n,Dumpchan
 same => n,Return

[test_caller_hangup]
exten => _X.,1,Noop( Running callER hangup handler
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Dumpchan
 same => n,Return

[test_callee_hangup]
exten => _X.,1,Noop( Running callEE hangup handler
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Dumpchan
 same => n,Return

[test_intercept_callee]
exten => _X.,1,Noop(### Running post Dial() dialplan on callEE
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Dumpchan
 same => n,ExecIf($["${DIALSTATUS}" == "ANSWER"]?Hangup)
 same => n,ExecIf($["${DIALSTATUS}" == "BUSY"]?Busy)
 same => n,Hangup

[test_intercept_caller]
exten => _X.,1,Noop(### Running post Dial() dialplan on callER
CHANNEL(name)='${CHANNEL(name)}' SIPCALLID='${SIPCALLID}')
 same => n,Dumpchan
 same => n,Hangup

​


On Wed, Jun 6, 2018 at 2:37 PM, David P  wrote:

> FYI, we found that our peers don't hangup properly. But we would still
> like to know how to get the peer's hangup handler to fire upon peer hangup,
> because right now it corrupts our globals by firing after the caller's
> hangup handler.
>
> On Tue, Jun 5, 2018 at 5:40 PM, David P  wrote:
>
>> FWIW, I added the following after the Dial, and it doesn't appear in cli
>> after peer hangup:
>>
>> same => n,NoOp(After Dial ${AddressToReachPeer})
>>
>> I also tried putting 'g' before the 'b'.
>>
>> I also tried removing the context headers of the hangup handlers and
>> predial handler, and just referring to those by extensions. No difference.
>>
>> On Tue, Jun 5, 2018 at 3:17 PM, David P 
>> wrote:
>>
>>> This has been super-helpful, Eric. However, the handleHangupByPeer 
>>> priorities
>>> below are still not run when the peer hangs-up. The last line in the cli
>>> when the peer hangs-up is still:
>>> Strict RTP learning complete - Locking on source address
>>> (Although sometimes there is also: Retransmission timeout reached on
>>> transmission)
>>>
>>>  same => 
>>> n(callPeer),Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${PeerCurrentCallsCount}
>>> + 1])
>>>  ; Ensure that hangup by caller/inbound-channel will invoke
>>> handleHangupByCaller.
>>>  same => n,Set(CHANNEL(hangup_handler_push)=handleHangupByCaller,s,1(
>>> args))
>>>  same => n,Set(AddressToReachPeer=SIP/${EXTEN:0:4}@${PeerBeingConside
>>> red})
>>>  ; Ensure that the channel of the peer (i.e. outbound-channel) is
>>> configured with hangup handler.
>>>  same => n,Dial(${AddressToReachPeer},,b(beforeDialingPeerConfigureIt
>>> sChannelForPeerHangupHandling^s^1))
>>>  same => n,Hangup
>>>
>>> [beforeDialingPeerConfigureItsChannelForPeerHangupHandling]
>>> exten => s,1,Set(CHANNEL(hangup_handler_push)=handleHangupByPeer,s,1(
>>> args))
>>>  same => n,Return
>>>
>>> [handleHangupByPeer]
>>>  ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is
>>> decremented after hangup, and end-of-call-epoch is set.
>>> exten => s,1,NoOp(${PeerBeingConsidered} peer channel: Entered
>>> handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCa
>>> llsCount})
>>>  same => n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${I
>>> ndexIntoPeers}CurrentCallsCount} - 1])
>>>  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
>>>  same => n,Return
>>>
>>> [handleHangupByCaller]
>>>  ; Ensure that GLOBAL(CB${IndexIntoPeers}CurrentCallsCount) is
>>> decremented after hangup, and end-of-call-epoch is set.
>>> exten => s,1,NoOp(${PeerBeingConsidered} caller channel: Entered
>>> handleHangupByCallerOrPeer Calls ${CB${IndexIntoPeers}CurrentCa
>>> llsCount})
>>>  same => n,Set(GLOBAL(CB${IndexIntoPeers}CurrentCallsCount)=$[${CB${I
>>> ndexIntoPeers}CurrentCallsCount} - 1])
>>>  same => n,Set(GLOBAL(${PeerBeingConsidered}EpochAtCallEnd)=${EPOCH})
>>>  same => n,Return
>>>
>>>
>>> When the caller hangs-up, handleHangupByCaller is run first, then 
>>> handleHangupByPeer
>>> runs. (And strangely, the value of global 
>>> CB${IndexIntoPeers}CurrentCallsCount
>>> isn't accessible in handleHangupByPeer.)
>>>
>>> Cheers,
>>> David
>>>
>>>
>>> On Tue, Jun 5, 2018 at 12:58 PM, Eric Wieling 
>>> wrote:
>>>
 Don't use the _. pattern.  Ever.

 The call has two channels so it needs two hangup handlers, something
>>>