diff options
author | mmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-06-10 19:34:03 +0000 |
---|---|---|
committer | mmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b> | 2010-06-10 19:34:03 +0000 |
commit | 310570e0f41b2c8283a1ab08876cad929187a218 (patch) | |
tree | b116664fa2b51c88689009ab942ce50ddf5cebfc /Makefile | |
parent | 3de2f800bebff1fe9ef37aec1ea256cb9cb71cd1 (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: http://svn.digium.com/svn/asterisk/trunk@269822 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions