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 <ldard...@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 <bferr...@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
-- _____________________________________________________________________ -- 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