[test-results] [Bamboo] No agents to build plan Asterisk - Trunk - FreeBSD 8.1 - i386

[Bamboo]

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

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

--------------
Code Changes
--------------
rmudgett (320820):

>Merged revisions 320796 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r320796 | rmudgett | 2011-05-25 11:23:11 -0500 (Wed, 25 May 2011) | 17 lines
>  
>  Give zombies a safe channel driver to use.
>  
>  Recent crashes from zombie channels suggests that they need a safe home to
>  goto.  When a masquerade happens, the physical part of the zombie channel
>  is hungup.  The hangup normally sets the channel private pointer to NULL.
>  If someone then blindly does a callback to the channel driver, a crash is
>  likely because the private pointer is NULL.
>  
>  The masquerade now sets the channel technology of zombie channels to the
>  kill channel driver.
>  
>  Related to the following issues:
>  (issue #19116)
>  (issue #19310)
>  
>  Review: https://reviewboard.asterisk.org/r/1224/
>........
>

rmudgett (320825):

>Merged revisions 320823 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r320823 | rmudgett | 2011-05-25 12:06:38 -0500 (Wed, 25 May 2011) | 18 lines
>  
>  The AMI Newstate event contains different information between v1.4 and v1.8.
>  
>  The addition of connected line support in v1.8 changes the behavior of the
>  channel caller ID somewhat.  The channel caller ID value no longer time
>  shares with the connected line ID on outgoing call legs.  The timing of
>  some AMI events/responses output the connected line ID as caller ID.
>  These party ID's are now separate.
>  
>  * The ConnectedLineNum and ConnectedLineName headers were added to many
>  AMI events/responses if the CallerIDNum/CallerIDName headers were also
>  present.
>  
>  (closes issue #18252)
>  Reported by: gje
>  Tested by: rmudgett
>  
>  Review: https://reviewboard.asterisk.org/r/1227/
>........
>

rmudgett (320884):

>Merged revisions 320883 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r320883 | rmudgett | 2011-05-25 17:25:18 -0500 (Wed, 25 May 2011) | 17 lines
>  
>  Native SIP CCSS sends bad CC cancel SUBSCRIBE message.
>  
>  The SUBSCRIBE message used to cancel a CC request has incorrect To/From
>  SIP headers.  They are reversed and the dialog tags are the same when they
>  should not be.  If pedantic mode was disabled, then the cancel would have
>  succeeded despite the incorrect message.
>  
>  * The SIP_OUTGOING flag was not set correctly for the dialog and I had to
>  move some CC subscribe handling code as a result.
>  
>  * Initialized the dialog subscribed type to CALL_COMPLETION earlier.  If a
>  CC request SUBSCRIBE message comes in and the CC instance is not found,
>  the 404 response was duplicated.
>  
>  JIRA AST-568
>  JIRA SWP-3493
>........
>


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