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

Matthew Jordan mjordan at digium.com
Thu Mar 6 16:21:57 CST 2014


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

-- 
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/20140306/9b8f5ffc/attachment.html>


More information about the asterisk-dev mailing list