| Summary: | ASTERISK-26718: ARI: Bridge destroying doesn't work as expected | ||||||||
| Reporter: | Marin Odrljin (modrljin) | Labels: | |||||||
| Date Opened: | 2017-01-13 08:46:09.000-0600 | Date Closed: | 2019-05-03 10:15:14 | ||||||
| Priority: | Major | Regression? | Yes | ||||||
| Status: | Closed/Complete | Components: | Resources/res_ari Resources/res_stasis | ||||||
| Versions: | 14.2.1 | Frequency of Occurrence | Constant | ||||||
| Related Issues: |
| ||||||||
| Environment: | Debian 8 | Attachments: | ( 0) ari_log_26718.txt ( 1) debug_log_26718.txt | ||||||
| Description: | 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... | ||||||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-01-13 08:46:10.872-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Rusty Newton (rnewton) 2017-01-14 15:30:37.218-0600 Thanks for filing this issue. We need a little bit more debug to help us out. Can you reproduce the issue and gather a full Asterisk log following these instructions? https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Be sure the log includes warning,notice,error,verbose,debug, with verbose and debug both turned up to level 5 or above. Additionally if you can gather a log of your ARI calls and events in time with the debug log that would be super helpful. By: Marin Odrljin (modrljin) 2017-01-16 04:57:37.543-0600 'ari_log_26718.txt' contains filtered data from my java app log file (ARI http requests and received events) By: Pavel Nichoski (supportlevel1) 2017-03-02 14:05:23.207-0600 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. By: Bruce (torontob) 2017-06-29 18:17:19.290-0500 I have the same issue. Will this be resolved anytime? Keeping so many bridge open and tracking them is a nightmare for now. Why is this not an assigned bug yet? Can we have everyone Vote for this ^^^^ top right corner. By: Joshua C. Colp (jcolp) 2017-06-29 18:51:18.350-0500 The issue has been accepted and is in the queue. Anyone may pick it up and look at it. By: Holger Hans Peter Freyther (zecke) 2019-04-10 01:34:02.131-0500 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. By: Abhay Gupta (agupta) 2019-04-22 23:27:15.862-0500 My issue is also similar and as i realise the common thing for both of us is that incoming call is not answered before putting that to bridge and somewhere in depart_channel function the cause is add_to_dial_bridge function as Holger Hans Peter Freyther has mentioned . on my bug ASTERISK-27756 and as suggested by Morten Tryfoss if i comment add_to_dial_bridge then the issue does not come . Now that i understand this condition , i will try to simulate the same and see how it goes . By: Joeran Vinzens (jvinzens) 2019-04-23 00:52:02.154-0500 I think it is important to keep the possibility to put a channel into a bridge in order to get all the benefits (early Media). Otherwise there is no possibility to have early Media on an stasis generated channel. By: Abhay Gupta (agupta) 2019-04-23 01:41:15.708-0500 Do you mean that early media that was added with stasis generated channel from asterisk 14 works with add_to_dial_bridge and so is important for that feature to work ? By: Joeran Vinzens (jvinzens) 2019-04-23 02:02:43.383-0500 there was a Blog Entry long ago from Joshua about forwarding 183 while using ARI https://blogs.asterisk.org/2016/08/24/asterisk-14-ari-create-bridge-dial/ We use it in order to have the Bridge forward the early media to the origin Call-leg. I "guess" it is important to have non answered channels in a bridge in order to get this. I was just pointing out, it is needed to have these kind of channels in a bridge. Unfortunately i do not know how the code works. By: Friendly Automation (friendly-automation) 2019-05-03 10:15:15.809-0500 Change 11254 merged by Friendly Automation: stasis: Call callbacks when imparting fails [https://gerrit.asterisk.org/c/asterisk/+/11254|https://gerrit.asterisk.org/c/asterisk/+/11254] By: Friendly Automation (friendly-automation) 2019-05-03 10:15:31.320-0500 Change 11331 merged by Friendly Automation: stasis: Call callbacks when imparting fails [https://gerrit.asterisk.org/c/asterisk/+/11331|https://gerrit.asterisk.org/c/asterisk/+/11331] | ||||||||