summaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorMark Michelson <mmichelson@digium.com>2010-06-10 19:34:03 +0000
committerMark Michelson <mmichelson@digium.com>2010-06-10 19:34:03 +0000
commite8d2153da6c8d66e2c1089e42bbbf08436f102fd (patch)
treeb116664fa2b51c88689009ab942ce50ddf5cebfc /Makefile
parent326c78368501ef8fecd3c10b286b5294a693536f (diff)
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
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions