On Mon, Oct 6, 2014 at 12:02 PM, Matthew Jordan <[email protected]> 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
-- _____________________________________________________________________ -- 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
