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

[Grzegorz Garlewicz (JIRA)]

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

Grzegorz Garlewicz commented on ASTERISK-29020:
-----------------------------------------------

I will try to gather some more data for this particular scenario. 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.

> 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: Grzegorz Garlewicz
>
> {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)