[asterisk-dev] Viva Chan_Sip, may it rest in peace

[Dan Jenkins]

On Wed, Oct 12, 2016 at 2:43 PM, Matt Fredrickson <creslin at 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 <jfinstrom at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161012/97e5f3a3/attachment.html>