<div dir="ltr">If chan_sip really has to go, then perhaps the place to start would be a marketing effort?<div><br></div><div>* Why is PJSIP better?</div><div>* What does PJSIP do that chan_sip does not?</div><div>* Is there anything in chan_sip that PJSIP does not do, and how do you solve that?</div><div>...</div><div><br></div><div>This can then be followed with bribery</div><div><br></div><div>* What does PJSIP need to do to make it worth your while switching?</div><div>...</div><div><br></div><div>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).</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Steve</div><br><div class="gmail_quote"><div dir="ltr">On Wed, 5 Oct 2016 at 08:21 Leandro Dardini <<a href="mailto:ldardini@gmail.com">ldardini@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">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.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Leandro</div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">2016-10-05 3:34 GMT+02:00 Bruce Ferrell <span dir="ltr" class="gmail_msg"><<a href="mailto:bferrell@baywinds.org" class="gmail_msg" target="_blank">bferrell@baywinds.org</a>></span>:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_3076356740085121509HOEnZb gmail_msg"><div class="m_3076356740085121509h5 gmail_msg">On 10/04/2016 05:46 PM, James Finstrom wrote:<br class="gmail_msg">
> 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<br class="gmail_msg">
> audience.  So let's discuss.<br class="gmail_msg">
><br class="gmail_msg">
> 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<br class="gmail_msg">
> slowing it.<br class="gmail_msg">
><br class="gmail_msg">
> What are some of the hurdles to adoption?<br class="gmail_msg">
> 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<br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> 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<br class="gmail_msg">
> 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<br class="gmail_msg">
><br class="gmail_msg">
> 3. Mo Adoption, Mo problems!<br class="gmail_msg">
> 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<br class="gmail_msg">
> 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<br class="gmail_msg">
> 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.<br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> Escaping the cycle.<br class="gmail_msg">
><br class="gmail_msg">
> So how do we dredge through this mess and get high adoption?<br class="gmail_msg">
><br class="gmail_msg">
> 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<br class="gmail_msg">
> 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<br class="gmail_msg">
> 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.<br class="gmail_msg">
> 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.<br class="gmail_msg">
><br class="gmail_msg">
> 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<br class="gmail_msg">
><br class="gmail_msg">
> --<br class="gmail_msg">
> James<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</div></div>Forcing adoption IS one simplistic approach to getting wide adoption.<br class="gmail_msg">
<br class="gmail_msg">
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<br class="gmail_msg">
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.<br class="gmail_msg">
<br class="gmail_msg">
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?<br class="gmail_msg">
<br class="gmail_msg">
Impatience NEVER benefits anyone.<br class="gmail_msg">
<span class="m_3076356740085121509HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
_____________________________________________________________________<br class="gmail_msg">
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" class="gmail_msg" target="_blank">http://www.api-digital.com</a> --<br class="gmail_msg">
<br class="gmail_msg">
asterisk-dev mailing list<br class="gmail_msg">
To UNSUBSCRIBE or update options visit:<br class="gmail_msg">
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br class="gmail_msg">
</font></span></blockquote></div><br class="gmail_msg"></div>
--<br class="gmail_msg">
_____________________________________________________________________<br class="gmail_msg">
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" class="gmail_msg" target="_blank">http://www.api-digital.com</a> --<br class="gmail_msg">
<br class="gmail_msg">
asterisk-dev mailing list<br class="gmail_msg">
To UNSUBSCRIBE or update options visit:<br class="gmail_msg">
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div></div>