[asterisk-dev] [Code Review] 4549: ARI: Add the ability to intercept hold and raise an event

[Matt Jordan]

> On March 31, 2015, 8:21 a.m., Joshua Colp wrote:
> > /branches/13/res/stasis/control.c, lines 609-622
> > <https://reviewboard.asterisk.org/r/4549/diff/1/?file=73161#file73161line609>
> >
> >     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.

This really shouldn't have been done. I was hoping to make use of ARI to test 'standard' hold in addition to the hold interception here; as it is, that's actually much harder, since we don't get an ARI event when using POST /channels/hold.

It's also ancillary to this change.

As it is, I'm going to just revert this change, and restructure the tests accordingly.


- Matt


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


On March 27, 2015, 10:19 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4549/
> -----------------------------------------------------------
> 
> (Updated March 27, 2015, 10:19 p.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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150406/88e94dbd/attachment.html>