On 08/03/14 01:14, Matthew Jordan wrote:
On Thu, Mar 6, 2014 at 4:32 PM, Damien Wedhorn <[email protected]
<mailto:[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]
<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.
Really, the asterisk-dev mailing list *is* the appropriate place for
this kind of information to be disseminated. It's the heartbeat of
development in Asterisk - we just have to make sure we keep using it :-)
Sorry, didn't explain myself. My issue was the there's a big PJSIP in
the subject line when in fact that particular part of the discussion was
about every other channel other than PJSIP. I think it would be
reasonable to assume that many not involved/interested in PJSIP would
just delete the email based on the subject line.
My suggestion was that when issues become broader, they could be
highlighted, possibly even just a cut and paste of the relevant part to
a new email with a subject that doesn't include a specific PJSIP reference.
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
