[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. 11, 2012, 1:17 p.m.)


Review request for Asterisk Developers.


Changes
-------

Add ast_bridge_lock()/ast_bridge_unlock() calls to the bridging API so ConfBridge does not need to know that ast_bridge is an ao2 object.


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 (updated)
-----

  /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/20121211/0b26062a/attachment-0001.htm>