[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)
noreply at issues.asterisk.org
Tue Jan 17 09:19:09 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jose María Arias updated ASTERISK-26722:
----------------------------------------
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
was:
n 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
> 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
>
> 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)
More information about the asterisk-bugs
mailing list