Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace
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
[asterisk-dev] Viva Chan_Sip, may it rest in peace
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
[asterisk-dev] Proposed alembic changes
Several folks have requested the ability to use the same schema for their cdr, config and voicemail tables. Alembic currently has an issue with this because the default name of the table alembic uses to track which revision the database is at is named 'alembic_version' with no qualifying information in it. The result is that if you attempt to use the same schema for 2 trees, alembic will complain that the revisions are out of sync. To address this, I've put a patch[1] up on gerrit that renames the 'alembic_version' table to 'alembic_version_' the next time you run alembic for a tree. For cdr for instance, the new table would be named 'alembic_version_cdr'. It would only be renamed it it contained a revision that matches the tree your're working with. Let's say you have an existing config tree in the 'asterisk' schema and wanted to add the cdr table to it. Assuming your cdr.ini file points to the 'asterisk' schema, when you run 'alembic -c cdr.ini upgrade head', the existing 'asterisk_version' table would be checked to see if it belongs to cdr. Since it belongs to config not cdr, the existing table is left alone and a new 'alembic_version_cdr' table is created and the upgrade is performed to create the cdr table. The next time you run alembic on the config tree, the 'alembic_version' table is checked again and since it does belong to config, it's renamed to 'alembic_version_config'. No existing data tables are renamed or altered and their data isn't touched unless of course that was the point of the alembic script in the first place. So why this email? We just wanted to make sure that nobody has an issue with renaming that table. Hopefully nobody is actually using that table for anything but even if you're not, we don't want you to be surprised if you notice the change. Speak up now if you have an issue with this. [1] https://gerrit.asterisk.org/4018 -- George Joseph Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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
[asterisk-dev] Working Groups
Hey all, Welcome back to all of you who attended AstriDevCon. Thanks so much for all of you that attended and gave so much of your time to be able to contribute. One of the ideas proposed in AstriDevCon was to create the notion of working groups within the Asterisk project, similarly to the way that the node.js project operates. I think this would be separate from the notion of maintainers of modules or subsystems in Asterisk, which we already have, and be more targeted towards areas that are non code related or areas of new code contribution. I'm assuming that this would mean each working group has a directive or mission of some sort, a list of members, and someone responsible for the output of the group itself (someone to hang, in a manner of speaking :-) ). Presumably we initially would need to identify some key areas of coverage. Since the discussion began at Astricon, I'd love to see some continuation here on the list and welcome any additional thoughts/interest/disinterest. Thanks. -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA -- _ -- 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
Re: [asterisk-dev] [asterisk-commits] format ogg opus: New format (asterisk[master])
On Tue, Oct 4, 2016 at 4:41 PM, ApexVitality wrote: > unsubscribe me from this list or any other list pls > Instructions are at the bottom of every e-mail: > 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
Re: [asterisk-dev] [asterisk-commits] format ogg opus: New format (asterisk[master])
unsubscribe me from this list or any other list pls -- _ -- 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
