> On March 12, 2014, 11:19 a.m., David Lee wrote: > > branches/12/res/stasis/control.c, line 878 > > <https://reviewboard.asterisk.org/r/3336/diff/1/?file=55802#file55802line878> > > > > This probably deserves a comment as to why we're doing a subscribe > > here, but we also have other logic for subscribing to the bridge a channel > > is in. > > > > Actually, if this works, then we might be able to get rid of the other > > logic. This method is certainly a lot simpler.
I'll add the comment with some explanation. I'd rather keep both because by removing the other mechanism for automatic bridge subscriptions, you risk causing the opposite problem of missing the ChannelLeftBridge event since the message may still be in flight when the subscription is removed. A possible way to mitigate that would be to wait for the appropriate topic(s) to flush. - opticron ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3336/#review11152 ----------------------------------------------------------- On March 12, 2014, 8:33 a.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3336/ > ----------------------------------------------------------- > > (Updated March 12, 2014, 8:33 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23295 > https://issues.asterisk.org/jira/browse/ASTERISK-23295 > > > Repository: Asterisk > > > Description > ------- > > This fixes an issue where a Stasis application running over ARI and > subscribed to ari/events could miss the ChannelEnteredBridge event because it > did not subscribe to the new bridge fast enough. > > To accomplish this, it subscribes the application controlling the channel to > the new bridge before adding it to that bridge which required the > stasis_app_control structure to maintain a reference to the stasis_app. > > > Diffs > ----- > > branches/12/res/stasis/control.c 410448 > branches/12/res/stasis/control.h 410448 > branches/12/res/res_stasis.c 410448 > > Diff: https://reviewboard.asterisk.org/r/3336/diff/ > > > Testing > ------- > > Ensured that the ARI tests still functioned since I was unable to reproduce > the bug this fixes. > > > Thanks, > > opticron > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
