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

Wed Oct 5 10:04:37 CDT 2016

I am in the same situation. All my systems are business-critical and I'm
yet to see a convincing argument to spend a lot of man power to migrate the systems.
Yes, pjsip supposed to be more stable, but chan_sip in asterisk 11 (with a few custom
patches) has been very stable for me. Yes, pjsip may have better performance, but 
I'm using horizontal scalability, so that doesn't affect me much. Yes, pjsip employ 
"sane, maintainable architecture, much easier to develop for" to quote one of the 
developers, but last time I checked (about a year ago) it still lacked feature parity 
with chan_sip. 

I did try to build a test system using pjsip about a year ago and at the time my
conclusion was "it's not ready". It may have changed and I'm planning to look at it again
in the next upgrade cycle, but please don't force it on me.

So I guess I'm joining the crowd saying, please, make it more attractive, provide feature
parity with chan_sip and provide easy migration path. That'll go a long way to get better 
adoption without pissing off and alienating users.

Thanks,
Michael

On Wednesday, October 05, 2016 08:22:21 AM Ryan Wagoner wrote:
> Part of what is holding me back is all my systems are production critical
> for businesses. I need a business case for real world improvements pjsip
> has over chan_sip if I'm going to risk downtime and issues for hundreds of
> users.
> 
> I'm currently running certified Asterisks 11 on all my installs. In the
> past, versions before 1.8, just upgrading minor versions would cause
> headache as things would break or occasionally Asterisk would crash. I
> would have to read the changelogs and either back port a security fix or
> undo a patch that broke something. I will say that with the improvements to
> the test suite this appears to no longer be an issue especially with
> Asterisk 11.
> 
> I still need to go through the 11 to 13 migration where the bridging
> changes cause the CDR records to change. I have to set aside time to bring
> up a test system, make test calls, and rewrite my code that reads the CDR
> table and assigns sales rep call credit. I'm planing to do this middle of
> next year before 11 EOLs.
> 
> I'm looking to migrate to pjsip towards towards the middle of the 13
> lifespan or when 15 releases as I only install certified LTS releases. I
> have patches for chan_sip to integrate with Exchange 2010/2013 including
> MWI support and patches for device feature key synchronization for DND and
> CW. I haven't tested pjsip, but I know the later isn't supported. Exchange
> is mission critical so if there are issues and I can't figure out how to
> write my own patches to solve it, I can't migrate to pjsip.
> 
> I think it would be reasonable to say that Asterisk 15 LTS is the last
> release for chan_sip. This gives everyone 6 years to migrate. In this time
> frame I have no doubt that the feature set and stability of pjsip will
> improve.
> 
> Ryan
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Oct 5, 2016 at 7:29 AM, Eric Klein <eric.klein at greenfieldtech.net>
> wrote:
> 
> > James,
> >
> > You missed a few points:
> > 1. There needs to be a move in the training materials, and DCAP exam away
> > from (the soon to be depriciated) version 11 and move into versions that
> > support PJSip - familiarity will breed use.
> >
> > 2. One suggestion to do this was to declare that Chan_Sip would be
> > depreciated in version 15 or 16. This would not mean removing it from the
> > code, but that going forward (for 1 or 2 more releases) it would only get
> > security fixes and no more development. This would have the benefit
> > of  everyone would have 3-5 years to learn and transition to PJSip without
> > breaking anything that is currently working,  while releasing development
> > staff to improving the interface and problems with PJSip and other parts of
> > Asterisk.
> >
> > Eric Klein
> > VP of Customer Experience
> > GreenfieldTech
> > Mobile +972-54-666-0933
> > Email Eric.Klein at greenfieldtech.net
> > Skype: EricLKlein
> > Web: http://www.greenfieldtech.net/
> >
> >
> >
> >> Message: 5
> >> Date: Tue, 4 Oct 2016 17:46:52 -0700
> >> From: James Finstrom <jfinstrom at gmail.com>
> >> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> >> Subject: [asterisk-dev] Viva Chan_Sip, may it rest in peace
> >> Message-ID:
> >>         <CAE3BMY2OBso2iF6xOR4wreGeSH-TsFh5=FV8NdZQxr_8F2Rb4A at mail.gm
> >> ail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >>
> >> 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
> >> -------------- next part --------------
> >> An HTML attachment was scrubbed...
> >> URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/
> >> 20161004/71b91854/attachment-0001.html>
> >>
> >
> > --
> > _____________________________________________________________________
> > -- 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/202132c3/attachment-0001.html>