----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3731/#review12532 -----------------------------------------------------------
team/rmudgett/stasis_linkedids/res/res_stasis.c <https://reviewboard.asterisk.org/r/3731/#comment22811> This must be called with chan locked. Accessing datastores on channels must be done with the channel locked. I don't think you are locking chan for most calls to use this datastore. team/rmudgett/stasis_linkedids/res/res_stasis.c <https://reviewboard.asterisk.org/r/3731/#comment22809> This assignment is not necessary as you are going to immediately assign it in the next step. team/rmudgett/stasis_linkedids/res/res_stasis.c <https://reviewboard.asterisk.org/r/3731/#comment22810> Do this unconditionally. ast_free is NULL tollerant so you don't need to test first. team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c <https://reviewboard.asterisk.org/r/3731/#comment22814> obj should be data for consistency with the function typedef. team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c <https://reviewboard.asterisk.org/r/3731/#comment22813> Probably should not exec Stasis if channel is hungup. ast_check_hangup_locked() team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c <https://reviewboard.asterisk.org/r/3731/#comment22815> This should be ast_free(app_name) and swap_chan should be app_name. team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c <https://reviewboard.asterisk.org/r/3731/#comment22816> extra blank line team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c <https://reviewboard.asterisk.org/r/3731/#comment22817> Should these failures remove the queued stasis action? Or should the queued action be done after the failures. - rmudgett On July 8, 2014, 9:03 p.m., opticron wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3731/ > ----------------------------------------------------------- > > (Updated July 8, 2014, 9:03 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23941 > https://issues.asterisk.org/jira/browse/ASTERISK-23941 > > > Repository: Asterisk > > > Description > ------- > > This intercepts channels attempting to enter stasis-controlled bridges that > are not themselves controlled by stasis and routes them through Stasis() to > be controlled by the Stasis application that controls the channels they are > replacing. > > > Diffs > ----- > > team/rmudgett/stasis_linkedids/rest-api/api-docs/events.json 418213 > team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c 418213 > team/rmudgett/stasis_linkedids/res/stasis/control.c 418213 > team/rmudgett/stasis_linkedids/res/stasis/control.h 418213 > team/rmudgett/stasis_linkedids/res/stasis/app.c 418213 > team/rmudgett/stasis_linkedids/res/stasis/app.h 418213 > team/rmudgett/stasis_linkedids/res/res_stasis.c 418213 > team/rmudgett/stasis_linkedids/res/ari/ari_model_validators.c 418213 > team/rmudgett/stasis_linkedids/res/ari/ari_model_validators.h 418213 > > Diff: https://reviewboard.asterisk.org/r/3731/diff/ > > > Testing > ------- > > Tested against the updated ARI attended transfer test in > https://reviewboard.asterisk.org/r/3732/ > > > File Attachments > ---------------- > > Collation of this patch and dependency patches. > > https://reviewboard.asterisk.org/media/uploaded/files/2014/07/09/37484ce9-9db8-4e86-a4b9-3791b8d8b9ac__ari_atxfer.diff > > > 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
