[asterisk-bugs] [JIRA] (ASTERISK-28829) app_queue: leaking stasis subscription when Redirecting call

[Nathan Bruning (JIRA)]

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

Nathan Bruning edited comment on ASTERISK-28829 at 4/22/20 3:10 PM:
--------------------------------------------------------------------

We've tracked down this issue to the root cause: there is a masquerade which changes unique id's, causing app_queue to miss the hangups.

A patch is submitted here: https://gerrit.asterisk.org/c/asterisk/+/14321
It's targetted for 16 as that's LTS, right?

Also, I believe ASTERISK-25844 would be fixed by this patch too.


was (Author: nathanb):
We've tracked down this issue to the root cause: there is a masquerade which changes unique id's, causing app_queue to miss the hangups.

A patch is submitted here: https://gerrit.asterisk.org/c/asterisk/+/14321

Also, I believe ASTERISK-25844 would be fixed by this patch too.

> app_queue: leaking stasis subscription when Redirecting call 
> -------------------------------------------------------------
>
>                 Key: ASTERISK-28829
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28829
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 16.9.0
>            Reporter: lvl
>            Assignee: lvl
>
> Given..
> * A queue
> * A local channel as member in that queue
> * A call to that member
> * An AMI Redirect on that call
> .. app_queue will permanently leak two stasis subscriptions.
> In setup_stasis_subs we'll create these subscriptions:
> {code}
> queue_data->bridge_router = stasis_message_router_create_pool(ast_bridge_topic_all());
> queue_data->channel_router = stasis_message_router_create_pool(ast_channel_topic_all());
> {code}
> .. which will continue to exist even after the call has hung up.
> This is probably caused by the stasis subscriptions not properly tracking the masquerading process and surrogate channels, meaning {{handle_hangup}} is never called.
> You can easily spot this by "core show taskprocessors" showing dozens or hundreds of "stasis/p:bridge:all" and "stasis/p:channel:all" lines even when there are no active channels.
> Because a testcase says more than a thousand words, I will submit one that reproduces the problem shortly.
> These hanging subscriptions (to *all* channel and bridge events) can eventually grind Asterisk to a halt. I will create a separate ticket for that and leave it at your discretion to close or merge that one.



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