Hey everyone! Last week was AstriDevCon, and we had a great turn out with nearly 50 developers from all over the world. We had a lot of great discussion about a variety of topics, the notes of which are up on the Asterisk wiki:
https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014 Keep in mind that these notes were hastily taken during quite a lot of dynamic discussion. At the end of the conversation, the folks at AstriDevCon laid out a couple of broad objectives for the project for the coming year: 1. Improve our infrastructure and move the project to Git. In addition, we should take the opportunity to clarify and improve our contribution process. 2. Improve the documentation of the project, such that it is easier to install, deploy, and configure Asterisk. A number of suggestions were made on this topic, including performing and documenting some case studies on different deployments, providing configuration make targets for different scenarios, and generally improving the documentation in Asterisk and on the wiki. 3. Continue to improve the APIs in Asterisk, with a focus on enabling Asterisk as a media application server. In particular, what capabilities ARI should have should be further explored, focussing on allowing an application developer to configure and control the 'core' capabilities in Asterisk. Several general improvements to ARI were also discussed. Keep in mind that these are just just general objectives - while specific features were discussed, it's hard to know exactly what will be done when and by whom. As an open source project, any feature or improvement to Asterisk is always welcome - and I expect that developers both at Digium and in the community will have many other projects that they pursue over the next year. At the same time, these guidelines will hopefully focus everyone in the project on the some general goals. In addition, there are a number of Action items that are highlighted in the notes. The following is a synopsis of each of these action items: 1. Draft a policy for allowing improvements in release branches. The Asterisk project today does not exist in the same world - and is not the same project - as when the "no new feature in release branches" policy was first employed. We have a rigorous peer review process, multiple test suites, continuous integration infrastructure, and more to help prevent regressions or other problems from occurring. In addition, the world today is also moving faster, and we'd like to make sure that Asterisk maintains pace with changes in the industry. At the same time, we have to ensure that release branches are stable and that a user can upgrade within a release branch and not worry about behavioural changes. We feel we can strike that balance with the right policy. 2. Finish an evaluation of Git and related infrastructure pieces and move the project to Git. Paul Belanger has done a great job setting up a temporary project for the Asterisk Test Suite [1] that uses Gerrit and Jenkins for code review/continuous integration/management. I'd encourage everyone to go take a look at it, ask questions, and evaluate it as a platform for the Asterisk project. (Keep in mind that it's a starting point, not a finished product!) [1]http://lists.digium.com/pipermail/asterisk-dev/2014-October/070938.html 3. Evaluate pulling the tests out of the Asterisk Test Suite into a separate repository and versioning the tests and the Test Suite. We've reached a point where people are using the Asterisk Test Suite's libraries to run their own tests, and where versioning the libraries in the Test Suite will help provide some stability to people's infrastructure. Versioning tests would help when a test's behaviour is different between different versions of Asterisk. Both can be done in conjunction with moving the project to Git. 4. Explore capabilities in AMI/AGI that may be candidates for ARI. Today, ARI has a fundamentally different objective than AMI/AGI: allow a person to build a custom communications application (in the same vein as a dialplan application) using the language of their choice. At the same time, it is conceivable that someone would want to use ARI for more than just that - for example, the asterisk resource in ARI fits outside the realm of a custom communications application. Likewise, actions such as pushing configuration to an Asterisk server is useful for a communications application, but is not necessarily tied to application. This action is to explore what capabilities ARI should have, focussing on controlling and manipulating the "core" of Asterisk. Paul Belanger had a good suggestion for this evaluation - drop the dialplan applications/functions and look at what is currently provided, as well as what could be provided. 5. Document the ARI features that were discussed over the past year and propose a design for them. Three features in particular were discussed but not implemented: playback of media from a remote URI, TTS, and ASR. There are some technical challenges with all three of these, but nothing that is really intractable. Since a number of developers (including myself) have looked at these problems, an approach for each should be documented on the wiki and discussed on the mailing list so that other community developers can help with the implementation and testing. 6. Look at ways Asterisk can scale today, document how that's accomplished, and document what some of the limitations are. In particular, Daniel-Constantin Mierla noted some issues with Kamailio integrations, where Asterisk device state interferes with deployments where devices register to a Kamailio instance as opposed to Asterisk. A -dev list post was proposed to flesh out this problem some more. Additionally, we all agreed that we need to document other challenges with scaling Asterisk. 7. Document PJSIP better! In particular, there is still a lot of confusion about how to configure the PJSIP stack for non-trivial use cases. 8. Simplify routing and dialling of SIP URIs Ben Klang noted that there are some circumstances where this is still challenging. A -dev list post was proposed to further explore this problem. That's a lot of things to talk about! Later this week, I'll have a more formal place put up on the wiki for the results of these discussions. In the meantime, if you had a particular action item assigned to you (which is noted on the wiki), feel free to create a new thread and start the discussion for the particular item. If you didn't have an action assigned to you, don't worry! Please participate in the discussions and - since a lot of these involve further exploration - feel free to look into some of these and share your results. In particular, please do go take a look at Paul's set up of Gerrit/Jenkins, as some thoughts on that would be hugely appreciated. Thoughts on deployment scenarios and scaling would also be greatly appreciated. And again, thanks to everyone who made the trek out to Las Vegas for AstriDevCon. I know that was a long trip for a number of you, and it was hugely appreciated. Thanks - Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 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