[asterisk-users] How to execute priorities following a caller hangup in a successful Dial?
David P
davidswalkabout at gmail.com
Wed Jun 6 13:37:57 CDT 2018
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 <davidswalkabout at gmail.com> 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 <davidswalkabout at gmail.com> 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 <ewieling at nyigc.com> 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 at 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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180606/8c31c244/attachment.html>
More information about the asterisk-users
mailing list