[asterisk-dev] PJSIP: allow/disallow or codecs?

[Matthew Jordan]

On Thu, Mar 6, 2014 at 4:32 PM, Damien Wedhorn <voip at facts.com.au> wrote:

>  On 07/03/14 08:21, Matthew Jordan wrote:
>
> On Thu, Mar 6, 2014 at 3:42 PM, Damien Wedhorn <voip at facts.com.au> wrote:
>
>>   On 07/03/14 07:29, Matthew Jordan wrote:
>>
>>  On Thu, Mar 6, 2014 at 3:22 PM, Paul Belanger <
>> paul.belanger at polybeacon.com> wrote:
>>
>>>  On Thu, Mar 6, 2014 at 3:31 PM, George Joseph
>>> <george.joseph at fairview5.com> 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 :-)

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140307/ed3b96b7/attachment.html>