<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 4:32 PM, Damien Wedhorn <span dir="ltr"><<a href="mailto:voip@facts.com.au" target="_blank">voip@facts.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
  
  <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 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 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 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"><font color="#888888"></font></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 class="gmail_extra"><br>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div><div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div></div>