[test-results] [Bamboo] Asterisk - Team Branches > Bridge Construction > #406 has FAILED. Change made by root.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - Team Branches > Bridge Construction > #406 failed.
-----------------------------------------------------------------------
Code has been updated by root.
1/2 jobs failed, with 0 failing tests.

http://bamboo.asterisk.org/browse/ASTTEAM-BRIDGECONSTRUCTION-406/


--------------
Failing Jobs
--------------
  - Asterisk 1.8 CentOS 6 32-Bit (CentOS 6): No tests found.



--------------
Code Changes
--------------
root (390758):

>Refactor the features configuration scheme.
>
>Features configuration is handled in its own API in
>features_config.h and features_config.c. This way, features
>configuration is accessible to anything that needs it.
>
>In addition, features configuration has been altered to
>be more channel-oriented. Most callers of features API
>code will be supplying a channel so that the individual
>channel's settings will be acquired rather than the global
>setting.
>
>Missing from this commit is XML documentation for the
>features configuration. That will be handled in a separate
>commit.
>
>Review: https://reviewboard.asterisk.org/r/2578/
>
>(issue ASTERISK-21542)
>........
>
>Merged revisions 390751 from file:///srv/subversion/repos/asterisk/trunk
>

root (390772):

>Reimplement bridging and DTMF features related channel variables in the bridging core.
>
>* The channel variable ATTENDED_TRANSFER_COMPLETE_SOUND is no longer
>channel driver specific.  If the channel variable is set on the
>transferrer channel, the sound will be played to the target of an attended
>transfer.
>
>* The channel variable BRIDGEPEER becomes a comma separated list of peers
>in a multi-party bridge.  The BRIDGEPEER value can have a maximum of 10
>peers listed.  Any more peers in the bridge will not be included in the
>list.  BRIDGEPEER is not valid in holding bridges like parking since those
>channels do not talk to each other even though they are in a bridge.
>
>* The channel variable BRIDGEPVTCALLID is only valid for two party bridges
>and will contain a value if the BRIDGEPEER's channel driver supports it.
>
>* The channel variable DYNAMIC_PEERNAME is redundant with BRIDGEPEER and
>is removed.  The more useful DYNAMIC_WHO_ACTIVATED gives the channel name
>that activated the dynamic feature.
>
>* The channel variables DYNAMIC_FEATURENAME and DYNAMIC_WHO_ACTIVATED are
>set only on the channel executing the dynamic feature.  Executing a
>dynamic feature on the bridge peer in a multi-party bridge will execute it
>on all peers of the activating channel.
>
>(closes issue ASTERISK-21555)
>Reported by: Matt Jordan
>
>Review: https://reviewboard.asterisk.org/r/2582/
>........
>
>Merged revisions 390771 from file:///srv/subversion/repos/asterisk/trunk
>

root (390789):

>Conditionally reject duplicate entries in applicationmap containers.
>
>When reading from a config file, it's important to reject duplicates. Otherwise,
>featuregroups will have ambiguity when pointing to applicationmap items. However,
>when constructing the channel's current applicationmap, we don't care about duplicate
>names since it's the DTMF that identifies a feature, not the name.
>........
>
>Merged revisions 390787 from file:///srv/subversion/repos/asterisk/trunk
>



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