[asterisk-bugs] [JIRA] Feedback Entered: (ASTERISK-19562) [patch] ConfBridge - Inconsistent hold-music behaviour

[Rusty Newton (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-19562:
------------------------------------

    Assignee: Jonathan Rose  (was: Neil Tallim)
      Status: Open  (was: Waiting for Feedback)

ASTERISK-20148 is a report by a different reporter, duplicate or very similar issue.

> [patch] ConfBridge - Inconsistent hold-music behaviour
> ------------------------------------------------------
>
>                 Key: ASTERISK-19562
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19562
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_confbridge
>    Affects Versions: SVN, 10.0.1, 10.1.0, 10.1.1, 10.1.2, 10.1.3, 10.2.0, 10.2.1
>            Reporter: Neil Tallim
>            Assignee: Jonathan Rose
>         Attachments: jrose_confbridge_suspension_and_startup_inconsistencies.diff, moh_everything.patch, moh_everything_spacing_fixes.diff, moh_leave.patch, moh_marked.patch, moh_unmarked.patch
>
>
> [moh_marked.patch]
> Primary symptom, with reproduction:
> 1) Marked user joins, with hold-music enabled (no music plays)
> 2) Unmarked user joins
> 3) Unmarked user leaves (marked user hears music)
> 4) Unmarked user joins (marked user still hears hold music)
> This patch primarily resolves step 4, disabling hold music when other users (marked or unmarked) join. This is effected by the first, second, and fourth hunks of the patch.
> It also changes the behaviour in step 1 for consistency, causing marked users to hear music when they're alone, if MoH is enabled in their profile. This is accomplished by the third hunk.
> -----
> [moh_unmarked.patch]
> This is a behavioural adjustment.
> Before, the arrival of a second user, regardless of whether it had WAITMARKED set or not, would turn off MoH for the first non-WAITMARKED participant. This patch basically just introduces a loop over all pre-existing participants to look for a conversation partner: any user who either does not have WAITMARKED set or has MARKEDUSER; if those conditions are met, the new user is not put on hold and the eligible pre-existing user(s -- though there should only ever be one) is taken off hold.
> -----
> [moh_leave.patch]
> The MoH-enabling loop now applies in all cases, not just when a marked user leaves. Marked-user-related kicking still happens as before, with the MoH loop checking the kicked flags of participants to avoid redundant or illogical work.
> If there are conversation partners for any non-WAITMARKED users, they are not put on hold. Anyone who is WAITMARKED is put on hold if there is no marked user. If there's only one user, they're put on hold without any consistency checks, if MoH is enabled.
> Users without WAITMARKED are no longer muted before the leader-has-left announcement is played, since not every non-WAITMARKED re-entry path performs unmuting, so it could eaisly have unintended side-effects that likely aren't worth the cost.
> -----
> [moh_everything.patch]
> Contains everything described above. The first and second patches have a conflict if applied independently, since they solve issues individually and both solutions affect the same lines in post_join_unmarked.
> -----
> First-party testing involved calling in with multiple marked/unmarked combinations (including with multiple marked users) and evaluating correctness of behaviour. Every conceivable scenario worked as intended.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira