| Summary: | ASTERISK-26722: Dialing an early bridged channel by ARI with timeout not equal zero causes bridge and thread leaks | ||||
| Reporter: | Jose María Arias (jmarias) | Labels: | |||
| Date Opened: | 2017-01-17 09:16:19.000-0600 | Date Closed: | 2017-01-17 09:21:14.000-0600 | ||
| Priority: | Major | Regression? | |||
| Status: | Closed/Complete | Components: | Bridges/bridge_simple Bridges/bridge_softmix Channels/chan_bridge Core/Bridging Core/Stasis Resources/res_ari_bridges Resources/res_ari_channels Resources/res_stasis | ||
| Versions: | 14.0.0-beta2 14.2.1 | Frequency of Occurrence | Constant | ||
| Related Issues: |
| ||||
| Environment: | Linux Mint 17.3 Rosa. Linux version 3.19.0-32-generic (buildd@lgw01-43) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) Asterisk 14.2.1 "out of the box" | Attachments: | ( 0) dial-onbridge-ari.json ( 1) dial-onbridge-debug | ||
| Description: | In an outgoing early media scenario using the early bridging feature, if you use the ARI dial method with a timeout param not equal zero, the bridge where the channel is bridged remains alocated after to be deleted.
You can reproduce the issue by ARI configuring a stasis application and connnecting the websocket and then creating a bridge b1, a channel c2, adding the channel c2 into the bridge b1, dialing out the channel with a timeout not equal 0, deleting the channel to hangup and trying to delete the bridge as follows: {{POST http://127.0.0.1:8088/ari/channels/create (channelId=c2&endpoint=SIP%2F5005&app=myapp) POST http://127.0.0.1:8088/ari/bridges/b1 POST http://127.0.0.1:8088/ari/bridges/b1/addChannel (channel=c2) POST http://127.0.0.1:8088/ari/channels/c2/dial (callerId=5005&timeout=30) DELETE http://127.0.0.1:8088/ari/channels/c2 DELETE http://127.0.0.1:8088/ari/bridges/b1}} then if you try "bridge show all" in the console you'll get: {{Bridge-ID Chans Type Technology}} {{b1 0 stasis simple_bridge}} and if you try again a "DELETE http://127.0.0.1:8088/ari/bridges/b1" you'll get a 404 not found response, however, the "bridge show all" will remain showing the bridge b1 in the stasis. The above is a simple scenario, but in a real scenario using the softmix bridge technology making hundreds of outgoing calls with an unique bridge-id per call for security reasons, a softmix_mixing_thread stays for each "phantom" bridge, as you'll be able to see making a "core show threads" in the console, making the system to go out from resources in a while. The workarround (and a hint to resolve the issue I think), is not to use the timeout param in the dial method. If you send: POST http://127.0.0.1:8088/ari/channels/c2/dial (callerId=5005) all works fine and the bridges are destroyed without causing the thread leak. I'm attaching two files: - json log of the ARI requests using RestClient plugin for Chrome - asterisk debug output for these ARI requests | ||||
| Comments: | By: Asterisk Team (asteriskteam) 2017-01-17 09:16:20.333-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: Jose María Arias (jmarias) 2017-01-17 09:22:54.847-0600 debug output and logs while reproducing the issue By: Jose María Arias (jmarias) 2017-01-18 09:11:54.240-0600 Hi Joshua, only a thing: the behavior of this issue regarding ASTERISK-26718 is a bit different because in ASTERISK-26718 it looks the issue only happens (sometimes) if you destroy the bridge with a channel into the bridge but if you destroy the channel before and then destroy the bridge, it works fine, as Marin reported. However, in ASTERISK-26722, the issue happens always, even you destroy the channel before destroying the bridge. All you have to do to make it to fail is to send a dial request with a timeout value greater than zero. Maybe the cause of both of them will be the same, but I would prefer to notice about it in order to help you addressing the issue. Thanks in advance. Jose By: Asterisk Team (asteriskteam) 2017-01-18 09:11:54.609-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Joshua C. Colp (jcolp) 2017-01-18 09:14:26.138-0600 The issues are linked so anyone working on it should see this as well - but I do believe it is the same underlying thing. | ||||