<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 2:43 PM, Matt Fredrickson <span dir="ltr"><<a href="mailto:creslin@digium.com" target="_blank">creslin@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been deliberately waiting to weigh in on this discussion -<br>
however, my thoughts are as follows:<br>
<br>
1.) Marking a module as deprecated is *not* the same thing as moving<br>
it out of the code base.  It simply means that there is no maintainer,<br>
and something better exists in the code base to move to.<br>
<br>
2.) Code areas marked as deprecated usually don't have a fixed sunset<br>
point where the code is actually removed, which is what I think Dan<br>
might have been pushing for.<br>
<br>
3.) In order to move forward with any sort of deprecation process, in<br>
my mind we need to ensure that chan_pjsip has considerable, if not<br>
complete, feature parity with chan_sip.<br>
<br>
4.) I also feel like the plan to make chan_pjsip capable of reading<br>
sip.conf and perhaps even the chan_sip realtime tables a necessary<br>
prerequisite for code removal, and perhaps even marking of the module<br>
as deprecated.<br>
<br>
5.) I think talk of pulling chan_sip completely out right now is<br>
premature and probably freaking a lot of people out. :-)<br>
<br>
Matthew Fredrickson<br>
<div class="m_-3151778371408565115HOEnZb"><div class="m_-3151778371408565115h5"><br>
On Tue, Oct 4, 2016 at 7:46 PM, James Finstrom <<a href="mailto:jfinstrom@gmail.com" target="_blank">jfinstrom@gmail.com</a>> wrote:<br>
> So the discussion of deprecating chan_sip came up at the devcon this year<br>
> and it caused a bit of a stir. The end result was the need for broader<br>
> discussion with a wider audience.  So let's discuss.<br>
><br>
> Currently, Asterisk is running dual sip stacks. The argument is that to<br>
> deprecate PJSIP there must be broader adoption. There is currently nothing<br>
> motivating adoption but much 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<br>
> broke but it is the "devil you know". A decade of documentation and a broad<br>
> user base allows people to be pretty forgiving of flaws. Almost any issue<br>
> has some sort of work around or generally accepted idea of I guess we can<br>
> live with it.<br>
><br>
> 2. One Ring to rule them all!!  PJSIP requires up to 6 sections of<br>
> configuration. Once you dig in, this method makes sense. But at a glance,<br>
> you have just multiplied the workload to  6 times that of chan_sip's single<br>
> blob config. Though it is not really 600% more effort it may be enough to<br>
> 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<br>
> the first place.  Dogfooding only gets you so far.  You can make anything<br>
> working clean in a single environment and single use case. But what happens<br>
> when people start flinging wrenches. Things break. 100 wrenches may break 10<br>
> things. 1000 wrenches may break 100 things.  In the ladder case, you have<br>
> 100 people saying pjsip sucks, and pjsip is crap. As with all things the 900<br>
> assume all is good and move on with their lives telling no one of their<br>
> glory. So you have 10% of the voices running unopposed. You fix the 100<br>
> issues and that is great but those 100 people have gone back to the comfort<br>
> 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<br>
> universe. This is why I think there is a tendency to be gunshy. No one wants<br>
> to be the guy who broke the universe.  But breaking the universe gets us to<br>
> #3 without falling back into #1.   Once The universe breaks and we are in #3<br>
> many of the edges will be found and fixed. Suddenly PJSIP becomes usable in<br>
> most, if not all situations. The issues in #2 will automatically resolve as<br>
> 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<br>
> confident once they do a few they will figure out the bark is bigger than<br>
> the bite.<br>
><br>
> tl;dr to get adoption you have to force it.  There will be blood, but<br>
> nothing that can't be cleaned up with a little bleach and some elbow grease<br>
><br>
> --<br>
> James<br>
><br>
</div></div><span class="m_-3151778371408565115im m_-3151778371408565115HOEnZb">> --<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/mailma<wbr>n/listinfo/asterisk-dev</a><br>
<br>
<br>
<br>
</span><span class="m_-3151778371408565115HOEnZb"><font color="#888888">--<br>
Matthew Fredrickson<br>
Digium, Inc. | Engineering Manager<br>
</font></span><span class="m_-3151778371408565115im m_-3151778371408565115HOEnZb">445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
<br>
</span><div class="m_-3151778371408565115HOEnZb"><div class="m_-3151778371408565115h5">--<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>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Yeah, I apologise to anyone I may have freaked out - but unless you go for the jugular and work your way back to something sensible for everyone; nothing generally happens (that's nothing about the Asterisk community, thats about any community in general). The end result (however many years down the line) should be to remove chan_sip but thats not going to happen any time soon - And I knew it wasn't going to happen any time soon but you have to start somewhere. If I had raised "i think we need to make migration easier" then would all of the same conversations have happened. I doubt it but I may be wrong about that :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks everyone for the constructive efforts on how to move forward!</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>