<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">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>
<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 07:29, Matthew Jordan wrote:
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra">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_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 class="HOEnZb"><font color="#888888"></font></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 class="gmail_extra">-- <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>