[test-results] [Bamboo] Asterisk > trunk - Linux - x86_64 > #382 has FAILED (1 tests failed). Change made by rmudgett.

[Bamboo]

-------------- next part --------------
-----------------------------------------------------------------------
Asterisk > trunk - Linux - x86_64 > #382 failed.
-----------------------------------------------------------------------
Code has been updated by rmudgett.
1/116 tests failed.

http://bamboo.asterisk.org/browse/AST-TRUNK-382/


--------------
Failing Jobs
--------------
  - Asterisk Job (Asterisk): 1 of 116 tests failed.


--------------
Code Changes
--------------
rmudgett (295867):

>Merged revisions 295866 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
>  
>  Merged revisions 295843 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
>    
>    Merged revisions 295790 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
>      
>      The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
>      
>      To recreate the problem:
>      1) Party A calls Party B
>      2) Invoke CLI "channel redirect" command to redirect channel call leg
>      associated with A.
>      3) All associated channels are hung up.
>      
>      Note that if the CLI command were done on the channel call leg associated
>      with B it works.
>      
>      This regression was a result of the fix for issue #16946
>      (https://reviewboard.asterisk.org/r/740/).
>      
>      The regression affects all features that use an async goto to execute the
>      dialplan because of an external event: Channel redirect, AMI redirect, SIP
>      REFER, and FAX detection.
>      
>      The struct ast_channel._softhangup code is a mess.  The variable is used
>      for several purposes that do not necessarily result in the call being hung
>      up.  I have added doxygen comments to describe how the various _softhangup
>      bits are used.  I have corrected all the places where the variable was
>      tested in a non-bit oriented manner.
>      
>      The primary fix is the new AST_CONTROL_END_OF_Q frame.  It acts as a weak
>      hangup request so the soft hangup requests that do not normally result in
>      a hangup do not hangup.
>      
>      JIRA SWP-2470
>      JIRA SWP-2489
>      
>      (closes issue #18171)
>      Reported by: SantaFox
>      (closes issue #18185)
>      Reported by: kwemheuer
>      (closes issue #18211)
>      Reported by: zahir_koradia
>      (closes issue #18230)
>      Reported by: vmarrone
>      (closes issue #18299)
>      Reported by: mbrevda
>      (closes issue #18322)
>      Reported by: nerbos
>      
>      Review:	https://reviewboard.asterisk.org/r/1013/
>    ........
>  ................
>................
>


--------------
Tests
--------------
New Test Failures (1)
   - AsteriskTestSuite: Chanspy/chanspy barge

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