On Fri, Oct 7, 2016 at 10:31 AM, Corey Farrell <g...@cfware.com> wrote: > Many people don't like chan_sip, most people hate working with the code. > The rush to throw out chan_sip when PJSIP isn't ready to be the only SIP > stack annoys me a bit. Nobody is forcing anyone to use or contribute to > chan_sip. Digium changed chan_sip from core to extended support so they can > significantly reduce involvement. At some point chan_sip will fizzle out > but that hasn't happened yet.
I don't think we're rushing - if anything, most people at DevCon (and I'd also say in this conversation) are being pretty realistic about how long it will take before chan_sip could be removed from the source tree. I think all we're seeing right now is a conversation about how we might eventually get there. Generally, when a module is first marked as being 'deprecated', we usually let it go through at least one additional release before it would ever be removed. Even then, our preference is to just leave the module in the source tree (usually disabled), in case someone still wants to use it. About the only time we remove a module is when it either no longer compiles, or when it is actively causing harm. Assuming we all decided to mark chan_sip as deprecated in Asterisk 15, then soonest it would be removed from the source tree is Asterisk 17 - so I think we've got some time to hash this out. As far as extended support is concerned - yes, Digium is not interested in maintaining chan_sip any longer. Our commercial products and interests are focused on the PJSIP stack. As such, once Asterisk 11 leaves bug fix support, I would expect our fixing of chan_sip related issues to drop dramatically - even more than they already have. Patches submitted for chan_sip through Gerrit will still be reviewed and receive attention, as will security patches. > Last time I checked about 200 of the PJSIP testsuite tests produced AO2 > leaks, in many cases hundreds of objects were leaked [1]. Some of these > leaks may be caused by bugs in tests and I realize that many use cases must > work without major leaking, but some use cases could cause failures. I've > submitted some fixes but I find PJSIP leak tracing more difficult than other > parts of Asterisk. I'll admit that some of the tracing is a bit more challenging, both with sorcery as well as with PJSIP memory pools. My impression right now is that any objects that are not released on shutdown are configuration objects or other similar objects that allocated a single time during some PJSIP module initialization. While those make AO2 debugging challenging (and it would be great to clean them up), they don't indicate any harmful memory leak. Of course, I do understand if that means you don't want to use those modules. > The current policy of allowing new features into released LTS branches is a > concern for me with PJSIP. If I were to start using PJSIP I would have to > worry about each 13.x.0 release having a new PJSIP feature possibly cause a > bug. A lot of bad things can be said about chan_sip, but new features are > extremely unlikely in 13.12.0. It would be nice if a core set of PJSIP and > other modules could be declared LTS frozen. During LTS releases these > modules would be strictly bug fix only. I suspect this is not yet wanted or > possible for PJSIP modules, but hope it can be re-evaluated before new LTS > branches. My hope is that eventually a basic PJSIP PBX could be run using > only frozen modules. Users with a specific needs or higher risk tolerance > could run some / all of the unfrozen modules to get more advanced or less > mature features. Eventually the list of frozen modules could grow as each > module becomes feature complete and is proven stable. I don't think I want to complicate the new feature development process. While I think we've had a few hiccups, by and large, I haven't heard of a lot of complaints with the new features/improvements that are being released mid-stream. The only ones that have bitten me are where we combined modules or introduced a new needed module (res_pjproject), and that's because I explicitly load modules that I use. Are there specific issues you're thinking of? > I do see chan_pjsip in my future. It has all the features I need plus the > config handling will improve my handling of dynamic peers. I have no > timeframe to migrate as I can't ignore my concerns and they can't be > addressed overnight. > > [1] > https://jenkins.asterisk.org/jenkins/job/periodic-ref_debug-asterisk-13/8/ > > On Tue, Oct 4, 2016 at 8:46 PM, James Finstrom <jfinst...@gmail.com> 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 >> >> -- >> _____________________________________________________________________ >> -- 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 -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- 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
