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

Paul Belanger paul.belanger at polybeacon.com
Fri Mar 7 08:19:58 CST 2014


On Thu, Mar 6, 2014 at 5: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.
>
Right, that is my logic as well. At a minimum core channel drivers
should idea act the same, extended or deprecated could be update as
community developers were able too.

> 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.
>
> Damien
>

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger



More information about the asterisk-dev mailing list