<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2176/25/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2012">AstriDevCon 2012</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mjordan">Matt Jordan</a>
</h4>
<br/>
<h4>Changes (50)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >* Nicolas Bouliane: Avencall <br>* Mark Murawski: Intellasoft <br></td></tr>
<tr><td class="diff-changed-lines" >* Sylvain Bolly: <span class="diff-added-words"style="background-color: #dfd;">Avencall</span> <br></td></tr>
<tr><td class="diff-unchanged" >* Xavier Carcelle: Avencall <br>* Nir Simionovich: Greenfield Technologies <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > <br>* Release Branches - what is an allowed patch in a release branch. Historically, we've had the policy that no new features should be allowed in release branches - should we revisit that decision? Pros and cons were discussed. The general consensus reached was that this should not be changed. <br></td></tr>
<tr><td class="diff-changed-lines" >** We discovered that this policy was never written down in a clear, concise way. <span class="diff-added-words"style="background-color: #dfd;">*Action to take:</span> We <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">took an action</span> <span class="diff-added-words"style="background-color: #dfd;">need</span> to craft a written policy for no new features in Release Branches and make it available on the Asterisk <span class="diff-changed-words">wiki.<span class="diff-added-chars"style="background-color: #dfd;">*</span></span> <br></td></tr>
<tr><td class="diff-unchanged" >*** We tried to find situations in which it might be possible to have a new feature included in a release branch. The only way it would be reasonable is if it did not, in any way, impact existing code. That would imply that the new feature would have to exist in a stand alone module, and be disabled by default. <br>* Git - should we moved to Git? There are a few reasons why a move to Git would be advantageous for the Asterisk project: <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >* Other Development Tools <br>** Review Board/Code Reviews <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*** Someone asked "what allows a Ship It?" There isn't a <br>**** complexity => testing <br>***** unit testing <br>***** asterisk testsuite tests <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">*** Someone asked "what allows a Ship It?" While there isn't a 'definition' for what constitutes acceptable code, there are some guidelines that reviewers should follow when performing a code review, as well as actions that submitters can take to help code receive a 'Ship It'. *Action to take: document a check-list for reviewers*. Some areas discussed included: <br>**** The higher the complexity, the more likely the need for automated testing or some other verification that the code is well tested. This can include several other items, that may be part of the same review or separate reviews: <br>***** Unit Testing via the Asterisk Unit Test Framework <br>***** Asterisk Test Suite tests <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-added-words"style="background-color: #dfd;">The code</span> needs to satisfy requirements for <span class="diff-changed-words">merging<span class="diff-added-chars"style="background-color: #dfd;">:</span></span> <br></td></tr>
<tr><td class="diff-changed-lines" >***** <span class="diff-added-words"style="background-color: #dfd;">The code must follow the</span> coding guidelines <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">***** documentation <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">***** The code should be well documented, and - if the item is a new feature or alters existing behavior - it should have sufficient documentation. This includes: <br></td></tr>
<tr><td class="diff-changed-lines" >****** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">n</span><span class="diff-added-chars"style="background-color: #dfd;">N</span>ew</span> config options in the sample config <br></td></tr>
<tr><td class="diff-changed-lines" >****** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">d</span><span class="diff-added-chars"style="background-color: #dfd;">D</span>oxygen</span> comments <br></td></tr>
<tr><td class="diff-changed-lines" >****** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">w</span><span class="diff-added-chars"style="background-color: #dfd;">W</span>iki</span> docs for usage <span class="diff-added-words"style="background-color: #dfd;">(if a new feature)</span> <br></td></tr>
<tr><td class="diff-changed-lines" >*** <span class="diff-added-words"style="background-color: #dfd;">In general, submitters should wait</span> 24hr for others to review <span class="diff-added-words"style="background-color: #dfd;">after receiving a 'Ship It'. Not everyone lives in the same time zone!</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">**** Time constrained - at least 2 ship its <br>* feature branches <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">**** If, for whatever reason, the patch has some time constraint and has to be merged sooner than 24 hours later, it should receive at least 2 ship its. This may only cover a hypothetical scenario, and may not need to be part of any written guideline. <br>* Feature branches - may be nice to have a page on the wiki for 'team branches' of features not merged for a particular version. This will let the Asterisk Test Suite be pointed at the branch, make it known that its available, etc. <br></td></tr>
<tr><td class="diff-changed-lines" >* <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">t</span><span class="diff-added-chars"style="background-color: #dfd;">T</span>esting</span> <br></td></tr>
<tr><td class="diff-changed-lines" >** <span class="diff-added-words"style="background-color: #dfd;">We</span> need to publicize <span class="diff-added-words"style="background-color: #dfd;">(better) the</span> tools available for <span class="diff-added-words"style="background-color: #dfd;">use. These tools should be made for</span> use <span class="diff-added-words"style="background-color: #dfd;">by everyone contributing to the Asterisk project.</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">** publicize what is tested <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">** Publicize what is tested - and at what level (unit, integration, system). Some automated mechanism that publishes the tests would be best, as that would prevent the documentation from getting out of sync with the tests. *Action taken: have the Unit Tests and Test Suite tests be documented on the Asterisk wiki* <br></td></tr>
<tr><td class="diff-changed-lines" >** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">w</span><span class="diff-added-chars"style="background-color: #dfd;">W</span>hat</span> is tested by Digium before a major release? <br></td></tr>
<tr><td class="diff-changed-lines" >*** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">a</span><span class="diff-added-chars"style="background-color: #dfd;">A</span>sterisk</span> testsuite <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*** manual tests <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">*** Manual tests (system level) <br></td></tr>
<tr><td class="diff-changed-lines" >*** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">t</span><span class="diff-added-chars"style="background-color: #dfd;">T</span>esting</span> is primarily core support level <br></td></tr>
<tr><td class="diff-changed-lines" >*** <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">minimal</span> <span class="diff-added-words"style="background-color: #dfd;">Minimal (or none)</span> testing of extended support level <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">* data capture <br>** non evil, phone home <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">* What do we feel would be needed at a policy level regarding a "phone home" Data Capture module? <br>** It must be "non evil", phone home <br></td></tr>
<tr><td class="diff-changed-lines" >** <span class="diff-added-words"style="background-color: #dfd;">It should contain</span> no personal info <br></td></tr>
<tr><td class="diff-changed-lines" >** <span class="diff-added-words"style="background-color: #dfd;">It should tag a system by a unique ID, and you should</span> know your own unique ID <br></td></tr>
<tr><td class="diff-changed-lines" >** <span class="diff-added-words"style="background-color: #dfd;">You should be able to</span> query <span class="diff-added-words"style="background-color: #dfd;">all gathered</span> data <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">** OPT OUT - easily turned off <br>** Well publicized <br>*** control where data is sent <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">** It should be OPT OUT - easily turned off. We discussed OPT IN, but everyone agreed that OPT IN systems rarely get the kind of participation needed for them to be worthwhile. <br>** It must be well publicized, in a variety of ways: <br>*** It must publicize where data is sent, and allow the user to control where data is sent. Valid options could be: <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">d</span><span class="diff-added-chars"style="background-color: #dfd;">D</span>igium</span> only <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">**** somewhere else only <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">**** Somewhere else only (that is, if you have multiple systems, you can have it send data only to your own service) <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">d</span><span class="diff-added-chars"style="background-color: #dfd;">D</span>igium+somewhere</span> else <br></td></tr>
<tr><td class="diff-changed-lines" >*** <span class="diff-added-words"style="background-color: #dfd;">You should be able to</span> control what data is <span class="diff-added-words"style="background-color: #dfd;">sent. Valid data that is</span> sent <span class="diff-added-words"style="background-color: #dfd;">could include:</span> <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">m</span><span class="diff-added-chars"style="background-color: #dfd;">M</span>odules</span> being used/versions <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">c</span><span class="diff-added-chars"style="background-color: #dfd;">C</span>alls</span> processed <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">r</span><span class="diff-added-chars"style="background-color: #dfd;">R</span>egistered</span> endpoints <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">technology</span> <span class="diff-added-words"style="background-color: #dfd;">Technologies</span> used <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">**** what data is collected & message spec <br></td></tr>
<tr><td class="diff-changed-lines" >**** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">u</span><span class="diff-added-chars"style="background-color: #dfd;">U</span>ptime</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*** open data transfer message format <br>*** well documented <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">*** Open data transfer message format (the message specification for what data is sent should be publicized) <br>*** Well documented message specification, i.e., should not require reverse engineering the module <br></td></tr>
<tr><td class="diff-changed-lines" >*** <span class="diff-added-words"style="background-color: #dfd;">A</span> separate module <span class="diff-added-words"style="background-color: #dfd;">should control the sending</span> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">*** CLI warning <br>* project pages <br>** asterisk-dev list discussions <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">*** CLI warning should be displayed *as the last message before the prompt* instructing the user that data is being sent, and how to turn it off. <br>* Project pages. All major projects should have a project page on the Asterisk wiki where people can go and learn what active projects are currently being worked on. The project pages are *not* a place for discussion, but rather a focal point for resources related to that project. <br>** This page should link to any major asterisk-dev list discussions. <br></td></tr>
<tr><td class="diff-changed-lines" >** <span class="diff-changed-words"><span class="diff-deleted-chars"style="color:#999;background-color:#fdd;text-decoration:line-through;">a</span><span class="diff-added-chars"style="background-color: #dfd;">A</span>nnounce</span> on mailing list <span class="diff-added-words"style="background-color: #dfd;">when a project is kicked off</span> - provide links to wiki for more detail <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">* mailing list <br>** don't require mailing list discussions to be conducted only through mailman server? <br>** counter-argument: might need tweaks for dups, conversations fall off of the list easier <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">** Page should include requirements, high level design, links to JIRA issues for tasking, links to code reviews, outstanding tasks, etc. <br>* Mailing list policies <br>** We currently require all mailing list discussions to be conducted only through the mailman server, i.e., you can't CC the mailing list. This can make it difficult if a particular mailing list is not one that you interact with on a constant basis. A proposal was made to not require mailing list discussions to be conducted only through mailman server. <br>** Counter-argument: the configuration would most likely need need tweaks for duplicate messages, and allowing conversations to CC a mailing list might mean that conversations fall off of the list easier (or never get put on it in the first place) <br>** *We didn't seem to come to a conclusion on this issue. If anyone feels like this needs more discussion, please start a policy discussion on the asterisk-dev list.* <br></td></tr>
<tr><td class="diff-unchanged" > <br>h2. Channel Drivers <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<div>
<ul>
<li><a href='#AstriDevCon2012-Introduction'>Introduction</a></li>
<li><a href='#AstriDevCon2012-Participants'>Participants</a></li>
<ul>
<li><a href='#AstriDevCon2012-Developers%2FContributorsPresent'>Developers/Contributors Present</a></li>
<li><a href='#AstriDevCon2012-DevelopersParticipatingvia%23astridevcon'>Developers Participating via #astridevcon</a></li>
</ul>
<li><a href='#AstriDevCon2012-Agenda'>Agenda</a></li>
<li><a href='#AstriDevCon2012-Notes'>Notes</a></li>
<ul>
<li><a href='#AstriDevCon2012-Policies'>Policies</a></li>
<li><a href='#AstriDevCon2012-ChannelDrivers'>Channel Drivers</a></li>
<li><a href='#AstriDevCon2012-Core'>Core</a></li>
<li><a href='#AstriDevCon2012-APIs'>APIs</a></li>
<li><a href='#AstriDevCon2012-Review'>Review</a></li>
<ul>
<li><a href='#AstriDevCon2012-AstriDevCon2011ProjectsAST%3AAstriDevCon2011'> AstriDevCon 2011 Projects</a></li>
<li><a href='#AstriDevCon2012-ProjectsDiscussed'>Projects Discussed</a></li>
</ul>
</ul>
<li><a href='#AstriDevCon2012-AgreedUponGoals'>Agreed Upon Goals</a></li>
</ul></div>
<h1><a name="AstriDevCon2012-Introduction"></a>Introduction</h1>
<p>AstriDevCon 2012 was held on Monday, October 22nd. It was held on the day prior to AstriCon at the same location. A group of active development community members met and discussed a number of topics.</p>
<p>Much thanks to Jared Smith and BlueHost for sponsoring the event!</p>
<h1><a name="AstriDevCon2012-Participants"></a>Participants</h1>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Unfortunately, my list of developers present got eaten by the cleaning crew (through no fault of their own, that's what I get for leaving it behind in a stack of scribbled papers!) If I miss your name and/or company on here, let me know and I'll be sure to correct the list below. – Matt</td></tr></table></div>
<h2><a name="AstriDevCon2012-Developers%2FContributorsPresent"></a>Developers/Contributors Present</h2>
<ul>
<li>Rusty Newton: Digium</li>
<li>Matt Jordan: Digium</li>
<li>Paul Belanger: PolyBeacon</li>
<li>Leif Madsen: CoreDial</li>
<li>Jared Smith: BlueHost</li>
<li>Nicolas Bouliane: Avencall</li>
<li>Mark Murawski: Intellasoft</li>
<li>Sylvain Bolly: Avencall</li>
<li>Xavier Carcelle: Avencall</li>
<li>Nir Simionovich: Greenfield Technologies</li>
<li>Eric Klein: Greenfield Technologies</li>
<li>David Faulk: Digium</li>
<li>Max Schroeder: Starface</li>
<li>Octavio Luna:</li>
<li>Alec Davis:</li>
<li>Corey McFadden: Voneto</li>
<li>Joshua Colp: Digium</li>
<li>Shaun Ruffell: Digium</li>
<li>Jason Parker: Digium</li>
<li>Matthew Frederickson: Digium</li>
<li>Malcolm Davenport: Digium</li>
<li>Steve Sokol: Digium</li>
<li>Michael Spiceland: Digium</li>
<li>David Lee: Digium</li>
<li>Kinsey Moore: Digium</li>
<li>Mark Michelson: Digium</li>
<li>Bryan Johns: Digium</li>
<li>Sean McCord: Ulexus</li>
<li>BJ Weschke: BTWTech</li>
<li>Clod Patry: ConnectIT Networks</li>
<li>Tim Panton: Voxeo Labs</li>
<li>James Body: Truphone</li>
</ul>
<h2><a name="AstriDevCon2012-DevelopersParticipatingvia%23astridevcon"></a>Developers Participating via #astridevcon</h2>
<ul>
<li>Tzafrir Cohen: Xorcom</li>
<li>Ben Klang: Mojo Lingo/Adhearsion</li>
<li>Ben Langfeld: Adhearsion</li>
</ul>
<h1><a name="AstriDevCon2012-Agenda"></a>Agenda</h1>
<p>After introductions, an agenda, consisting of topic areas and specific items, was developed and agreed upon. In order to ensure that all topics had some discussion, each of the major topics was limited to an agreed upon amount of time. The following broad areas were discussed:</p>
<ul>
<li>Policies (1 hour)</li>
<li>Channel Drivers (2 hours)</li>
<li>Core (1 hour)</li>
<li>APIs (1 hour)</li>
<li>Review of past work and existing work (1 hour)</li>
</ul>
<h1><a name="AstriDevCon2012-Notes"></a>Notes</h1>
<p>Please remember that these notes merely represent the items that were discussed, and, by themselves, do not constitute policies or project proposals.</p>
<h2><a name="AstriDevCon2012-Policies"></a>Policies</h2>
<ul>
<li>Release Branches - what is an allowed patch in a release branch. Historically, we've had the policy that no new features should be allowed in release branches - should we revisit that decision? Pros and cons were discussed. The general consensus reached was that this should not be changed.
<ul>
<li>We discovered that this policy was never written down in a clear, concise way. <b>Action to take: We need to craft a written policy for no new features in Release Branches and make it available on the Asterisk wiki.</b>
<ul>
<li>We tried to find situations in which it might be possible to have a new feature included in a release branch. The only way it would be reasonable is if it did not, in any way, impact existing code. That would imply that the new feature would have to exist in a stand alone module, and be disabled by default.</li>
</ul>
</li>
</ul>
</li>
<li>Git - should we moved to Git? There are a few reasons why a move to Git would be advantageous for the Asterisk project:
<ol>
<li>Easier merge paths between branches (which will get more complicated with the EOL of Asterisk 10 in December)</li>
<li>Potential process improvements that would allow verified code to be merged quicker into branches/trunk</li>
</ol>
<ul>
<li>Asterisk is a large project to move to Git. It may be better to start with DAHDI (they really already use it extensively, and Subversion is a formality) or the Asterisk Test Suite (smaller project, one branch, fewer users)</li>
<li>One of the complications of moving Asterisk to Git is menuselect. Since no other projects (we think) use menuselect at this time, we should move menuselect into Asterisk (barring any technical barriers that arise)</li>
</ul>
</li>
<li>Other Development Tools
<ul>
<li>Review Board/Code Reviews
<ul>
<li>Someone asked "what allows a Ship It?" While there isn't a 'definition' for what constitutes acceptable code, there are some guidelines that reviewers should follow when performing a code review, as well as actions that submitters can take to help code receive a 'Ship It'. <b>Action to take: document a check-list for reviewers</b>. Some areas discussed included:
<ul>
<li>The higher the complexity, the more likely the need for automated testing or some other verification that the code is well tested. This can include several other items, that may be part of the same review or separate reviews:
<ul>
<li>Unit Testing via the Asterisk Unit Test Framework</li>
<li>Asterisk Test Suite tests</li>
</ul>
</li>
<li>The code needs to satisfy requirements for merging:
<ul>
<li>The code must follow the coding guidelines</li>
<li>The code should be well documented, and - if the item is a new feature or alters existing behavior - it should have sufficient documentation. This includes:
<ul>
<li>New config options in the sample config</li>
<li>Doxygen comments</li>
<li>Wiki docs for usage (if a new feature)</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>In general, submitters should wait 24hr for others to review after receiving a 'Ship It'. Not everyone lives in the same time zone!
<ul>
<li>If, for whatever reason, the patch has some time constraint and has to be merged sooner than 24 hours later, it should receive at least 2 ship its. This may only cover a hypothetical scenario, and may not need to be part of any written guideline.</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>Feature branches - may be nice to have a page on the wiki for 'team branches' of features not merged for a particular version. This will let the Asterisk Test Suite be pointed at the branch, make it known that its available, etc.</li>
<li>Testing
<ul>
<li>We need to publicize (better) the tools available for use. These tools should be made for use by everyone contributing to the Asterisk project.</li>
<li>Publicize what is tested - and at what level (unit, integration, system). Some automated mechanism that publishes the tests would be best, as that would prevent the documentation from getting out of sync with the tests. <b>Action taken: have the Unit Tests and Test Suite tests be documented on the Asterisk wiki</b></li>
<li>What is tested by Digium before a major release?
<ul>
<li>Asterisk testsuite</li>
<li>Manual tests (system level)</li>
<li>Testing is primarily core support level</li>
<li>Minimal (or none) testing of extended support level</li>
</ul>
</li>
</ul>
</li>
<li>What do we feel would be needed at a policy level regarding a "phone home" Data Capture module?
<ul>
<li>It must be "non evil", phone home</li>
<li>It should contain no personal info</li>
<li>It should tag a system by a unique ID, and you should know your own unique ID</li>
<li>You should be able to query all gathered data</li>
<li>It should be OPT OUT - easily turned off. We discussed OPT IN, but everyone agreed that OPT IN systems rarely get the kind of participation needed for them to be worthwhile.</li>
<li>It must be well publicized, in a variety of ways:
<ul>
<li>It must publicize where data is sent, and allow the user to control where data is sent. Valid options could be:
<ul>
<li>Digium only</li>
<li>Somewhere else only (that is, if you have multiple systems, you can have it send data only to your own service)</li>
<li>Digium+somewhere else</li>
</ul>
</li>
<li>You should be able to control what data is sent. Valid data that is sent could include:
<ul>
<li>Modules being used/versions</li>
<li>Calls processed</li>
<li>Registered endpoints</li>
<li>Technologies used</li>
<li>Uptime</li>
</ul>
</li>
<li>Open data transfer message format (the message specification for what data is sent should be publicized)</li>
<li>Well documented message specification, i.e., should not require reverse engineering the module</li>
<li>A separate module should control the sending</li>
<li>CLI warning should be displayed <b>as the last message before the prompt</b> instructing the user that data is being sent, and how to turn it off.</li>
</ul>
</li>
</ul>
</li>
<li>Project pages. All major projects should have a project page on the Asterisk wiki where people can go and learn what active projects are currently being worked on. The project pages are <b>not</b> a place for discussion, but rather a focal point for resources related to that project.
<ul>
<li>This page should link to any major asterisk-dev list discussions.</li>
<li>Announce on mailing list when a project is kicked off - provide links to wiki for more detail</li>
<li>Page should include requirements, high level design, links to JIRA issues for tasking, links to code reviews, outstanding tasks, etc.</li>
</ul>
</li>
<li>Mailing list policies
<ul>
<li>We currently require all mailing list discussions to be conducted only through the mailman server, i.e., you can't CC the mailing list. This can make it difficult if a particular mailing list is not one that you interact with on a constant basis. A proposal was made to not require mailing list discussions to be conducted only through mailman server.</li>
<li>Counter-argument: the configuration would most likely need need tweaks for duplicate messages, and allowing conversations to CC a mailing list might mean that conversations fall off of the list easier (or never get put on it in the first place)</li>
<li><b>We didn't seem to come to a conclusion on this issue. If anyone feels like this needs more discussion, please start a policy discussion on the asterisk-dev list.</b></li>
</ul>
</li>
</ul>
<h2><a name="AstriDevCon2012-ChannelDrivers"></a>Channel Drivers</h2>
<ul>
<li>SIP Channel driver - issues
<ul>
<li>huge tracts of code
<ul>
<li>lack of stack-based structuring</li>
<li>bugfixes very often create more bugs, even with experienced Asterisk devs</li>
<li>Unapproachable for new developers</li>
</ul>
</li>
</ul>
</li>
<li>new parallel channel driver
<ul>
<li>what should the driver provide?
<ul>
<li>B2BUA</li>
<li>Register</li>
<li>Subscription</li>
<li>More (not proxy)?</li>
</ul>
</li>
<li>services provided should be built in separate modules</li>
<li>use GPL SIP stack - don't reinvent the wheel
<ul>
<li>PJSIP, Sofia? Others? Should be discussed on dev list</li>
<li>Have someone full time on stack?</li>
<li>Pick a version of the stack for a branch of Asterisk</li>
<li>testing - interop testing (SIPit)</li>
</ul>
</li>
<li>Data Access Layer
<ul>
<li>Must support Legacy configs</li>
</ul>
</li>
<li>Need agreed upon set of functionality</li>
<li>layers of abstraction - modular</li>
</ul>
</li>
<li>Skinny Channel driver
<ul>
<li>SCCP being developed by Avencall team
<ul>
<li>need team branch for 1.8</li>
<li>forward port to trunk</li>
<li>double check feature parity with chan_skinny</li>
<li>Work with Damien Wedhorn (current maintainer of chan_skinny) to determine feature set</li>
<li>Find ways to integrate development processes with Asterisk</li>
</ul>
</li>
</ul>
</li>
<li>chan_rtp
<ul>
<li>RTP API as a resource module?</li>
<li>Expose RTP functionality without requiring signalling?</li>
</ul>
</li>
<li>the future of chan_agent
<ul>
<li>Current implementation == crashy</li>
<li>makes abstraction of the agent easy (doable without chan_agent, but hard)</li>
<li>replace app_queue with tiny pieces?</li>
<li>further discussion on this within APIs</li>
</ul>
</li>
</ul>
<h2><a name="AstriDevCon2012-Core"></a>Core</h2>
<ul>
<li>console logging (format) - kobaz has done some work on this and may be getting closer to being able to have it reviewed</li>
<li>scalability
<ul>
<li>What is the ability to scale -mmichelson
<ul>
<li>RT</li>
<li>Should we use an API that provides federation?</li>
<li>UUID for an Asterisk instance
<ul>
<li>expose system name out of system.conf</li>
</ul>
</li>
<li>multiple data storage for ASTDB</li>
<li>media storage as a resource</li>
</ul>
</li>
</ul>
</li>
<li>Monolithic App breakup
<ul>
<li>Queues</li>
<li>VoiceMail</li>
</ul>
</li>
<li>cdrs</li>
</ul>
<h2><a name="AstriDevCon2012-APIs"></a>APIs </h2>
<ul>
<li>Manager
<ul>
<li>Problems
<ul>
<li>tracking calls in transfer scenarios
<ul>
<li>channel tracking</li>
<li>UUID per channel</li>
</ul>
</li>
<li>no spec - is it worth specifying a broken protocol or implementing a specified, consistent protocol with other proven implementations, which provides additional features (multi-tennancy, real security, federation, load balancing)? (<a href="http://rayo.org/xep" class="external-link" rel="nofollow">http://rayo.org/xep</a>)</li>
<li>events lack documentation (getting there)
<ul>
<li>Register events
<ul>
<li>prevent unregistered events from going out, log error</li>
</ul>
</li>
<li>Accurate timestamping</li>
<li>Meta events</li>
<li>Efficiency</li>
<li>Documentation</li>
<li>Channel lifetime</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li>AsyncAGI
<ul>
<li>No ability to rescue a channel dumped into AsyncAGI without a response</li>
<li>Global scope, races if multiple AMI users are listening to AsyncAGI</li>
</ul>
</li>
<li>Asynchronous media control
<ul>
<li>External Message Bus
<ul>
<li>multi-cast</li>
</ul>
</li>
<li>SIP event observers</li>
</ul>
</li>
<li>Consistency
<ul>
<li>Bridge as object</li>
<li>Lightweight Dial</li>
<li>Originate and Bridge?</li>
</ul>
</li>
<li>Message send</li>
<li>MSRP support</li>
<li>Compliance/Regression tests with API consumers</li>
<li>API Standardization<br/>
*SLA - Need to explore SLA using ConfBridge</li>
</ul>
<h2><a name="AstriDevCon2012-Review"></a>Review</h2>
<h3><a name="AstriDevCon2012-AstriDevCon2011ProjectsAST%3AAstriDevCon2011"></a><a href="/wiki/display/AST/AstriDevCon+2011" title="AstriDevCon 2011">AstriDevCon 2011 Projects</a></h3>
<h5><a name="AstriDevCon2012-%28P0%29"></a>(P0)</h5>
<ul>
<li>SIP path support (Olle)
<ul>
<li>(first generation of code exists, needs more work, simple patch, going to get it done, needs an extra field in astdb; helps when there are 2 or more load balancing proxies in front of asterisk, when you'd like the call to be able to get back to Asterisk; see <a href="https://reviewboard.asterisk.org/r/991/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/991/</a>)</li>
<li><a href="https://issues.asterisk.org/view.php?id=18223" class="external-link" rel="nofollow">https://issues.asterisk.org/view.php?id=18223</a></li>
<li><b>Review 2011</b>: No change since 2010</li>
</ul>
</li>
<li>Group variables (Kobaz)
<ul>
<li>(on review board, in progress)</li>
<li><b>Review 2011</b>: Code written and then re-written this year, tested in production for a year. Feels good code wise. Some suggestions on reviewboard and should be converted to ao2.
<ul>
<li>Goal to commit for Asterisk 11</li>
<li><a href="http://reviewboard.asterisk.org/r/464" class="external-link" rel="nofollow">http://reviewboard.asterisk.org/r/464</a></li>
<li><a href="https://issues.asterisk.org/jira/browse/ASTERISK-15439" class="external-link" rel="nofollow">https://issues.asterisk.org/jira/browse/ASTERISK-15439</a></li>
</ul>
</li>
</ul>
</li>
<li><del>Pre-Dial (Kobaz) <a href="/wiki/pages/createpage.action?spaceKey=AST&title=Finished%2C+Committed&linkCreation=true&fromPageId=21463921" class="createlink">Finished, Committed</a></del>
<ul>
<li><del>(I think it's done. Been in production for 12+months with no hiccups. Needs review!)</del></li>
<li><del><b>Review 2011</b>: Very happy with the way it is. Uploaded latest diff against trunk.</del>
<ul>
<li><del>Goal to commit for Asterisk 11</del></li>
<li><a href="https://reviewboard.asterisk.org/r/1229/" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/1229/</a></li>
<li><a href="https://issues.asterisk.org/jira/browse/ASTERISK-19548" class="external-link" rel="nofollow">https://issues.asterisk.org/jira/browse/ASTERISK-19548</a></li>
</ul>
</li>
</ul>
</li>
<li><del>Hangup Handlers (Kobaz) <a href="/wiki/pages/createpage.action?spaceKey=AST&title=Finished%2C+Committed&linkCreation=true&fromPageId=21463921" class="createlink">Finished, Committed</a></del>
<ul>
<li><del>(Needs to be updated to use the same gosub parse/exec as PreDial uses)</del></li>
<li><del><b>Review 2011</b>:</del>
<ul>
<li><del>Goal to commit for Asterisk 11</del></li>
<li><a href="https://reviewboard.asterisk.org/r/1230" class="external-link" rel="nofollow">https://reviewboard.asterisk.org/r/1230</a></li>
</ul>
</li>
</ul>
</li>
<li>Distributed extension state using SIP (Olle)
<ul>
<li>(resources in place, doing it, 1.4 done before Christmas, project pinana)</li>
<li><b>Review 2011</b>: No changes known. Idle.</li>
</ul>
</li>
<li><del>Manager event docs (Paul Belanger)</del>
<ul>
<li><b>Review 2011</b>: <del>Code was created and working, but did not pass code review. Talked about it again a couple of months ago, and some work done.</del>
<ul>
<li><del>About a day or two to get the framework completed</del></li>
<li><del>Then just need to insert the documentation into the code and then it could be completed.</del></li>
</ul>
</li>
</ul>
</li>
<li>Cross-platform documentation (Ben Klang)
<ul>
<li>(caveats for using Asterisk on operating system xyz; pull a PDF of the Wiki documentation into the source, don't forget to include basic installation information, and do it all in .txt - Ben)</li>
<li><b>Review 2011</b>: Documentation updated for Solaris. Is on the wiki, and just needs to be put into a better location. Leif will help restructure part of the wiki to make the Linux and Solaris documentation (and other operating systems) a better format.</li>
</ul>
</li>
<li><del>Fix libs to optionally init OpenSSL (Digium)</del>
<ul>
<li><del>(or use existing tools; sort of a bug)</del></li>
<li><b>Review 2011</b>: <del>Code on reviewboard, need to confirm that the code solves the problem, confirmed it doesn't cause harm</del>
<ul>
<li><del>Testing required on multiple platforms and libraries</del></li>
</ul>
</li>
</ul>
</li>
<li><del>Make ast_channel an opaque type (Digium)</del>
<ul>
<li><b>Review 2011</b>: <del>Large project and has not been started. Should not be on P0.</del></li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P1%29"></a>(P1)</h5>
<ul>
<li><del>Who hung up? (there's a branch, shouldn't take too much time - Olle)</del>
<ul>
<li><b>Review 2011</b>: <del>Jason Parker thinks something like that may have been committed a few months ago by Jeffrey C. Ollie. Will need to review to see if anything has actually been done there.</del>
<ul>
<li><del>Kobaz has a 2-3 line code change that simply adds events to Softhangup() and Hangup()</del></li>
<li><del>On a failed call, there is no access to the causecodes – would be powerful if we had access to it</del>
<ul>
<li><del>Would need to develop some code that created a generic layer to convert between channel drivers (each does it different)</del></li>
<li><del>Need to investigate if there are any CEL events already created that will give some of that information</del></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><del><a href="/wiki/display/AST/Media+Overhaul" title="Media Overhaul">Codecs (SILK, OPUS), Media Negotiation</a></del> (Digium)
<ul>
<li><b>Review 2011</b>: <del>Every version of Asterisk had a fixed bitfield, and we needed to be conscious about adding new codecs (limited). Project was to remove that limitation. Reworked how media formats are represented in Asterisk. Integration of codecs like SILK and CELT. Helps with better support for video as well.</del>
<ul>
<li><del>Framework in place</del></li>
<li><del>Need to now start using the framework to help add functionality to Asterisk</del></li>
<li><del>For Asterisk 11, would be nice to add re-invite support so that clients and re-negotiate resolutions (for video). End-to-end negotiation. Framework in place to do that, just need to add the functionality.</del></li>
</ul>
</li>
</ul>
</li>
<li>RTCP (Olle)
<ul>
<li>Pinefrog; Work to be done - Ported to trunk, added to CEL</li>
<li><b>Review 2011</b>: Idle</li>
</ul>
</li>
<li><del>Conferencing that supports a new magic media</del> (Digium)
<ul>
<li><b>Review 2011</b>: Completed and in Asterisk 10. Updated ConfBridge() application which was pretty much re-written. Now supports high resolution codecs and voice activity video switching within ConfBridge().</li>
<li><del>higher sampling rates</del></li>
<li><b>Review 2011</b>: Part of the codec negotiation framworks.</li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P2%29"></a>(P2)</h5>
<ul>
<li>Async DNS (TCP DNS and use a good resolver)
<ul>
<li><b>Review 2011</b>: No change known.</li>
</ul>
</li>
<li>Named ACLs (deluxepine)
<ul>
<li><b>Review 2011</b>: Idle</li>
</ul>
</li>
<li><a href="/wiki/display/AST/SIP+Security+Events" title="SIP Security Events"><del>SIP Security Events</del></a>
<ul>
<li><b>Review 2011</b>: <del>Additional work was updated and put into Asterisk 10. Only reported manager authentication events prior to Asterisk 10.</del>
<ul>
<li><del>Prior to Asterisk 10 relaxed policy a bit and added chan_sip security events (only for inbound registration).</del></li>
<li><del>Additional work needed throughout Asterisk to add more events.</del></li>
<li><del>Added to Asterisk 10. Reference: <a href="https://issues.asterisk.org/jira/browse/ASTERISK-18264" class="external-link" rel="nofollow">https://issues.asterisk.org/jira/browse/ASTERISK-18264</a></del></li>
</ul>
</li>
</ul>
</li>
<li><del>Light weight means of holding NAT open in SIP (less complex than current qualify, Consider it done)</del>
<ul>
<li><b>Review 2011</b>: <del>No change.</del></li>
</ul>
</li>
<li><del>IPv6 for the restivus</del> (IAX, <del>Jabber/XMPP/Gtalk, Manager, etc.)</del>
<ul>
<li><b>Review 2011</b>: <del>No change.</del></li>
</ul>
</li>
<li><del>ConfBridge feature complete with MeetMe</del>
<ul>
<li><b>Review 2011</b>: Not entirely true, but very close.</li>
</ul>
</li>
<li>Support sound file containers (matroska)
<ul>
<li><b>Review 2011</b>: Suggestion to have (media) files used by Asterisk not just headerless files, so you could actually do things properly, like storing G729 that contains silent suppression information.
<ul>
<li>No change in Asterisk, but has been getting worked on for Asterisk SCF. Very complicated. Matroska is just a framework. Once stable for Asterisk SCF, we can consider building it for Asterisk as well.</li>
</ul>
</li>
</ul>
</li>
<li>RTMP client channel driver
<ul>
<li><b>Review 2011</b>: No change.</li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P3%29"></a>(P3)</h5>
<ul>
<li><del>Unique identifier for filtering log data to a call</del>
<ul>
<li><del>(finishing what was already begun w/ Clod's project, CLI filtering; should take a look at what Stephan from Unlimitel.ca's created)</del></li>
<li><b>Review 2011</b>: <del>Claude's patch was only for CLI filtering.</del>
<ul>
<li><del>Discussion about in the logger.conf to change the configuration so that the 'core set verbose 5' (or debug, etc) that it does not affect all the configuration files when you just want to change the verbosity on the console. (<a href="https://issues.asterisk.org/jira/browse/ASTERISK-18352" class="external-link" rel="nofollow">https://issues.asterisk.org/jira/browse/ASTERISK-18352</a>)</del></li>
<li>Configuration could be under a header, and then create your own filters for channels, and what verbosity,debug,etc. is output to a log file and console per file</li>
<li><b>Take Away</b>: Need to have a discussion of what people would want and need (requirements gathering), and then we can investigate how difficult it would be to implement, and what the order of implementation.</li>
</ul>
</li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P4%2CSimon%27sfeatures%29"></a>(P4, Simon's features)</h5>
<ul>
<li>Multiple SIP Sockets
<ul>
<li>(Listen on multiple ports or on multiple interfaces, but not all; also set binding for RTP)...alternate idea / solution would be to make Asterisk capable of loading multiple SIP profiles, it might be easier</li>
<li><b>Review 2011</b>: No change.</li>
</ul>
</li>
<li>Multiple DNS results
<ul>
<li>(need to be able to traverse a list of DNS results, rather than just getting back one result)</li>
<li><b>Review 2011</b>: Some work has been done, but chan_sip (or others) has not been enhanced to take advantage of that.</li>
</ul>
</li>
<li><del>ICE-lite</del>
<ul>
<li><del>(no code, responding correctly to ICE connectivity checks (STUN multiplexed on the RTP port) and understanding the SDP); it makes NAT traversal work for clients that do ICE; also addressed lightweight NAT refresh)</del></li>
<li><b>Review 2011</b>: <del>No change or progress. No one has tried to work on it. Appears to be very little deployment.</del></li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P5%29"></a>(P5)</h5>
<ul>
<li><del>AstDB replacement</del> SQLite
<ul>
<li><b>Review 2011</b>: <del>Have initial support implemented for Asterisk 10. Backend is being used. Terry is continuing to work on additional functionality in trunk.</del></li>
</ul>
</li>
<li>SIP identity
<ul>
<li>(on reviewboard; needs to be forward ported; important for organizations w/ federated identities; a requirement for DTLS SRTP; not widely deployed)</li>
<li><b>Review 2011</b>: No change.\</li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P6%29"></a>(P6)</h5>
<ul>
<li>Structured identifiers for errors
<ul>
<li>(tag an error message with a unique string, specific to the error message and where it came from; should be alphanumeric to keep them short)</li>
<li><b>Review 2011</b>: No change. Nice to have feature, but someone needs to take it on as a personal project. Essentially building a knowledge base. Would have to research what a code would look like, then pick 10, start with those, and continue to expand over time.</li>
</ul>
</li>
<li>AMI SetVar, Context limits
<ul>
<li>(there's code already...Olle has it)</li>
<li><b>Review 2011</b>: Idle.</li>
</ul>
</li>
<li><del>AMI filters on demand</del>
<ul>
<li><b>Review 2011</b>: Created by Kobaz and is part of Asterisk 10. Allows you to add filters per session and not globally.</li>
</ul>
</li>
<li><del>DTLS SRTP</del>
<ul>
<li><del>(not likely to be widely deployed in the next 12 months)</del></li>
<li><b>Review 2011</b>: <del>No progress has been made. Only one library has it, and is not very mature. Not really up to the Asterisk project to solve the problem. Future consideration.</del></li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P7%2Cnotkobaz%29"></a>(P7, not kobaz)</h5>
<ul>
<li>Write a Specification for AMI (not kobaz)
<ul>
<li><b>Review 2011</b>: Goes hand-in-hand with the event documentation. Make it so that we do no break AMI versions – no changes within the same version. We can do this since we do have the ability to version the AMI commands.</li>
</ul>
</li>
<li>Multiple TLS server certs
<ul>
<li>(1 socket, requires support by OpenSSL; simpler to implement than multiple SIP profiles; don't know if any clients use it yet; needs more research)</li>
<li><b>Review 2011</b>: Currently no SIP end points that support the mechanism, and some discussion on SIP lists say that an RFC should be written. Not very difficult to do on the server side of things. Could be done between Asterisk to Asterisk since we'd implement both the client and the server.</li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P8%2Cnicetohave%29"></a>(P8, nice to have)</h5>
<ul>
<li>Make resource modules that talk to DBs attempt reconnects
<ul>
<li><b>Review 2011</b>: Added reconnect support to res_config_postgres by Kobaz. Already part of res_odbc. Other native drivers should have it added. Could abstract the reconnection support so that we don't duplicate code. Some work done, more work still possible.</li>
</ul>
</li>
<li>Apple's new file streaming format, derived from .m3u
<ul>
<li><b>Review 2011</b>: No changes known.</li>
</ul>
</li>
<li><del>Make MixMonitor and Monitor feature compatible</del>
<ul>
<li><b>Review 2011</b>: Done in Asterisk 10 (per David Vossel)
<ul>
<li>Some discussion should be done to move res_monitor to 'extended' or 'deprecated' support level. MixMonitor() likely is now feature complete for Monitor(), especially since MixMonitor() has been implemented in a more friendly manner (in terms of I/O and threading).</li>
</ul>
</li>
</ul>
</li>
</ul>
<h5><a name="AstriDevCon2012-%28P%3F%2CResearchRequired%29"></a>(P?, Research Required)</h5>
<ul>
<li>New app_queue (as if? no, seriously? talking about this scares Russell)
<ul>
<li><b>Review 2011</b>: Suggested by Kevin that we could have a single box that handles no media, and just does the signalling. Since the agents can be distributed with distributed device state, all registrations would be remote from the queue server. There needs to be an atomic server that would handle the decision making.
<ul>
<li>Gregory (irroot) – additional skills based routing code and features.</li>
</ul>
</li>
</ul>
</li>
<li>Identify and fix all bugs in AMI
<ul>
<li><b>Review 2011</b>: In progress.</li>
</ul>
</li>
<li>Broadsoft or Dialog Info shared line appearance (SLA) support
<ul>
<li>(Tabled for later discussion)</li>
<li><b>Review 2011</b>: Licensing issues. Code written using documentation that is marked as confidential. No situation change. Unable to merge code.</li>
</ul>
</li>
<li><del>LDAP from within the dialplan</del>
<ul>
<li>(we may already have it, needs research to see if the realtime driver does what's desired - Leif)</li>
<li><b>Review 2011</b>: Yes you can already do this using dialplan functions. REALTIME_FIELD and REALTIME_HASH, etc..</li>
</ul>
</li>
<li>Device state normalization
<ul>
<li><b>Review 2011</b>: Unknown what this means. Could be different channel drivers report different types of information. No change.</li>
</ul>
</li>
<li>Anything DB over HTTP(s) with failover handling
<ul>
<li><b>Review 2011</b>: Unknown what this is.</li>
</ul>
</li>
<li>Use a channel as a MoH Source
<ul>
<li><b>Review 2011</b>: Still a neat idea.</li>
</ul>
</li>
<li>Kill Masquerades
<ul>
<li><b>Review 2011</b>: With fire! (Kevin)</li>
</ul>
</li>
<li>Bridging thread pool
<ul>
<li><b>Review 2011</b>: If you have 200 calls up, you have 200 threads up just polling, when you could just have 10 that each handle 20 bridges, and then you reduce context switching. (That's the idea.) Code not likely flexible enough to do this. Could be done... (Kevin)</li>
</ul>
</li>
<li>Threadify chan_sip
<ul>
<li><b>Review 2011</b>: This would cause an entire re-write on chan_sip, so this is not possible unless a new channel driver were written.</li>
</ul>
</li>
<li>Export ISDN ROSE information up to Asterisk channels
<ul>
<li><b>Review 2011</b>: Not much was really discussed on this as there has not been much requirement for it.</li>
</ul>
</li>
</ul>
<h3><a name="AstriDevCon2012-ProjectsDiscussed"></a>Projects Discussed</h3>
<ul>
<li>Group variables (Kobaz)
<ul>
<li>(on review board, in progress)</li>
<li>Code written and then re-written last year; has been in production for some time.</li>
<li>Kobaz to take a look at getting the review refreshed
<ul>
<li><a href="http://reviewboard.asterisk.org/r/464" class="external-link" rel="nofollow">http://reviewboard.asterisk.org/r/464</a></li>
<li><a href="https://issues.asterisk.org/jira/browse/ASTERISK-15439" class="external-link" rel="nofollow">https://issues.asterisk.org/jira/browse/ASTERISK-15439</a></li>
</ul>
</li>
</ul>
</li>
<li>RTCP (Olle)
<ul>
<li>Pinefrog; Work to be done - Ported to trunk, added to CEL</li>
<li>Mentioned that this would be really nice to have.</li>
</ul>
</li>
<li>Async DNS (TCP DNS and use a good resolver)
<ul>
<li>Many people mentioned that having asynchronous DNS and supporting multpile srv records would resolve a lot of issues with Asterisk behind SIP proxies. This would be a good project for Asterisk 12.</li>
</ul>
</li>
<li>Named ACLs (deluxepine)
<ul>
<li>Named ACLs committed for Asterisk 11; however, this did not fully capture all of the use cases of Olle's deluxepine branch.</li>
<li>For folks interested in security, this may be worth looking into.</li>
</ul>
</li>
<li>IPv6 Support for chan_iax2</li>
<li>Call-ID Logging Filtering
<ul>
<li>Make use of the call-id that is tagged with channels through other mechanisms (CLI filtering, etc.)</li>
</ul>
</li>
</ul>
<h1><a name="AstriDevCon2012-AgreedUponGoals"></a>Agreed Upon Goals</h1>
<p>After much discussion, the attendees agreed that two broad areas needed to be addressed for Asterisk 12. While many other projects should also receive attention, these two goals should be the focus of the Asterisk developer community. These are:</p>
<ul>
<li>Overhaul the SIP functionality in Asterisk.</li>
<li>Make the APIs exposed by Asterisk consistent and easier to build applications on top of.</li>
</ul>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2012">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=21463921&revisedVersion=11&originalVersion=10">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2012?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>