<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 5, 2016 at 8:21 AM, Leandro Dardini <span dir="ltr"><<a href="mailto:ldardini@gmail.com" target="_blank">ldardini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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><br></div><div>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><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Leandro</div></font></span></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-10-05 3:34 GMT+02:00 Bruce Ferrell <span dir="ltr"><<a href="mailto:bferrell@baywinds.org" target="_blank">bferrell@baywinds.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_8277619395390080505HOEnZb"><div class="gmail-m_8277619395390080505h5">On 10/04/2016 05:46 PM, James Finstrom wrote:<br>
> 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>
> audience.  So let's discuss.<br>
><br>
> 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>
> slowing it.<br>
><br>
> What are some of the hurdles to adoption?<br>
> 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>
> 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>
><br>
> 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>
> 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>
><br>
> 3. Mo Adoption, Mo problems!<br>
> 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>
> 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>
> 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>
> 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>
><br>
> Escaping the cycle.<br>
><br>
> So how do we dredge through this mess and get high adoption?<br>
><br>
> 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>
> 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>
> 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>
> 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>
><br>
> 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>
><br>
> --<br>
> James<br>
><br>
<br>
</div></div>Forcing adoption IS one simplistic approach to getting wide adoption.<br>
<br>
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>
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>
<br>
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>
<br>
Impatience NEVER benefits anyone.<br>
<span class="gmail-m_8277619395390080505HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailm<wbr>an/listinfo/asterisk-dev</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So I was the one who brought it up at devcon but I know many agree. Jame's initial layout is 100% correct but doesn't go into the thoughts behind why it was suggested, potential solutions and potential timeframes.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Now I must re-iterate here; neither the community or Digium agreed and said "yeah lets scrap chan_sip" (well I did, to get the conversation going) - its not going to be removed any time soon, with deprecation happening long before it being removed. Deprecation won't be happening in 15, which means at the earliest it'll be 16 with it being removed far later/if ever - I doubt deprecation will even happen in 16 but we have to come up with a plan to keep Asterisk moving forward so I'd like to see us settle on one sooner rather than later.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Why did I suggest it? Is it because I hate developing chan_sip? No, I don't write C code although I may start learning soon. Is it because I love pjsip? No, its different and I'm still learning about all the things it can do and how to configure them - the fact that some documentation isn't correct on the wiki isnt great here (you don't <i>need </i>to assign a transport against an endpoint - especially if you want to be able to accept over multiple transports etc - but a lot of the documentation says you should put in a transport!)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway, I got side tracked. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Why did I suggest removing chan_sip (which got scaled back to deprecating)? Purely because the Asterisk project decided many moons ago that the sip stack in Asterisk wasn't fit for purpose any more. This was decided years ago now. It wasn't decided just to make more work for the core team; it was decided because continuing to develop monolithic code was taking too much time and there were better solutions out there. Today, we have members of the core team fighting security issues in chan_sip because they have to - to keep Digium (not sure about legals for other contributors) out of trouble with law suits etc - they can't just let something that many people rely on just sit there in the source code without being looked after. So instead of working on awesome new features in Asterisk; they spend their days fixing chan_sip - <i style="font-weight:bold">YAY</i> - as a software dev there is nothing greater than removing code that you never have to touch again - I would much rather the Asterisk core team be writing awesome new stuff than spending their days patching 10 year old code.</div><div class="gmail_extra"><b><i><br></i></b></div><div class="gmail_extra">Another reason I said we should remove it was because we had decided on PJSIP and the whole point of PJSIP was to one day remove chan_sip - that <b><i>was</i></b> the goal (no-one disagreed at devcon)</div><div class="gmail_extra"><br></div><div class="gmail_extra">We also heard that people are worried about having to learn a new SIP stack in terms of code - they have patches for chan_sip, or they know chan_sip and so when they get hired to come in and fix something - they <i>know</i> what they're talking about; but less so with pjproject</div><div class="gmail_extra"><br></div><div class="gmail_extra">So we have to start making a move towards progress. Many issues have been solved with PJSIP (my main personal one being configuring pjproject separately to asterisk and getting the right flags etc - since 13.9 I think we've got a configure flag that does it all for us). If we don't start aiming to deprecate and then remove; it will never happen, chan_sip will remain a liability for Asterisk and eventually it will bite the project in some way. </div><div class="gmail_extra"><br></div><div class="gmail_extra">So onwards to the solution or at least one of them.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We saw one key thing standing in the way of people adopting PJSIP and that was the configuration. So we put forward that we should make PJSIP understand sip.conf - yes you don't get all the new nice stuff in pjproject but thats not the point here - the point is helping people migrate. Over time people will learn the new stuff. We already have the PJSIP wizard which already helps configuring PJSIP but many people still think thats too much to move too as well.</div><div class="gmail_extra"><br></div><div class="gmail_extra">But we're interested in why <i>you</i> haven't moved over to PJSIP yet. If the community as a whole said, yes, we don't want the core teams efforts to be on chan_sip anymore, what can we (the community) do to help progress that? We talked at AstriDevCon about setting up working groups. <a href="http://lists.digium.com/pipermail/asterisk-dev/2016-October/075809.html">http://lists.digium.com/pipermail/asterisk-dev/2016-October/075809.html</a> I'll be putting forward migration to PJSIP as a working group. Its something we need to tackle for the future of the project.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I probably forgot a load of stuff that we discussed at devcon but hope if we make a working group around this we'll be able to come up with a plan that the community can agree on</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dan</div><div class="gmail_extra"><br></div></div>