[test-results] [Bamboo] Asterisk > 1.8 - Linux - x86_64 > #373 was SUCCESSFUL (with 59 tests). Change made by Russell Bryant.

[Bamboo]

-------------- next part --------------
-----------------------------------------------------------------------
Asterisk > 1.8 - Linux - x86_64 > #373 was successful.
-----------------------------------------------------------------------
Code has been updated by Russell Bryant.
59 tests in total.

http://bamboo.asterisk.org/browse/AST-18-373/


--------------
Code Changes
--------------
Russell Bryant (296002):

>Merged revisions 296001 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>
>................
>  r296001 | russell | 2010-11-24 11:03:16 -0600 (Wed, 24 Nov 2010) | 45 lines
>  
>  Merged revisions 296000 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.4
>  
>  ........
>    r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
>    
>    Handle failures building translation paths more effectively.
>    
>    The problem scenario occurred on a heavily loaded system that was using the
>    codec_dahdi module and exceeded the hardware transcoding capacity.  The failure
>    mode at that point was not good.  The report came in to us as an Asterisk
>    lock-up.  The "core show locks" shows a ton of threads locked up (but no
>    obvious deadlock).  Upon deeper investigation, when the system is in this
>    state, the CPU was maxed out.  The CPU was being consumed by the Asterisk
>    logger spewing messages on every audio frame for calls set up after transcoder
>    capacity was reached.
>    
>    The purpose of this patch is to make Asterisk handle failures to create a
>    translation path in a more graceful manner.  If we can't translate, then the
>    call just needs to be dropped, as it's not going to work.  These are the
>    changes:
>    
>    1) In set_format() of channel.c (which is called by set_read_format() and
>    set_write_format()), it was ignoring if ast_translator_build_path() failed and
>    returned NULL.  It now pays attention to that case and returns a result
>    reflecting failure.  With this change in place, the bridging code will
>    immediately detect a failure and end the bridge instead of proceeding to try to
>    bridge frames that can't be translated and making channel drivers freak out by
>    sending them frames in a format they weren't expecting.
>    
>    2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
>    ignored.  It is now reflected in the return value of the function.  This didn't
>    turn out to have any affect on the bug, but seemed like a good change to leave
>    in.
>    
>    3) In app_dial(), when only sending a call to a single endpoint, it will
>    attempt to do some bridging of its own of early audio.  It uses
>    make_compatible() when it's going to do this.  However, it ignored failure from
>    make compatible.  So, even with the fix from #1, if there was early audio going
>    through app_dial, there would still be a period of invalid frames passing
>    through.  After detecting failure here, Dial() exits.
>    
>    ABE-2658
>  ........
>................
>


--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/test-results/attachments/20101124/1f4dec2f/attachment.htm