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

[Matt Fredrickson]

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