<!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 08/03/14 01:14, Matthew Jordan wrote:
<blockquote
cite="mid:CAN2PU+5_L5ZzFQQvbT8JPkwepYDxs81UzEC9pFP+xF_B2OJFmw@mail.gmail.com"
type="cite">
<div dir="ltr">On Thu, Mar 6, 2014 at 4:32 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 08:21, Matthew Jordan
wrote:
<blockquote 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> 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></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>
</div>
</div>
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.<span class="HOEnZb"></span><br
clear="all">
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">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 :-)<br>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Damien<br>
</body>
</html>