[test-results] [Bamboo] Asterisk - 10 > Ubuntu Lucid (10.04) > #910 has FAILED (2 tests failed, 1 failures were new). Change made by Terry Wilson and Russell Bryant.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - 10 > Ubuntu Lucid (10.04) > #910 failed.
-----------------------------------------------------------------------
Code has been updated by Terry Wilson, Russell Bryant.
2/195 tests failed, 1 failure was new.

http://bamboo.asterisk.org/browse/AST10-LUCID-910/


--------------
Failing Jobs
--------------
  - amd64 (Default Stage): 2 of 195 tests failed.


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

>Merged revisions 351182 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r351182 | russell | 2012-01-16 20:37:03 -0500 (Mon, 16 Jan 2012) | 22 lines
>  
>  Add some missing locking in chan_sip.
>  
>  This patch adds some missing locking to the function 
>  send_provisional_keepalive_full().  This function is called from the scheduler,
>  which is processed in the SIP monitor thread.  The associated channel (or pbx)
>  thread will also be using the same sip_pvt and ast_channel so locking must be
>  used.  The sip_pvt_lock_full() function is used to ensure proper locking order
>  in a safe manner.
>  
>  In passing, document a suspected reference counting error in this function.
>  The "fix" is left commented out because when the "fix" is present, crashes
>  occur.  My theory is that fixing it is exposing a reference counting error
>  elsewhere, but I don't know where.  (Or my analysis of this being a problem
>  could have been completely wrong in the first place).  Leave the comment in
>  the code for so that someone may investigate it again in the future.
>  
>  Also add a bit of doxygen to transmit_provisional_response().
>  
>  (closes issue ASTERISK-18979)
>  
>  Review: https://reviewboard.asterisk.org/r/1648
>........
>

Terry Wilson (351131):

>Ensure ACK retransmit & hangup on non-200 response to INVITE
>
>When handling a non-2xx final response on an INVITE transaction, we have to
>keep the transaction around after we send an ACK in case we receive a
>retransmission of the response so we can re-transmit the ACK, but also tear
>down the ast_channel as soon as we transmit the ACK. Before this patch, we
>could fail at both of these things. Calling sip_alreadygone/needdestroy
>prevented us from keeping the transaction up and retransmitting the ACK, and
>queueing CONGESTION was not sufficient to cause the channel to be torn down
>when originating calls via the CLI, for example.
>
>This patch queues a hangup with CONGESTION instead of just queueing CONGESTION
>for these responses and removes the sip_alreadygone and sip_needdestroy calls
>from handle_response_invite on non-2xx responses. It relies on the hangup
>calling sip_scheddestroy.
>
>For more information, see section 17.1.1.1 of RFC 3261.
>
>(closes issue ASTERISK-17717)
>Review: https://reviewboard.asterisk.org/r/1672/
>........
>
>Merged revisions 351130 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>


--------------
Tests
--------------
New Test Failures (1)
   - AsteriskTestSuite: S/channels/ s i p/codec negotiation
Existing Test Failures (1)
   - AsteriskTestSuite: S/fax/gateway mix2

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