[asterisk-bugs] [JIRA] (ASTERISK-26718) ARI: Bridge destroying doesn't work as expected

Holger Hans Peter Freyther (JIRA) noreply at issues.asterisk.org
Wed Apr 10 01:35:48 CDT 2019


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

Holger Hans Peter Freyther commented on ASTERISK-26718:
-------------------------------------------------------

I looked into the crash reported in ASTERISK-28347 and see two related issues when the bridge is deleted while the call is still set-up.

# The ast_channel is in a pseudo state. It was departed from the deleted bridge but it is not allowed to rejoin the dial bridge. This prints an error message (repeatedly). It seems at the point control->pbx = NULL but channel->pbx is still set.

# The crash due dial_bridge_after_cb_failed being executed _after_ control_unlink has been called (resulting in the stasis_app_control closure being a dangling pointer.

I think I have a fix for the second issue in https://gerrit.asterisk.org/c/asterisk/+/11254 but I need some guidance on the first item.


> ARI: Bridge destroying doesn't work as expected
> -----------------------------------------------
>
>                 Key: ASTERISK-26718
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26718
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari, Resources/res_stasis
>    Affects Versions: 14.2.1
>         Environment: Debian 8
>            Reporter: Marin Odrljin
>            Assignee: Unassigned
>         Attachments: ari_log_26718.txt, debug_log_26718.txt
>
>
> There is an unexpected behavior when destroying a bridge from ARI. My scenario is following:
> 1. IN call comes to stasis app
> 2. app creates bridge and adds channel to it
> 3. app creates new OUT channel for dialing and adds it to the same bridge
> 4. app dials on out channel
> 5. when one of the channels disconnects, app tries to destroy a bridge. After that, following events are received from asterisk:
> 	- 'ChannelLeftBridge' for IN channel
> 	- 'ChannelLeftBridge' for OUT channel
> 6. app hangup other channel
> The problem is that 'BridgeDestroyed' event never comes. In version 13, as I recall, this event was sometimes fired, sometimes not, but bridge was in most cases or always destroyed. But in v 14, bridge is not really destroyed, it is still listed with ari/bridges request. E.g. response is following:
> {
>   "video_mode": "talker",
>   "name": "CONF-1484303820.435",
>   "id": "C-1-40",
>   "bridge_class": "stasis",
>   "technology": "simple_bridge",
>   "bridge_type": "mixing",
>   "creator": "Stasis",
>   "channels": []
> }
> As you can see, creator is Stasis, and there are no channels inside. Looks
> like that bridge is not properly destroyed on delete http command and it
> will hang forever in asterisk. Good thing is that app can later again create
> bridge with the same ID, so this problem is not fatal, but it's not nice to
> see a lot of 'hanging' unused bridges.
> > What happens if you remove each channel from the bridge, hang them up, and then destroy the bridge? Does that work as expected?
> > Joshua Colp
> I just tried it and everything seems to be fine if channels are removed from
> bridge before it is destroyed. Strange thing is that destroying is also
> proper if both channels are still in and connected, but if one disconnects
> and destroying is made with other channel still in the bridge, then channel
> is properly removed but bridge is not deleted. Theoretically my app could
> remove other channel before destroying a bridge, but this seems to me
> unnecessary since destroying of the bridge is doing it, and I'm then just
> adding additional logic without a reason. Do you agree?
> > It is a reasonable expectation that destroying the bridge in this state
> should result in the behavior you expect. Please file an issue[1].
> > Joshua Colp
> And here it is...



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



More information about the asterisk-bugs mailing list