[asterisk-bugs] [JIRA] (ASTERISK-29020) Regression: Fix for app_queue: track masquerades in app_queue to avoid leaked stasis subscriptions broke queue log

[Kevin Harwell (JIRA)]

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

Kevin Harwell commented on ASTERISK-29020:
------------------------------------------

{quote}
But just from looking at the new code only: in every scenario in which there is a queue log entry written after a masquerade, this queue log entry is going to have a different uniqueid than before.
{quote}
I don't think this is necessarily always the case. If the stasis handler in question is even called the channel blob's {{uniqueid}} must match either the queue_data's {{caller_uniqueid}} or {{member_uniqueid}} before the value is overwritten.

As well the handler is only called on a channel that is "setup" to listen for the {{ast_channel_masquerade_type()}}. For example, in a scenario I ran where a caller enters a queue, the agent is dialed, and then the agent answers, the agent here is "setup" to listen for the event. That means in that scenario if the agent transfers the caller someplace the handler is _not_ called because the caller is not "setup" to listen for it. However the caller can potentially transfer the agent. If that happens the handler _may_ be called. I say _may_ because when I ran that scenario sometimes it was called, and sometimes it wasn't. Even when it was the queue_log value did not change as neither of the handler's checks passed. So it's important to understand the scenario where the conditions to overwrite are triggered.

Also, given the above I believe there might be a race condition where sometimes the stasis subscription is removed on the associated channel before that event gets triggered or completes propogation. I will say that's somewhat of a separate issue, but could explain if in your scenario you see it overwritten sometimes, and sometimes not.


> Regression: Fix for app_queue: track masquerades in app_queue to avoid leaked stasis subscriptions broke queue log
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29020
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29020
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 13.35.0
>            Reporter: Grzegorz Garlewicz
>            Assignee: Unassigned
>
> {code}handle_masquerade{code}'s
> {code}ast_string_field_set(queue_data, caller_uniqueid, new_channel_id);{code}
> makes all subsequent entries in the queue_log use the new uniqueid which is not in any way associated to the original one.
> This way you can no longer rely on the log entries.
> {code}
> 1596621010|1596620945.17555|Consultant|NONE|ENTERQUEUE||209899255|1
> 1596621016|1596620945.17555|Consultant|Sip/3873|CONNECT|6|1596621010.17570|5
> 1596621065|1596621064.17580|Specialist|NONE|ENTERQUEUE||3873|2
> 1596621066|1596621064.17580|Consultant|Sip/3873|ATTENDEDTRANSFER|APP|Queue|6|50|1
> {code}
> the last entry used to have original uniqueid



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