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

Wed Oct 5 11:23:27 CDT 2016

On Wed, Oct 5, 2016 at 4:04 PM, Michael Ulitskiy <mulitskiy at acedsl.com>
wrote:

> 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
>
> > >
>
> --
> _____________________________________________________________________
> -- 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
>

Michael,

What would be amazing is for you to tell us which features you are missing
(or were missing when you tried)

If we start a working group around PJSIP migration then these points will
help drive that forward.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161005/140c5408/attachment-0001.html>