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

Damien Wedhorn voip at facts.com.au
Thu Mar 6 16:32:08 CST 2014


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 
> <mailto: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
>>     <mailto:paul.belanger at polybeacon.com>> wrote:
>>
>>         On Thu, Mar 6, 2014 at 3:31 PM, George Joseph
>>         <george.joseph at fairview5.com
>>         <mailto: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.

Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140307/7d5320a2/attachment-0001.html>


More information about the asterisk-dev mailing list