[asterisk-dev] [Code Review] Use the proper type for ast_codec_pref's framing field so that packetization values > 127 can be used

[David Vossel]

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

Ship it!


Works for me.  Hard coded values like that usually scare me, but this '64' value will always be the case for 1.8.  Asterisk 10 uses a defined value for these arrays, so simply making it an int instead of a char should be fine.

- David


On Dec. 21, 2011, 11:35 p.m., Terry Wilson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1639/
> -----------------------------------------------------------
> 
> (Updated Dec. 21, 2011, 11:35 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> ast_codec_pref has a framing field that is set as a signed char array even though every place in the code treats it as an int array. This just changes the field to an int array. It uses a magic number, but it is essentially the same thing that was there before. We could probably move the AST_FORMAT_LIST into the header and use its ARRAY_LEN as the size so that things are no bigger than they need to be. I figured I'd go with the smallest change first and see what people thought.
> 
> 
> This addresses bug ASTERISK-18876.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18876
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/frame.h 348793 
> 
> Diff: https://reviewboard.asterisk.org/r/1639/diff
> 
> 
> Testing
> -------
> 
> Made calls with allow=g729:230 and saw that it was used whereas before it looped around to a lower value.
> 
> 
> Thanks,
> 
> Terry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111222/3452f058/attachment.htm>