[test-results] [Bamboo] No agents to build plan Asterisk - Trunk - CentOS 5.5 - i386

Tue Jan 18 18:20:32 CST 2011

-------------------------------------------------------------------------------
ASTTRUNK-CENTOS55-I386-151 has been queued, but there's no agent capable of building it.
-------------------------------------------------------------------------------

http://bamboo.asterisk.org/browse/ASTTRUNK-CENTOS55-I386/log

--------------
Code Changes
--------------
rmudgett (302178):

>Merged revisions 302174 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r302174 | rmudgett | 2011-01-18 12:11:43 -0600 (Tue, 18 Jan 2011) | 102 lines
>  
>  Merged revisions 302173 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ................
>    r302173 | rmudgett | 2011-01-18 12:07:15 -0600 (Tue, 18 Jan 2011) | 95 lines
>    
>    Merged revisions 302172 via svnmerge from 
>    https://origsvn.digium.com/svn/asterisk/branches/1.4
>    
>    ........
>      r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
>      
>      Issues with DTMF triggered attended transfers.
>      
>      Issue #17999
>      1) A calls B. B answers.
>      2) B using DTMF dial *2 (code in features.conf for attended transfer).
>      3) A hears MOH. B dial number C
>      4) C ringing. A hears MOH.
>      5) B hangup. A still hears MOH. C ringing.
>      6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
>      For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
>      
>      Problem: When A and B hangup, C is still ringing.
>      
>      Issue #18395
>      SIP call limit of B is 1
>      1. A call B, B answered
>      2. B *2(atxfer) call C
>      3. B hangup, C ringing
>      4. Timeout waiting for C to answer
>      5. Recall to B fails because B has reached its call limit.
>      
>      Because B reached its call limit, it cannot do anything until the transfer
>      it started completes.
>      
>      Issue #17273
>      Same scenario as issue 18395 but party B is an FXS port.  Party B cannot
>      do anything until the transfer it started completes.  If B goes back off
>      hook before C answers, B hears ringback instead of the expected dialtone.
>      
>      **********
>      Note for the issue #17273 and #18395 fix:
>      
>      DTMF attended transfer works within the channel bridge.  Unfortunately,
>      when either party A or B in the channel bridge hangs up, that channel is
>      not completely hung up until the transfer completes.  This is a real
>      problem depending upon the channel technology involved.
>      
>      For chan_dahdi, the channel is crippled until the hangup is complete.
>      Either the channel is not useable (analog) or the protocol disconnect
>      messages are held up (PRI/BRI/SS7) and the media is not released.
>      
>      For chan_sip, a call limit of one is going to block that endpoint from any
>      further calls until the hangup is complete.
>      
>      For party A this is a minor problem.  The party A channel will only be in
>      this condition while party B is dialing and when party B and C are
>      conferring.  The conversation between party B and C is expected to be a
>      short one.  Party B is either asking a question of party C or announcing
>      party A.  Also party A does not have much incentive to hangup at this
>      point.
>      
>      For party B this can be a major problem during a blonde transfer.  (A
>      blonde transfer is our term for an attended transfer that is converted
>      into a blind transfer.  :)) Party B could be the operator.  When party B
>      hangs up, he assumes that he is out of the original call entirely.  The
>      party B channel will be in this condition while party C is ringing, while
>      attempting to recall party B, and while waiting between call attempts.
>      
>      WARNING:
>      The ATXFER_NULL_TECH conditional is a hack to fix the problem.  It will
>      replace the party B channel technology with a NULL channel driver to
>      complete hanging up the party B channel technology.  The consequences of
>      this code is that the 'h' extension will not be able to access any channel
>      technology specific information like SIP statistics for the call.
>      
>      ATXFER_NULL_TECH is not defined by default.
>      **********
>      
>      (closes issue #17999)
>      Reported by: iskatel
>      Tested by: rmudgett
>      JIRA SWP-2246
>      
>      (closes issue #17096)
>      Reported by: gelo
>      Tested by: rmudgett
>      JIRA SWP-1192
>      
>      (closes issue #18395)
>      Reported by: shihchuan
>      Tested by: rmudgett
>      
>      (closes issue #17273)
>      Reported by: grecco
>      Tested by: rmudgett
>      
>      Review: https://reviewboard.asterisk.org/r/1047/
>    ........
>  ................
>................
>

russell (302268):

>Merged revisions 302267 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r302267 | russell | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 5 lines
>  
>  Don't enable AO2_DEBUG by default if AST_DEVMODE is on.
>  
>  AO2_DEBUG is not important and is causing a false compiler warning to be
>  generated on my Ubuntu Natty dev box.
>........
>

jpeeler (302270):

>Merged revisions 302266 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r302266 | jpeeler | 2011-01-18 14:19:57 -0600 (Tue, 18 Jan 2011) | 34 lines
>  
>  Merged revisions 302265 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ........
>    r302265 | jpeeler | 2011-01-18 14:13:52 -0600 (Tue, 18 Jan 2011) | 27 lines
>    
>    Convert device state callbacks to ao2 objects to fix a deadlock in chan_sip.
>    
>    Lock scenario presented here:
>    Thread 1
>     holds ast_rdlock_contexts &conlock
>     holds handle_statechange hints
>     holds handle_statechange hint
>      waiting for cb_extensionstate
>       Locked Here: chan_sip.c line 7428 (find_call)
>    Thread 2
>     holds handle_request_do &netlock
>     holds find_call sip_pvt_ptr
>      waiting for ast_rdlock_contexts &conlock
>       Locked Here: pbx.c line 9911 (ast_rdlock_contexts)
>    
>    Chan_sip has an established locking order of locking the sip_pvt and then
>    getting the context lock. So the as stated by the summary, the operations in
>    thread 2 have been modified to no longer require the context lock.
>    
>    (closes issue #18310)
>    Reported by: one47
>    Patches: 
>          statecbs_ao2.mk2.patch uploaded by one47 (license 23),
>          modified by me
>    
>    Review: https://reviewboard.asterisk.org/r/1072/
>  ........
>................
>


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