[asterisk-dev] [Code Review]: Fix MOH on simultaneous confbridge user entry to a new conference.

[jcolp]

> On Dec. 12, 2012, 11:53 a.m., Mark Michelson wrote:
> > /branches/10/apps/app_confbridge.c, lines 857-861
> > <https://reviewboard.asterisk.org/r/2232/diff/3/?file=32368#file32368line857>
> >
> >     Would it be possible to just lock the user->conference_bridge here and add a lock around the ast_bridge_join() call in confbridge_exec()?

ast_bridge_join is blocking so it would never be unlocked until it returned


- jcolp


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2232/#review7526
-----------------------------------------------------------


On Dec. 11, 2012, 1:17 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2232/
> -----------------------------------------------------------
> 
> (Updated Dec. 11, 2012, 1:17 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When two users enter a new conference simultaneously, one of the callers hears MOH.
> 
> * Created a confbridge internal MOH API to eliminate the inlined MOH handling code.
> Note that the conference mixing bridge needs to be locked when actually starting/stopping MOH because there is a small window between the conference join unsuspend MOH and actually joining the mixing bridge.  Doing the lock this way may be a violation of the bridging API.  I don't see an alternative though.  See the comment in the conf_moh_start()/conf_moh_stop() functions.
> 
> * Created the concept of suspended MOH so it can be interrupted while conference join announcements and DTMF features can operate.
> 
> * Suspend any MOH until the user actually joins the bridge of the conference.  This way any pre-join file playback does not need to worry about MOH.
> 
> * Made post-join actions only play deferred entry announcement files.  Changing the user/conference state during that time is not protected or controlled by the state machine.
> 
> 
> This addresses bug ASTERISK-20606.
>     https://issues.asterisk.org/jira/browse/ASTERISK-20606
> 
> 
> Diffs
> -----
> 
>   /branches/10/apps/app_confbridge.c 377802 
>   /branches/10/apps/confbridge/conf_state.c 377802 
>   /branches/10/apps/confbridge/conf_state_multi_marked.c 377802 
>   /branches/10/apps/confbridge/include/confbridge.h 377802 
>   /branches/10/include/asterisk/bridging.h 377802 
> 
> Diff: https://reviewboard.asterisk.org/r/2232/diff
> 
> 
> Testing
> -------
> 
> Simultaneous entry to a new conference does not have one of the users still hearing MOH.
> Simultaneous entry of the following user types:
> unmarked - unmarked -> MOH is no longer played to the first user who "entered"
> waitmarked - marked -> MOH is no longer played to the waitmarked user who "entered" first.
> unmarked - waitmarked -> MOH is played to both users since the conference has not started.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121212/c797f852/attachment-0001.htm>