On Wed, Oct 12, 2016 at 2:43 PM, Matt Fredrickson <cres...@digium.com> wrote:
> I've been deliberately waiting to weigh in on this discussion - > however, my thoughts are as follows: > > 1.) Marking a module as deprecated is *not* the same thing as moving > it out of the code base. It simply means that there is no maintainer, > and something better exists in the code base to move to. > > 2.) Code areas marked as deprecated usually don't have a fixed sunset > point where the code is actually removed, which is what I think Dan > might have been pushing for. > > 3.) In order to move forward with any sort of deprecation process, in > my mind we need to ensure that chan_pjsip has considerable, if not > complete, feature parity with chan_sip. > > 4.) I also feel like the plan to make chan_pjsip capable of reading > sip.conf and perhaps even the chan_sip realtime tables a necessary > prerequisite for code removal, and perhaps even marking of the module > as deprecated. > > 5.) I think talk of pulling chan_sip completely out right now is > premature and probably freaking a lot of people out. :-) > > Matthew Fredrickson > > On Tue, Oct 4, 2016 at 7:46 PM, James Finstrom <jfinst...@gmail.com> > wrote: > > So the discussion of deprecating chan_sip came up at the devcon this year > > and it caused a bit of a stir. The end result was the need for broader > > discussion with a wider audience. So let's discuss. > > > > Currently, Asterisk is running dual sip stacks. The argument is that to > > deprecate PJSIP there must be broader adoption. There is currently > nothing > > motivating adoption but much slowing it. > > > > What are some of the hurdles to adoption? > > 1. Apathy. If it ain't broke don't fix it. Many would argue chan_sip is > > broke but it is the "devil you know". A decade of documentation and a > broad > > user base allows people to be pretty forgiving of flaws. Almost any issue > > has some sort of work around or generally accepted idea of I guess we can > > live with it. > > > > 2. One Ring to rule them all!! PJSIP requires up to 6 sections of > > configuration. Once you dig in, this method makes sense. But at a glance, > > you have just multiplied the workload to 6 times that of chan_sip's > single > > blob config. Though it is not really 600% more effort it may be enough to > > scare some away > > > > 3. Mo Adoption, Mo problems! > > The only way to clean up all the edge cases and weird bugs is to hit > them in > > the first place. Dogfooding only gets you so far. You can make anything > > working clean in a single environment and single use case. But what > happens > > when people start flinging wrenches. Things break. 100 wrenches may > break 10 > > things. 1000 wrenches may break 100 things. In the ladder case, you have > > 100 people saying pjsip sucks, and pjsip is crap. As with all things the > 900 > > assume all is good and move on with their lives telling no one of their > > glory. So you have 10% of the voices running unopposed. You fix the 100 > > issues and that is great but those 100 people have gone back to the > comfort > > of chan_sip and are stuck at point 1. > > > > Escaping the cycle. > > > > So how do we dredge through this mess and get high adoption? > > > > You have to make #1 not an option. This means potentially breaking the > > universe. This is why I think there is a tendency to be gunshy. No one > wants > > to be the guy who broke the universe. But breaking the universe gets us > to > > #3 without falling back into #1. Once The universe breaks and we are > in #3 > > many of the edges will be found and fixed. Suddenly PJSIP becomes usable > in > > most, if not all situations. The issues in #2 will automatically resolve > as > > there is more information and it becomes the "accepted way" of doing > things. > > The old dogs will have to refactor how they do configuration but I am > > confident once they do a few they will figure out the bark is bigger than > > the bite. > > > > tl;dr to get adoption you have to force it. There will be blood, but > > nothing that can't be cleaned up with a little bleach and some elbow > grease > > > > -- > > James > > > > -- > > _____________________________________________________________________ > > -- 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 > > > > -- > Matthew Fredrickson > Digium, Inc. | Engineering Manager > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > -- > _____________________________________________________________________ > -- 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 > Yeah, I apologise to anyone I may have freaked out - but unless you go for the jugular and work your way back to something sensible for everyone; nothing generally happens (that's nothing about the Asterisk community, thats about any community in general). The end result (however many years down the line) should be to remove chan_sip but thats not going to happen any time soon - And I knew it wasn't going to happen any time soon but you have to start somewhere. If I had raised "i think we need to make migration easier" then would all of the same conversations have happened. I doubt it but I may be wrong about that :) Thanks everyone for the constructive efforts on how to move forward!
-- _____________________________________________________________________ -- 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