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

[Pavel Nichoski (JIRA)]

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

Pavel Nichoski commented on ASTERISK-26718:
-------------------------------------------

I have this issue too, and bridge is not destroyed completely even after both channels are removed from it. I say 'completely' cause bridge is destroyed, but there are some leftovers that make it still show. Essentially, the bridge is not alive, as another bridge can be created with the same id, but the bridge is still visible in "bridge show all" and in getting the list of bridges from ARI.
So this is not a work stopper right now, but eventually these bridge leftovers might occupy a lot of memory or cause other type of problems.

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