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

[rmudgett]

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

(Updated Dec. 7, 2012, 9:32 a.m.)


Review request for Asterisk Developers.


Changes
-------

Fixed waitmarked and marked users entering at the same time.


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.


This addresses bug ASTERISK-20606.
    https://issues.asterisk.org/jira/browse/ASTERISK-20606


Diffs (updated)
-----

  /branches/10/apps/app_confbridge.c 377376 
  /branches/10/apps/confbridge/conf_state.c 377376 
  /branches/10/apps/confbridge/conf_state_multi_marked.c 377376 
  /branches/10/apps/confbridge/include/confbridge.h 377376 

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.


Thanks,

rmudgett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121207/0509d6e8/attachment.htm>