On Thu, Mar 6, 2014 at 5:32 PM, Damien Wedhorn <[email protected]> wrote: > On 07/03/14 08:21, Matthew Jordan wrote: > > 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 > > > Thanks Matt > > A couple of observations. While I agree with your general advice of not > restricting changes where consistency can't be done, where reasonably > trivial (eg, setting codecs as an alias for any channel driver using allow), > it would be nice to try and make such changes consistent. > > I guess it becomes a matter of where do you draw the line in the sand. > Basically, if a change is going to be made, other drivers should be > considered. > Right, that is my logic as well. At a minimum core channel drivers should idea act the same, extended or deprecated could be update as community developers were able too.
> The second thing, I only picked this up by luck. A couple of words caught my > eye as I deleted a PJSIP email not relevant to my stuff. It may be worth > considering how this type of information can be reliably shared to > interested parties. > > Damien > -- Paul Belanger | PolyBeacon, Inc. Jabber: [email protected] | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _____________________________________________________________________ -- 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
