[asterisk-dev] Opinions needed: Should PJSIP support enhancements still be allowed in 12->13?

[Matthew Jordan]

On Wed, Oct 1, 2014 at 12:29 PM, Eric Wieling <EWieling at nyigc.com> wrote:
>>From: asterisk-dev-bounces at lists.digium.com
>> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of George Joseph
>>Sent: Wednesday, October 01, 2014 1:16 PM
>>To: asterisk-dev at lists.digium.com
>>Subject: [asterisk-dev] Opinions needed: Should PJSIP support enhancements
>> still be allowed in 12->13?
>
>>
>
>>Even though I've been using pjsip on my dev and test machines for a year,
>> it's only in the last few weeks I've tried to implement pjsip in a prod
>> environment and that's brought up some >issues.   Unfortunately now that
>> we're close to a 13 release there's some trepidation about addressing these
>> issues in 12->13 as opposed to just trunk...
>

Two thoughts here.

1) Generally, I think the standard/LTS release cycle works pretty
well. We got a lot of good feedback during the past 10 months from
Asterisk 12, and I think we've seen some good adoption. Certainly
we've gotten plenty of good bug reports against the PJSIP stack, and
that generally tends to imply that people are using it. From the
perspective of the intended purpose of "standard" and "LTS" releases,
this is meeting what we hoped would happen.

2) On the other hand, we did a lot of work in 12, and I think we might
have done too good a job warning people. Thinking back to Asterisk 10,
it does feel like fewer people have made the leap to 12 than the
number of people who leaped to 10. I don't think this is a problem
with upgrading or lack of information - if anything, we have a lot
better documentation now than we did then (and yes, it could still be
improved upon, no arguments there) - but we did warn people about the
upgrade path. Plus, you can upgrade to 12 and _not_ use the new PJSIP
stack, which means we might have had a good chunk of people upgrade
and just not try it out yet.

So there's some conflict here: on the one hand, we've seen progress;
on the other, we're bound to still get some serious issues with people
who are attempting to deploy something in their production
environment. If we don't fix those kinds of issues, then people will
have to wait another two years for the next LTS.

>
>>res_phoneprov:  Today's phoneprov infrastructure is strictly chan_sip using
>> users.conf and sip.conf for all user related configuration.  There's no
>> pjsip support there at all.   I have 2 patches posted >to RB ([1], [2])
>> that make res_phoneprov pluggable and provide a pjsip provider for
>> phoneprov.    All existing functionality remains unchanged.   You just get
>> the same capabilities for pjsip that >you had for sip.
>

I don't think there's any question that the patches you've put
together are the right approach. It's definitely very, very good work.

>
>>manager/config:  From a remote configuration management perspective The AMI
>> commands GetConfig, GetConfigJSON and UpdateConfig allow you to manipulate
>> Asterisk config files, BUT >they don't work well on configurations that can
>> have multiple sections with the same name.  This was rarely a problem before
>> pjsip but now you can have an endpoint, an aor, an auth, an identify >and an
>> registration all named 'myitsp'.   This makes it impossible to manipulate
>> them  via AMI.   I have a patch to enhance manager.config with that
>> capability as well as the cabability to >manipulate config templates via
>> AMI.   [3]
>

Again, this is a good find and a good improvement to make an existing
command work with the new configuration schemas.

>
>>Finally,  While thinking of alternatives for the config file dilemma, Josh,
>> Brad and I tossed around the idea of a 'super' pjsip object or objects that
>> could represent a 'trunk' or a 'user' thereby >eliminating having to specify
>> separate endpoint, aor, auth, identify and registration objects for common
>> scenarios. [4]   I just started writing code for this today.
>

This one still feels like an open debate to me (sorry!) :-)

I'll defer that conversation to the thread you have going on it.

>
>>So now the big question is...   Can these items go into 12/13 or should
>> they go only in ttrunk/14.   I do need these patches but I can always apply
>> them to my own distro.  My opinion though is >that they should go into 12/13
>> to help speed the adoption of pjsip.  No one who uses phoneprov or AMI to
>> manipulate config files will able migrate otherwise.  Having said that, I
>> realize that 13 >GA is almost upon us and having defined cutoffs is a very
>> good thing.
>
>>
>
>>Thought's? Opinions?
>
>
>
> If PJSIP in Asterisk 13 is *supposed* to have feature parity with chan_sip,
> then I’d call the above items bugs rather than enhancements.
>

I don't think the PJSIP stack in Asterisk 13 (or in any version of
Asterisk, for that matter) *has* to have feature parity with chan_sip.
I think that's a bit of a tall order: for one thing, there are a
number of "features" in chan_sip that should probably never have
existed (autocreatepeer, users.conf, etc.). I think having a blanket
statement that the two must have equivalent feature parity is a
difficult policy to have - it's a never ending feature creep for
everyone involved, and a convenient excuse to shoe-horn in changes
that probably shouldn't be made.

That doesn't preclude having this patch go into any version of
Asterisk - or any patch for that matter - I just don't like using that
rationale to justify a patch.

>
> I strongly support the policy of “no new features” after a branch has been
> released, but sometimes the changes are so important they should be made
> anyway.  AELSub is a great example of the latter.
>

So that is some rambling thoughts. Where are we at?

Clearly, there are some existing commands and infrastructure pieces
that don't support the new PJSIP stack. For people to make use of
their existing Asterisk setups, there would ideally be a way for them
to support PJSIP.

At the same time, we have also reached a point where we need to be
very mindful of changes. Long Term Support releases should not receive
the same kinds of additions as Standard releases: we should err on the
side of caution and stability.

I think we need to find a way to balance stability and functionality.
This ideally would be something to hash out in two weeks at
AstriDevCon, as we usually spend a good chunk of time working through
project policies there. George's patches would ideally be available in
13.0.0 (if everyone were okay with them going into that branch), so
waiting until AstriDevCon to get a final say-so on the patches would
not be a good idea.

Therefore, what I'm proposing is the following:

* For each change set listed above, I think we cannot have them merged
into a branch of Asterisk without accompanying automated tests. In the
case of both changes, nominal tests should be possible using the
Asterisk Test Suite. If you need a hand with writing some of those
tests, I'd be glad to help out with them. We can identify what those
tests should be on this thread and work through that if you'd like.
* At AstriDevCon, I think we need to consider laying out a proposal
for a policy for changes in branches. I hesitate to do this here and
now, as AstriDevCon is a great place to get a general consensus
suitable for submitting to everyone on the mailing list. As a seed for
thought, I'd state that the world we live in now and the state of the
Asterisk project as it is today is not the same as when the zero
tolerance "no new features in release branches" policy was first
enacted. That is not a criticism of the policy, just a reflection that
we have a lot of tests, continuous integration infrastructure, and
other constraints that were not present at that time. But that's a
rant best served in Las Vegas.

Thoughts?

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