On Wed, Oct 5, 2016 at 4:04 PM, Michael Ulitskiy <[email protected]> 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 < > [email protected]> > > > 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 [email protected] > > > > Skype: EricLKlein > > > > Web: http://www.greenfieldtech.net/ > > > > > > > > > > > > > > > >> Message: 5 > > > >> Date: Tue, 4 Oct 2016 17:46:52 -0700 > > > >> From: James Finstrom <[email protected]> > > > >> To: Asterisk Developers Mailing List <[email protected]> > > > >> Subject: [asterisk-dev] Viva Chan_Sip, may it rest in peace > > > >> Message-ID: > > > >> <[email protected] > > > >> 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
-- _____________________________________________________________________ -- 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
