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

[Scott Griepentrog]

So in all the current channel drivers (that need it), the convention is
like such:

disallow = all
allow = ulaw, alaw

Which can also be shortened to just:

allow = !all, ulaw, alaw

Which already makes disallow somewhat superfluous.

In PJSIP this has been kept the same way.  However, the addition of PJSIP
is already a significant change and gives us the opportunity to make a few
improvements -- if and where it makes sense to do so.  It is also entirely
possible to make similar changes to other channel drivers, which can be
addressed in the future, but today I'm talking just about PJSIP.

The idea of using codecs is that it "reads" better -- tells you what you're
allowing or disallowing:

codecs = !all, ulaw, alaw

It's certainly a break with existing convention, however, it makes sense in
a way.  And we're not talking yet about removing support for allow &
disallow, simply adding codecs as the "preferred" method.  And if you show
endpoint configuration you would see only codecs = !all, ulaw, alaw.




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:
>> > On Thu, Mar 6, 2014 at 1:22 PM, Scott Griepentrog <
>> sgriepentrog at digium.com>
>> > wrote:
>> >>
>> >> First, a smidgen of background:
>> >>
>> >> The two sorcery options for pjsip.conf "allow" and "disallow" both
>> accept
>> >> a list of codecs and set the same table of codecs in behind the
>> scenes.  The
>> >> difference being of course that the disallow field inverts the meaning.
>> >>
>> >> There is some potential confusion here as to why there is two lists of
>> the
>> >> exact same codecs (see
>> >> https://issues.asterisk.org/jira/browse/ASTERISK-23092).  I have a
>> suggested
>> >> patch (see https://reviewboard.asterisk.org/r/3193/) to make the
>> disallow
>> >> option disappear in a fashion.  You can still use the disallow option
>> in
>> >> pjsip.conf, but when viewing the settings with pjsip show endpoint #
>> only
>> >> the allow list would appear.  This is accomplished by marking the
>> disallow
>> >> field as an alias.
>> >>
>> >> An option to move away from SIP's convention of allow/disallow and have
>> >> PJSIP use codecs=ulaw,etc has been suggested (and is coded in the
>> review).
>> >> The question then is:
>> >>
>> >> 1) Do we want to discontinue or alias both allow & disallow and move to
>> >> codecs?
>> >>
>> >>
>> >> 2) If yes, then which version should that be done in?  12?  13?
>> >
>> >
>> > My vote...Move to codecs and alias allow/disallow in 12,  discontinue
>> > allow/disallow in 13.
>> >
>> >>
>> >> Note that even if codecs is chosen, allow and disallow continue to
>> work so
>> >> no existing pjsip.conf is broken.
>> >>
>> >
>>  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 Wedhorn
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
[image: Digium logo]
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
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/46558059/attachment-0001.html>