[asterisk-dev] AstriDevCon Summary

[Matthew Jordan]

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