[asterisk-bugs] [JIRA] (ASTERISK-26722) Dialing an early bridged channel by ARI with timeout not equal zero causes bridge and thread leaks

[Jose María Arias (JIRA)]

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

Jose María Arias commented on ASTERISK-26722:
---------------------------------------------

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 

> Dialing an early bridged channel by ARI with timeout not equal zero causes bridge and thread leaks
> --------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26722
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26722
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          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
>    Affects Versions: 14.0.0-beta2, 14.2.1
>         Environment: Linux Mint 17.3 Rosa. Linux version 3.19.0-32-generic (buildd at lgw01-43) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) )
> Asterisk 14.2.1 "out of the box"
>            Reporter: Jose María Arias
>         Attachments: dial-onbridge-ari.json, dial-onbridge-debug
>
>
> 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



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