[asterisk-dev] [Code Review] 3068: ARI: provide a default format capability to channels that are created

[Joshua Colp]

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

Ship it!


Ship It!

- Joshua Colp


On Dec. 12, 2013, 5:55 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3068/
> -----------------------------------------------------------
> 
> (Updated Dec. 12, 2013, 5:55 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22962
>     https://issues.asterisk.org/jira/browse/ASTERISK-22962
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When creating channels via ARI, the current code fails to provide any default format capabilities. For non-virtual channels this isn't really a problem - the channels typically receive their capabilities as a result of the underlying channel driver configuration. For virtual channels (such as Local channels), the lack of any format capabilities causes the Asterisk core to make some 'odd' choices with respect to the translation paths. The issue reporter had some paths that had 3 hops on each channel leg, causing multiple transcodings and some really crappy audio/performance.
> 
> By specifying a baseline of SLIN, we prevent that from occurring. Note that this is what AMI does when it performs an Originate, as does res_clioriginate.
> 
> Note that this does not solve the odd translation paths that were created or some other more deep performance issues in the translation/format capability core. Those should be addressed separately of this problem.
> 
> 
> Diffs
> -----
> 
>   /branches/12/res/ari/resource_channels.c 403703 
> 
> Diff: https://reviewboard.asterisk.org/r/3068/diff/
> 
> 
> Testing
> -------
> 
> Without this patch: bad audio, bad performance.
> With this patch: acceptable performance/audio.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131216/6f218389/attachment-0001.html>