[test-results] [Bamboo] Asterisk - Trunk > FreeBSD 8.1 > #178 was SUCCESSFUL (with 96 tests). Change made by 9 authors.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - Trunk > FreeBSD 8.1 > #178 was successful.
-----------------------------------------------------------------------
This build occurred because it is a dependant of ASTTRUNK-LUCID-386.
96 tests in total.

http://bamboo.asterisk.org/browse/ASTTRUNK-FREEBSD81-178/


--------------
Code Changes
--------------
rmudgett (309446):

>Merged revisions 309445 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
>  
>  Get real channel of a DAHDI call.
>  
>  Starting with Asterisk v1.8, the DAHDI channel name format was changed for
>  ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
>  
>  There were several reasons that the channel name had to change.
>  
>  1) Call completion requires a device state for ISDN phones.  The generic
>  device state uses the channel name.
>  
>  2) Calls do not necessarily have B channels.  Calls placed on hold by an
>  ISDN phone do not have B channels.
>  
>  3) The B channel a call initially requests may not be the B channel the
>  call ultimately uses.  Changes to the internal implementation of the
>  Asterisk master channel list caused deadlock problems for chan_dahdi if it
>  needed to change the channel name.  Chan_dahdi no longer changes the
>  channel name.
>  
>  4) DTMF attended transfers now work with ISDN phones because the channel
>  name is "dialable" like the chan_sip channel names.
>  
>  For various reasons, some people need to know which B channel a DAHDI call
>  is using.
>  
>  * Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
>  CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
>  in use by the channel.  Use CHANNEL(no_media_path) to determine if the
>  channel even has a B channel.
>  
>  * Added AMI event DAHDIChannel to associate a DAHDI channel with an
>  Asterisk channel so AMI applications can passively determine the B channel
>  currently in use.  Calls with "no-media" as the DAHDIChannel do not have
>  an associated B channel.  No-media calls are either on hold or
>  call-waiting.
>  
>  (closes issue #17683)
>  Reported by: mrwho
>  Tested by: rmudgett
>  
>  (closes issue #18603)
>  Reported by: arjankroon
>  Patches:
>        issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
>  Tested by: stever28, rmudgett
>........
>

Tilghman Lesher (309809):

>Merged revisions 309808 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>................
>  r309808 | tilghman | 2011-03-06 18:54:42 -0600 (Sun, 06 Mar 2011) | 14 lines
>  
>  Merged revisions 309251 via svnmerge from 
>  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
>  
>  ........
>    r309251 | tilghman | 2011-03-01 19:06:02 -0600 (Tue, 01 Mar 2011) | 7 lines
>    
>    Revert previous 2 commits, and instead conditionally redefine the same macro used in flex 2.5.35 that clashed with our workaround.
>    
>    Not surprisingly, the workaround was exactly the same code as was provided by
>    the Flex maintainers, albeit in two different places, in different macros.
>    
>    This should fix the FreeBSD builds, which have an older version of Flex.
>  ........
>................
>

Mark Michelson (309766):

>Merged revisions 309765 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.8
>
>........
>  r309765 | mmichelson | 2011-03-06 18:13:36 -0600 (Sun, 06 Mar 2011) | 3 lines
>  
>  Indicate that Asterisk uses the Allow header to determine if MESSAGE requests should be sent.
>........
>


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