[asterisk-dev] [Code Review] 3835: chan_iax2: Restore previous iax2_best_codec behavior

opticron reviewboard at asterisk.org
Tue Jul 22 09:24:35 CDT 2014


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

Ship it!


Ship It!

- opticron


On July 22, 2014, 8:18 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3835/
> -----------------------------------------------------------
> 
> (Updated July 22, 2014, 8:18 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> During the media formats work the iax2_best_codec function in chan_iax2 was changed to turn the formats into a format capabilities structure and to grab the first format from it. This imposes an explicit preference depending on the order of how old bitfield based formats are mapped to new style formats. This preference differed from the old code. The acl_call test exposed this because it does not have any disallow or allow configuration. It uses the defaults provided by chan_iax2. This default includes g723, which is not a codec we can transcode. Due to the ordering g723 is the first format in the capabilities structure when doing the conversion causing it to get chosen as the format in use. As this test plays tones and we can't transcode g723... the test failed. The attached change restores the previous behavior of iax2_best_codec by using a specific hard coded preference list (which was taken from Asterisk 12).
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_iax2.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3835/diff/
> 
> 
> Testing
> -------
> 
> Ran acl_call test, it passes once again.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

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


More information about the asterisk-dev mailing list