On Wed, Oct 1, 2014 at 12:29 PM, Eric Wieling <[email protected]> wrote: >>From: [email protected] >> [mailto:[email protected]] On Behalf Of George Joseph >>Sent: Wednesday, October 01, 2014 1:16 PM >>To: [email protected] >>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 -- _____________________________________________________________________ -- 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
