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

[Damien Wedhorn]

On 08/03/14 01:14, Matthew Jordan wrote:
> On Thu, Mar 6, 2014 at 4:32 PM, Damien Wedhorn <voip at facts.com.au 
> <mailto: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
>>     <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.
>
>
> 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 :-)
Sorry, didn't explain myself. My issue was the there's a big PJSIP in 
the subject line when in fact that particular part of the discussion was 
about every other channel other than PJSIP. I think it would be 
reasonable to assume that many not involved/interested in PJSIP would 
just delete the email based on the subject line.

My suggestion was that when issues become broader, they could be 
highlighted, possibly even just a cut and paste of the relevant part to 
a new email with a subject that doesn't include a specific PJSIP reference.

Damien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140308/7575c50d/attachment.html>