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

[George Joseph]

On Mon, Oct 6, 2014 at 12:02 PM, Matthew Jordan <mjordan at digium.com> wrote:

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


> 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?
>
> Thanks Matt!   I do have unit tests for the config.c changes but the rest
do need TestSuite tests as well.  I actually started looking at these this
weekend.   The test for the AMI changes I can easily clone from existing
AMI tests.    The phoneprov test is even easier since it just has to look
at the output of a text file.  I should have those done this week.

The phoneprov and manager/config change sets both have "ship It"s but I'll
hold off committing them until the tests are ready.

george
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141006/3820934e/attachment-0001.html>