Merged revisions 269821 via svnmerge from
authorMark Michelson <mmichelson@digium.com>
Thu, 10 Jun 2010 19:34:03 +0000 (19:34 +0000)
committerMark Michelson <mmichelson@digium.com>
Thu, 10 Jun 2010 19:34:03 +0000 (19:34 +0000)
commite8d2153da6c8d66e2c1089e42bbbf08436f102fd
treeb116664fa2b51c88689009ab942ce50ddf5cebfc
parent326c78368501ef8fecd3c10b286b5294a693536f
Merged revisions 269821 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r269821 | mmichelson | 2010-06-10 14:30:12 -0500 (Thu, 10 Jun 2010) | 19 lines

  Fix potential crash when writing raw SLIN audio on a PLC-enabled channel.

  The issue here was that the frame created when adjusting for PLC had no offset
  to its audio data. If this frame were translated to another format prior to
  being sent out an RTP socket, all went well because the translation code would
  put an appropriate offset into the frame. However, if the SLIN audio were not
  translated before being sent out the RTP socket, bad things would happen.
  Specifically, the ast_rtp_raw_write makes the assumption that the frame has
  at least enough of an offset that it can accommodate an RTP header. This was
  not the case. As such, data was being written prior to the allocation, likely
  corrupting the data the memory allocator had written. Thus when the time came
  to free the data, all hell broke loose. ....Well, Asterisk crashed at least.

  The fix was just what one would expect. Offset the data in the frame by a reasonable
  amount. The method I used is a bit odd since the data in the frame is 16 bit integers
  and not bytes. I left a big ol' comment about it. This can be improved on if someone
  is interested. I was more interested in getting the crash resolved.
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269822 65c4cc65-6c06-0410-ace0-fbb531ad65f3
main/channel.c