<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 07/03/14 08:21, Matthew Jordan wrote:
<blockquote
cite="mid:CAN2PU+7vENZb0izVnxStmZcTyTWPt0YrxaH+WKpqhUQk1-9XqA@mail.gmail.com"
type="cite">
<div dir="ltr">On Thu, Mar 6, 2014 at 3:42 PM, Damien Wedhorn <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:voip@facts.com.au" target="_blank">voip@facts.com.au</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
<div>
<div class="h5"> On 07/03/14 07:29, Matthew Jordan
wrote:
<blockquote type="cite">
<div dir="ltr"> On Thu, Mar 6, 2014 at 3:22 PM,
Paul Belanger <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:paul.belanger@polybeacon.com"
target="_blank">paul.belanger@polybeacon.com</a>></span>
wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>
<div>On Thu, Mar 6, 2014 at 3:31 PM,
George Joseph<br>
<<a moz-do-not-send="true"
href="mailto:george.joseph@fairview5.com"
target="_blank">george.joseph@fairview5.com</a>>
wrote:<br>
><br>
</div>
</div>
For me to be on-board with the change,
we'd have to apply it to all<br>
channel drives that implement said codecs
allow / disallow logic, so<br>
sip.conf, chan_ooh323.conf, gtalk.conf,
h323.conf, iax.conf,<br>
jingle.conf.<br>
<br>
That way all our documentation /
functionality is consistent among<br>
channel drivers.<br>
<span></span><br>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">Yeah... that will never
happen.<br>
</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
</div>
</div>
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".<span
class="HOEnZb"></span><br>
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">Damien asked me about this in
#asterisk-dev, and I should apologize here - that was a bit of
a glib response.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
<br>
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.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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?<br>
<br>
</div>
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">So: no, I don't think it's correct to
require non-breaking changes to be propagated over to all
other channel drivers. <br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">
Matt<br>
<br>
</div>
</div>
</blockquote>
<br>
Thanks Matt<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Damien<br>
</body>
</html>