On Wed, Oct 12, 2016 at 2:43 PM, Matt Fredrickson <cres...@digium.com>
> 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>
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> > to be the guy who broke the universe. But breaking the universe gets us
> > #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
> > most, if not all situations. The issues in #2 will automatically resolve
> > there is more information and it becomes the "accepted way" of doing
> > 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
> > --
> > 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:
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: