On 07/03/14 08:21, Matthew Jordan wrote:
On Thu, Mar 6, 2014 at 3:42 PM, Damien Wedhorn <[email protected]
<mailto:[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]
<mailto:[email protected]>> wrote:
On Thu, Mar 6, 2014 at 3:31 PM, George Joseph
<[email protected]
<mailto:[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.
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
--
_____________________________________________________________________
-- 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
