----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4549/#review14967 -----------------------------------------------------------
/branches/13/funcs/func_holdintercept.c <https://reviewboard.asterisk.org/r/4549/#comment25583> Nit picky: is res really needed here? /branches/13/res/stasis/app.c <https://reviewboard.asterisk.org/r/4549/#comment25584> I don't think these are needed. The sub_default_handler already does this and should be invoked for them. /branches/13/res/stasis/control.c <https://reviewboard.asterisk.org/r/4549/#comment25585> This is substantially changing the behavior. ast_indicate will tell the channel to go on hold or off hold. ast_queue_hold/ast_queue_unhold will queue a frame as if the channel has said it is on hold or off hold. - Joshua Colp On March 28, 2015, 3:19 a.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4549/ > ----------------------------------------------------------- > > (Updated March 28, 2015, 3:19 a.m.) > > > Review request for Asterisk Developers and Joshua Colp. > > > Bugs: ASTERISK-24922 > https://issues.asterisk.org/jira/browse/ASTERISK-24922 > > > Repository: Asterisk > > > Description > ------- > > For some applications - such as SLA - a phone pressing hold should not behave > in the fashion that the Asterisk core would like it to. Instead, the hold > action has some application specific behaviour associated with it - such as > disconnecting the channel that initiated the hold; only playing MoH to > channels in the bridge if the channels are of a particular type, etc. > > One way of accomplishing this is to use a framehook to intercept the > hold/unhold frames, raise an event, and eat the frame. Tasty. The patch > attached to this issue accomplished that as a new dialplan function, > HOLD_INTERCEPT. > > In addition: > * ARI now queues hold/unhold frames instead of indicating frames directly. > This allows for the Stasis hold/unhold messages to be raised. > * Some general cleanup of raising hold/unhold Stasis messages was done, > including removing some RAII_VAR usage. > > > Diffs > ----- > > /branches/13/rest-api/api-docs/events.json 433677 > /branches/13/res/stasis/control.c 433677 > /branches/13/res/stasis/app.c 433677 > /branches/13/res/ari/ari_model_validators.c 433677 > /branches/13/res/ari/ari_model_validators.h 433677 > /branches/13/main/stasis_channels.c 433677 > /branches/13/main/manager_channels.c 433677 > /branches/13/main/channel.c 433677 > /branches/13/main/bridge_channel.c 433677 > /branches/13/funcs/func_holdintercept.c PRE-CREATION > /branches/13/CHANGES 433677 > > Diff: https://reviewboard.asterisk.org/r/4549/diff/ > > > Testing > ------- > > See Gerrit reviews: > > https://gerrit.asterisk.org/#/c/16 > https://gerrit.asterisk.org/#/c/17 > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- 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
