----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4600/ -----------------------------------------------------------
(Updated April 8, 2015, 1:14 p.m.) Status ------ This change has been marked as submitted. Review request for Asterisk Developers. Changes ------- Committed in revision 434424 Bugs: ASTERISK-24841 https://issues.asterisk.org/jira/browse/ASTERISK-24841 Repository: Asterisk Description ------- When a channel enters the bridging system it is first made compatible with the bridge and then the bridge technology makes the channel compatible with the technology. For all but the DAHDI native and softmix bridge technologies the make channel compatible with the bridge step is an effective noop because the other technologies allow all audio formats. For the DAHDI native bridge technology it doesn't matter because it is not an initial bridge technology and chan_dahdi allows only one native format per channel. For the softmix bridge technology, it is a noop at best and harmful at worst because the wrong translation path could be setup if the channel's native formats allow more than one audio format. This is an intermediate patch for a series of patches aimed at improving translation path choices. * Removed code dealing with the unnecessary step of making the channel compatible with the bridge. Diffs ----- /branches/13/main/bridge.c 434401 /branches/13/include/asterisk/bridge_technology.h 434401 /branches/13/channels/dahdi/bridge_native_dahdi.c 434401 /branches/13/bridges/bridge_softmix.c 434401 /branches/13/bridges/bridge_simple.c 434401 /branches/13/bridges/bridge_native_rtp.c 434401 /branches/13/bridges/bridge_holding.c 434401 Diff: https://reviewboard.asterisk.org/r/4600/diff/ Testing ------- Since the removed code is a noop for all bridge technologies but softmix and without the code identified in ASTERISK-24841 allowing the PJSIP native format capabilities to hold more than one audio format at a time, there is no difference between the patch being applied or not. Calls using G.722 into ConfBridge still work. Thanks, rmudgett
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev