[asterisk-bugs] [JIRA] (ASTERISK-30102) Hangup_handler not invoked

[Morten Sølvberg (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-30102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=259451#comment-259451 ] 

Morten Sølvberg edited comment on ASTERISK-30102 at 6/9/22 3:46 AM:
--------------------------------------------------------------------

Hi Kevin
The actual Diaplan is very complex, but the below example will show it just as well.

'Channel1' and 'Channel2' both dials 1234, is assigned a hangup_handler and placed in a queue.
'Channel1' is then redirected via AMI to the BridgeChannels context and orders a bridge with 'Channel2'.
If you look at the log you will see that the the hangup action [chanHungUp] is perfomed immidiately for the chanel 'Surrogate/Channel2', but is not performed when 'Channel2' leaves the bridge.
Futher more you will see that if 'Channel2' is the first to hangUp, then it is not sent to (bridgedEnd,s,1) as ordered in the Bridge application, and does no show up as the h extension in any other part of the dial plan.

I believe that the actual error is that the hangup_handler isn't copied to the new channel when the Masquerade operation ís performed.
The second problem where the channel isn't sent to (bridgedEnd,s,1) when it hangs up, might have been the actual intent, and that you therefore won't see this as an error - which is fine.


[IncomingContext]
exten => 1234,1,Answer()
exten => 1234,n,Gosub(hanguphandler,s,1)
exten => 1234,n,Queue(SomeQueue)
exten => h,1,Goto(chanHungUp,s,1)

[hanguphandler]
exten => s,1,Set(CHANNEL(hangup_handler_push)=chanHungUp,s,1());
exten => s,n,Return()

__________________________
Send this via AMI:
    Action: SetVar
    Channel: FirstChannel
    Variable: IdOfOtherChannel
    Value: SecondChannel

    Action: Redirect
    Channel: FirstChannel
    Context: BridgeChannels
    Exten: s
    Priority: 1
__________________________

[BridgeChannels]
exten => s,1,Bridge(${IdOfOtherChannel},F(bridgedEnd,s,1))
exten => s,n,NoOp(bridger exit - BRIDGERESULT = ${BRIDGERESULT})
exten => s,n,HangUp()
exten => h,1,Goto(chanHungUp,s,1)

[bridgedEnd]
exten => s,1,NoOp(bridged exit)
exten => s,n,HangUp()
exten => h,1,Goto(chanHungUp,s,1)

[chanHungUp]
exten => s,1,NoOp(Channel now hung up);
exten => s,n,Return()



was (Author: soelvberg):
Hi Kevin
The actual Diaplan is very complex, but the below example will show it just as well.

'Channel1' and 'Channel2' both dials 1234, is assigned a hangup_handler and placed in a queue.
'Channel1' is then redirected via AMI to the BridgeChannels context and orders a bridge with 'Channel2'.
If you look at the log you will see that the the hangup action [chanHungUp] is perfomed immidiately for the chanel 'Surrogate/Channel2', but is not performed when 'Channel2' leaves the bridge.
Futher more you will see that if 'Channel2' is the first to hangUp, then it is not sent to (bridgedEnd,s,1) as ordered in the Bridge application, and does no show up as the h extension in any other part of the dial plan.

I believe that the actual error is that the hangup_handler isn't copied to the new channel when the Masquerade operation ís performed.
The second problem where the channel isn't sent to (bridgedEnd,s,1) when it hangs up, might have been the actual intent, and that you therefore won't see this as an error - which is fine.


[IncomingContext]
exten => 1234,1,Answer()
exten => 1234,n,Gosub(hanguphandler,s,1)
exten => 1234,n,Queue(SomeQueue)
exten => h,1,Goto(chanHungUp,s,1)

[hanguphandler]
exten => s,1,Set(CHANNEL(hangup_handler_push)=chanHungUp,s,1());
exten => s,n,Return()


Send this via AMI:
    Action: SetVar
    Channel: FirstChannel
    Variable: IdOfOtherChannel
    Value: SecondChannel

    Action: Redirect
    Channel: FirstChannel
    Context: BridgeChannels
    Exten: s
    Priority: 1


[BridgeChannels]
exten => s,1,Bridge(${IdOfOtherChannel},F(bridgedEnd,s,1))
exten => s,n,NoOp(bridger exit - BRIDGERESULT = ${BRIDGERESULT})
exten => s,n,HangUp()
exten => h,1,Goto(chanHungUp,s,1)

[bridgedEnd]
exten => s,1,NoOp(bridged exit)
exten => s,n,HangUp()
exten => h,1,Goto(chanHungUp,s,1)

[chanHungUp]
exten => s,1,NoOp(Channel now hung up);
exten => s,n,Return()


> Hangup_handler not invoked
> --------------------------
>
>                 Key: ASTERISK-30102
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30102
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_simple
>    Affects Versions: 18.0.1
>         Environment: Hosted in Azure
>            Reporter: Morten Sølvberg
>            Assignee: Unassigned
>
> I am recording calls with MixMonitor, and I am using "hangup_handler_push" on all calls I crate/receive, to make sure that the calls are always sent to the same location in the dialplan where I move the recording to a mounted drive.
> This usually works fine, but I see that when I use the Bridge application, then the hangup_handler is removed for the *Briged* party. 
> I assume that this happens due to the masquerade functionality in Asterisk, and that the hangup_handler isn't copied to the new channel. 
> I can see the hangup_handler being invoked on the Surrogate channel, but not on the actual one.
> Luckily I can use the F option in the Bridge application, so the *Bridged* party is sent to defined place in the dialplan when the *Bridger* hangs up.
> This also works fine.
> However if the *Bridged* party hangs up, then the channel is not sent to the defined localion in the dialplan.
> I have an h extension in all the the contexts that the channel has been in, but it does not hit any of these either.
> Is this a known issue and/or can you think of a workaround?



--
This message was sent by Atlassian JIRA
(v6.2#6252)