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

Wed Oct 5 04:12:56 CDT 2016

If chan_sip really has to go, then perhaps the place to start would be a
marketing effort?

* Why is PJSIP better?
* What does PJSIP do that chan_sip does not?
* Is there anything in chan_sip that PJSIP does not do, and how do you
solve that?
...

This can then be followed with bribery

* What does PJSIP need to do to make it worth your while switching?
...

I have a "perfectly" working chan_sip environment - Why do I want to spend
6 to 12 months picking up the pieces of a transition - Persuade me and all
of the others in the same boat, certainly don't just pull the rug - That
will simply upset people and cause people to stick with whatever released
version last had a working chan_sip implementation (at least that's what I
would do).

If you want to persuade *me* then do a full SDP rtcp-mux / media bundling
implementation that only works in PJSIP :) Then I'd have to flip.

Perhaps some of the above marketing exists already, hidden in some corner
of a wiki rather than being announced? If so, let's get it out there.

Cheers,
Steve

On Wed, 5 Oct 2016 at 08:21 Leandro Dardini <ldardini at gmail.com> wrote:

> Your analysis of the chan_sip/PJSIP is really great and I agree with you.
> Being a grey haired tech, I can check what drives similar changes in the
> latest 20 years. We moved from Netware networks to TCP/IP, we moved from
> Windows 3.11 to Windows 95, we moved from IE to Chrome... in all these past
> situation, we moved from an old, established, perfectly working environment
> to something new. What drives the change? Usually because in the new system
> you have some cool feature you like, so you have on one side, the effort to
> learn something new, but on the other side you have the new functionalities
> you really need.
>
> For the chan_sip/PJSIP, I think people should continue to use chan_sip if
> they like it, sooner or later they will need some of the features
> introduced by PJSIP and they'll move.
>
> Leandro
>
> 2016-10-05 3:34 GMT+02:00 Bruce Ferrell <bferrell at baywinds.org>:
>
> On 10/04/2016 05:46 PM, James Finstrom 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
> >
>
> Forcing adoption IS one simplistic approach to getting wide adoption.
>
> Were Asterisk a toy, not widely in use, that kind of simple approach might
> make sense.  Asterisk is however NOT a toy.  Asterisk IS in wide use for
> peoples livelihood.  "A little
> bleach" might also read "possible loss of business for others"... And that
> cavalier thought process towards those failures might well benefit from a
> much closer look.
>
> Another method is showing a clear and persuasive benefit. Might it be
> possible that such a benefit isn't actually there, beyond a certain
> "academic" mindset?
>
> Impatience NEVER benefits anyone.
>
>
>
> --
> _____________________________________________________________________
> -- 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
>
>
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161005/65f7d7a7/attachment.html>