On Thu, Mar 6, 2014 at 3:42 PM, Damien Wedhorn <[email protected]> wrote:
> On 07/03/14 07:29, Matthew Jordan wrote: > > > On Thu, Mar 6, 2014 at 3:22 PM, Paul Belanger < > [email protected]> wrote: > >> On Thu, Mar 6, 2014 at 3:31 PM, George Joseph >> <[email protected]> wrote: >> > >> For me to be on-board with the change, we'd have to apply it to all >> channel drives that implement said codecs allow / disallow logic, so >> sip.conf, chan_ooh323.conf, gtalk.conf, h323.conf, iax.conf, >> jingle.conf. >> >> That way all our documentation / functionality is consistent among >> channel drivers. >> >> > Yeah... that will never happen. > > I assume this is about the codecs option. If so, why couldn't it be > implemented in all the channel drivers. Surely the "codecs list" option > could be a simple wrapper for "disallow all, allow list". > Damien asked me about this in #asterisk-dev, and I should apologize here - that was a bit of a glib response. The reality is that some channel drivers have active maintainers, and core changes that are made (or 'better ways of doing things') do get actively made in those channel drivers. This is the case with chan_skinny, chan_ooh323, and chan_unistim. The channel driver maintainers have done an excellent job working together with the community to keep up with the changes in Asterisk 12. Others, however, have no active maintainer. This doesn't mean they never get a bug fix, or that they are broken in Asterisk 12, but it does mean that there is no one who actively works to keep the channel driver working with all of the latest changes. During Asterisk 12, we spent a lot of time working through all of the channel drivers for the changes in the Asterisk core. If we hadn't done that, they would have been broken by the transfer, pickup, and parking changes. I think that's a fair requirement on the project: if you make a change in the core and it breaks someone, it's on you to go fix it. The question then becomes: do we limit any changes to supported channel drivers if we do not reflect those changes in an unsupported channel driver? I don't think that's a fair requirement. It burdens the project: any incremental improvement in chan_pjsip, or chan_sip, or any channel driver really - has to be reflected across all channel drivers. And not all channel drivers are equal: making a configuration change in chan_pjsip is vastly different then making that change in chan_dahdi. So: no, I don't think it's correct to require non-breaking changes to be propagated over to all other channel drivers. Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org
-- _____________________________________________________________________ -- 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
