<html>
<head>
<meta name="viewport" content="width=device-width" />
<base href="https://wiki.asterisk.org/wiki" />
<style type="text/css">
body, #email-content, #email-content-inner { font-family: Arial,FreeSans,Helvetica,sans-serif; }
body, p, blockquote, pre, code, td, th, li, dt, dd { font-size: 13px; }
small { font-size: 11px; }
body { width:100% !important; -webkit-font-smoothing: antialiased; }
body,
#email-wrapper { background-color: #f0f0f0; }
#email-wrapper-inner { padding: 20px; text-align: center; }
#email-content-inner { background-color: #fff; border: 1px solid #bbb; color: $menuTxtColour; padding:20px; text-align:left; }
#email-wrapper-inner > table { width: 100%; }
#email-wrapper-inner.thin > table { margin: 0 auto; width: 50%; }
#email-footer { padding: 0 16px 32px 16px; margin: 0; }
.email-indent { margin: 8px 0 16px 0; }
.email-comment { margin: 0 0 0 56px; }
.email-comment.removed { background-color: #ffe7e7; border: 1px solid #df9898; padding: 0 8px;}
#email-title-avatar { text-align: left; vertical-align: top; width: 48px; padding-right: 8px; }
#email-title-flavor { margin: 0; padding: 0 0 4px 0; }
#email-title-heading { font-size: 16px; line-height: 20px; min-height: 20px; margin: 0; padding: 0; }
#email-title .icon { border: 0; padding: 0 5px 0 0; text-align: left; vertical-align: middle; }
#email-actions { border-top: 1px solid #bbb; color: #505050; margin: 8px 0 0 0; padding: 0; }
#email-actions td { padding-top: 8px; }
#email-actions .left { max-width: 45%; text-align: left; }
#email-actions .right { text-align: right; }
.email-reply-divider { border-top: 1px solid #bbb; color: #505050; margin: 32px 0 8px 0; padding: 8px 0; }
.email-section-title { border-bottom: 1px solid #bbb; margin: 8px 0; padding: 8px 0 0 0; }
.email-metadata { color: #505050; }
a { color: #326ca6; text-decoration: none; }
a:hover { color: #336ca6; text-decoration: underline; }
a:active {color: #326ca6; }
a.email-footer-link { color: #505050; font-size: 11px; }
.email-item-list { list-style: none; margin: 4px 0; padding-left: 0; }
.email-item-list li { list-style: none; margin: 0; padding: 4px 0; }
.email-list-divider { color: #505050; padding: 0 0.35em; }
.email-operation-icon { padding-right: 5px; }
.avatar { -ms-interpolation-mode: bicubic; border-radius: 3px;}
.avatar-link { margin: 2px; }
.tableview th { border-bottom: 1px solid #69C; font-weight: bold; text-align: left; }
.tableview td { border-bottom: 1px solid #bbbbbb; text-align: left; padding: 4px 16px 4px 0; }
.aui-message { margin: 1em 0; padding: 8px; }
.aui-message.info { background-color: #e0f0ff; border: 1px solid #9eb6d4; }
.aui-message.success { background-color: #ddfade; border: 1px solid #93c49f; }
.aui-message.error,
.aui-message.removed { background-color: #ffe7e7; border: 1px solid #df9898; color: #000; }
.call-to-action-table { margin: 10px 1px 1px 1px;}
.call-to-cancel-container, .call-to-action-container { padding: 5px 20px; }
.call-to-cancel-container { border: 1px solid #aaa; background-color: #eee; border-radius: 3px; }
.call-to-cancel-container a.call-to-cancel-button { background-color: #eee; font-size: 14px; line-height: 1; padding: 0; margin: 0; color: #666; font-family: sans-serif;}
.call-to-action-container { border: 1px solid #486582; background-color: #3068A2; border-radius: 3px; padding: 4px 10px; }
.call-to-action-container a.call-to-action-button { background-color: #3068A2; font-size: 14px; line-height: 1; padding: 0; margin: 0; color: #fff; font-weight: bold; font-family: sans-serif; }
/** The span around the inline task checkbox image */
.diff-inline-task-overlay {
display: inline-block;
text-align: center;
height: 1.5em;
padding: 5px 0px 1px 5px;
margin-right: 5px;
/** Unfortunately, the negative margin-left is stripped out in gmail */
margin-left: -5px;
}
@media handheld, only screen and (max-device-width: 480px) {
div, a, p, td, th, li, dt, dd { -webkit-text-size-adjust: auto; }
small, small a { -webkit-text-size-adjust: 90%; }
td[id=email-wrapper-inner] { padding: 2px !important; }
td[id=email-content-inner] { padding: 8px !important; }
td[id="email-wrapper-inner"][class="thin"] > table { text-align: left !important; width: 100% !important; }
td[id=email-footer] { padding: 8px 12px !important; }
div[class=email-indent] { margin: 8px 0px !important; }
div[class=email-comment] { margin: 0 !important; }
p[id=email-title-flavor] a { display: block; } /* puts the username and the action on separate lines */
p[id=email-permalink] { padding: 4px 0 0 0 !important; }
table[id=email-actions] td { padding-top: 0 !important; }
table[id=email-actions] td.right { text-align: right !important; }
table[id=email-actions] .email-list-item { display: block; margin: 1em 0 !important; word-wrap: normal !important; }
span[class=email-list-divider] { display: none; }
}
</style>
</head>
<body style="font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; width: 100%; -webkit-font-smoothing: antialiased; background-color: #f0f0f0">
<table id="email-wrapper" width="100%" cellspacing="0" cellpadding="0" border="0" style="background-color: #f0f0f0">
<tbody>
<tr valign="middle">
<td id="email-wrapper-inner" style="font-size: 13px; padding: 20px; text-align: center">
<table id="email-content" cellspacing="0" cellpadding="0" border="0" style="font-family: Arial, FreeSans, Helvetica, sans-serif; width: 100%">
<tbody>
<tr valign="top">
<td id="email-content-inner" align="left" style="font-family: Arial, FreeSans, Helvetica, sans-serif; font-size: 13px; background-color: #fff; border: 1px solid #bbb; padding: 20px; text-align: left">
<table id="email-title" cellpadding="0" cellspacing="0" border="0" width="100%">
<tbody>
<tr>
<td id="email-title-avatar" rowspan="2" style="font-size: 13px; text-align: left; vertical-align: top; width: 48px; padding-right: 8px"> <img class="avatar" src="cid:avatar_ce51dcf276530e4a4b00548e2a6d0905" border="0" height="48" width="48" style="-ms-interpolation-mode: bicubic; border-radius: 3px" /> </td>
<td valign="top" style="font-size: 13px">
<div id="email-title-flavor" class="email-metadata" style="margin: 0; padding: 0 0 4px 0; color: #505050">
<a href=" https://wiki.asterisk.org/wiki/display/~mjordan " style="color:#326ca6;text-decoration:none;; color: #326ca6; text-decoration: none">Matt Jordan</a> edited the page:
</div> </td>
</tr>
<tr>
<td valign="top" style="font-size: 13px"> <h2 id="email-title-heading" style="font-size: 16px; line-height: 20px; min-height: 20px; margin: 0; padding: 0"> <a href="https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2012" style="color: #326ca6; text-decoration: none"> <img class="icon" src="cid:page-icon" alt="" style="border: 0; padding: 0 5px 0 0; text-align: left; vertical-align: middle" /> <strong style="font-size:16px;line-height:20px;vertical-align:top;">AstriDevCon 2012</strong> </a> </h2> </td>
</tr>
</tbody>
</table>
<div class="email-indent" style="margin: 8px 0 16px 0">
<div class="email-diff">
<div id="page-diffs" class="wiki-content">
<p class="diff-block-target" style="font-size: 13px"> </p>
<table class="diff-macro bodyless diff-html-changed" style="background-color: #f0f0f0;border: 1px solid #dddddd;margin: 10px 1px;padding: 0 2px 2px;width: 100%;margin: 5px 0; padding: 0; width: auto;">
<thead>
<tr>
<th class="diff-macro-title" style="background-color: transparent; text-align: left; font-weight: normal;padding: 5px;; font-size: 13px"><span class="diff-html-changed" id="changed-diff-0" style="background-color: #d6f0ff;"><span class="icon macro-placeholder-icon" style="background-color: ;line-height: 20px;"><img src="https://wiki.asterisk.org/wiki/s/en_GB-1988229788/4252/6ac85e9b14675c5514a674e1aecae99c9505ed36.48/_/images/icons/macrobrowser/dropdown/toc.png" style="padding-right: 5px; vertical-align: text-bottom;" /> </span>Table of Contents</span></th>
</tr>
</thead>
<tbody>
<tr>
<td class="diff-macro-properties" style="background-color: #fafafa; padding: 0 0 0 5px; font-size: 12px; text-align: left;padding: 0; border: 1px solid #dddddd;; font-size: 13px">
<table>
<tbody>
<tr>
<td style="background-color: #fafafa; padding: 0 0 0 5px; font-size: 12px; text-align: left;; font-size: 13px"><span class="diff-html-changed" style="background-color: #d6f0ff;">maxlevel</span></td>
<td style="background-color: #fafafa; padding: 0 0 0 5px; font-size: 12px; text-align: left;; font-size: 13px"><span class="diff-html-changed" style="background-color: #d6f0ff;">3</span></td>
</tr>
</tbody>
</table> </td>
</tr>
</tbody>
</table>
<p style="font-size: 13px"></p>
<h1 id="AstriDevCon2012-Introduction" class="diff-block-context">Introduction</h1>
<p class="diff-block-context" style="font-size: 13px">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 class="diff-context-placeholder" style="font-size: 13px">...</p>
<ul class="diff-block-target">
<li style="font-size: 13px">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 style="font-size: 13px">We discovered that this policy was never written down in a clear, concise way.
<s>
<strong><span class="diff-html-changed" id="changed-diff-1" style="background-color: #d6f0ff;">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.</span></strong>
</s>
<ul>
<li style="font-size: 13px">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 style="font-size: 13px">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 style="font-size: 13px">Easier merge paths between branches (which will get more complicated with the EOL of Asterisk 10 in December)</li>
<li style="font-size: 13px">Potential process improvements that would allow verified code to be merged quicker into branches/trunk</li>
</ol>
<ul>
<li style="font-size: 13px">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 style="font-size: 13px">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 style="font-size: 13px">Other Development Tools
<ul>
<li style="font-size: 13px">Review Board/Code Reviews
<ul>
<li style="font-size: 13px">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'. <strong>Action to take: document a check-list for reviewers</strong>. Some areas discussed included:
<ul>
<li style="font-size: 13px">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 style="font-size: 13px">Unit Testing via the Asterisk Unit Test Framework</li>
<li style="font-size: 13px">Asterisk Test Suite tests</li>
</ul> </li>
<li style="font-size: 13px">The code needs to satisfy requirements for merging:
<ul>
<li style="font-size: 13px">The code must follow the coding guidelines</li>
<li style="font-size: 13px">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 style="font-size: 13px">New config options in the sample config</li>
<li style="font-size: 13px">Doxygen comments</li>
<li style="font-size: 13px">Wiki docs for usage (if a new feature)</li>
</ul> </li>
</ul> </li>
</ul> </li>
<li style="font-size: 13px">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 style="font-size: 13px">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 style="font-size: 13px">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. <strong>Action to take: make a space on the Asterisk wiki for the documentation of feature branches that are available</strong> </li>
<li style="font-size: 13px">Testing
<ul>
<li style="font-size: 13px">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 style="font-size: 13px">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. <strong>Action taken: have the Unit Tests and Test Suite tests be documented on the Asterisk wiki</strong> </li>
<li style="font-size: 13px">What is tested by Digium before a major release?
<ul>
<li style="font-size: 13px">Asterisk testsuite</li>
<li style="font-size: 13px">Manual tests (system level)</li>
<li style="font-size: 13px">Testing is primarily core support level</li>
<li style="font-size: 13px">Minimal (or none) testing of extended support level</li>
</ul> </li>
</ul> </li>
<li style="font-size: 13px">What do we feel would be needed at a policy level regarding a "phone home" Data Capture module?
<ul>
<li style="font-size: 13px">It must be "non evil", phone home</li>
<li style="font-size: 13px">It should contain no personal info</li>
<li style="font-size: 13px">It should tag a system by a unique ID, and you should know your own unique ID</li>
<li style="font-size: 13px">You should be able to query all gathered data</li>
<li style="font-size: 13px">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 style="font-size: 13px">It must be well publicized, in a variety of ways:
<ul>
<li style="font-size: 13px">It must publicize where data is sent, and allow the user to control where data is sent. Valid options could be:
<ul>
<li style="font-size: 13px">Digium only</li>
<li style="font-size: 13px">Somewhere else only (that is, if you have multiple systems, you can have it send data only to your own service)</li>
<li style="font-size: 13px">Digium+somewhere else</li>
</ul> </li>
<li style="font-size: 13px">You should be able to control what data is sent. Valid data that is sent could include:
<ul>
<li style="font-size: 13px">Modules being used/versions</li>
<li style="font-size: 13px">Calls processed</li>
<li style="font-size: 13px">Registered endpoints</li>
<li style="font-size: 13px">Technologies used</li>
<li style="font-size: 13px">Uptime</li>
</ul> </li>
<li style="font-size: 13px">Open data transfer message format (the message specification for what data is sent should be publicized)</li>
<li style="font-size: 13px">Well documented message specification, i.e., should not require reverse engineering the module</li>
<li style="font-size: 13px">A separate module should control the sending</li>
<li style="font-size: 13px">CLI warning should be displayed <strong>as the last message before the prompt</strong> instructing the user that data is being sent, and how to turn it off.</li>
</ul> </li>
</ul> </li>
<li style="font-size: 13px">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 <strong>not</strong> a place for discussion, but rather a focal point for resources related to that project.
<ul>
<li style="font-size: 13px">This page should link to any major asterisk-dev list discussions.</li>
<li style="font-size: 13px">Announce on mailing list when a project is kicked off - provide links to wiki for more detail</li>
<li style="font-size: 13px">Page should include requirements, high level design, links to JIRA issues for tasking, links to code reviews, outstanding tasks, etc.</li>
</ul> </li>
<li style="font-size: 13px">Mailing list policies
<ul>
<li style="font-size: 13px">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 style="font-size: 13px">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 style="font-size: 13px"> <strong>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.</strong> </li>
</ul> </li>
</ul>
<p class="diff-context-placeholder" style="font-size: 13px">...</p>
<ul class="diff-block-target">
<li style="font-size: 13px">SIP Channel driver. It has issues. As of October of 2012, ~25% of the open issues in JIRA are against <code style="font-size: 13px">chan_sip</code>. While that can be attributed to its usage, it can also be attributed to its design. A poll was taken of the attendees if anyone liked to maintain <code style="font-size: 13px">chan_sip</code>; no one raised their hand.
<ul>
<li style="font-size: 13px">The current SIP channel driver has huge tracts of code (31000 in 1.8; 34000 lines in trunk (which means we aren't actively making it better))
<ul>
<li style="font-size: 13px">The design has a lack of stack-based structuring. This makes means there is no transport layer; no transaction layer; no application layer; logic flows between all layers in the channel driver often on different code paths with little discernible logic as to why.</li>
<li style="font-size: 13px">Bugfixes very often create more bugs, even with experienced Asterisk devs.</li>
<li style="font-size: 13px">Unapproachable for new developers. This limits who can come in and contribute bug fixes, which is a very bad state for an open source project.</li>
</ul> </li>
</ul> </li>
<li style="font-size: 13px">Can we refactor the existing <code style="font-size: 13px">chan_sip</code>? This was discussed a bit, but given the following, it was not an approach that received a lot of support:
<ol>
<li style="font-size: 13px">Many have tried, all have failed</li>
<li style="font-size: 13px">It increases the risk of the project failing - even if a new SIP channel driver were written that did not meet all objectives, the existing one would still provide functionality. If we refactor it, we lose that safety net.</li>
</ol> </li>
<li style="font-size: 13px">
<s>
<strong><span class="diff-html-changed" id="changed-diff-2" style="background-color: #d6f0ff;">Project proposed: build a new parallel channel driver</span></strong>
</s>
<ul>
<li style="font-size: 13px">What should the driver provide?
<ul>
<li style="font-size: 13px">It must provide basic B2BUA capabilities</li>
<li style="font-size: 13px">Registrar</li>
<li style="font-size: 13px">Subscription</li>
<li style="font-size: 13px">More (but not a proxy)? <em>It was noted that it does not have to provide the above capabilities either - if it is built in a modular fashion, portions (such as registrar) could be removed</em> </li>
</ul> </li>
<li style="font-size: 13px">Services provided should be built in separate modules for flexibility and ease of maintenance</li>
<li style="font-size: 13px">Use a GPL SIP stack - don't reinvent the wheel.
<ul>
<li style="font-size: 13px">PJSIP, Sofia? Others? While we naturally leaned towards PJSIP, given Digium's experience with it on Asterisk SCF, this should first be discussed on the asterisk-dev list.</li>
<li style="font-size: 13px">If possible, try to have someone full time on the stack library development team.</li>
<li style="font-size: 13px">Pick a version of the stack for a branch of Asterisk. This will keep the stack in line with that version to prevent churn if the stack is upgraded in a release branch.</li>
<li style="font-size: 13px">Testing. Will be a huge effort, as we have to guarantee interoperability as much as possible. Should develop specific test scenarios and build out tests against the current SIP channel driver and then run them against the new one.
<ul>
<li style="font-size: 13px">Plan to do interop testing at SIPit when possible</li>
<li style="font-size: 13px">
<s>
<strong><span class="diff-html-changed" id="changed-diff-3" style="background-color: #d6f0ff;">Action taken: Build out a list of scenarios for SIP tests to be created in the Asterisk Test Suite to ensure that basic functionality works in a new SIP channel driver</span></strong>
</s> </li>
</ul> </li>
</ul> </li>
<li style="font-size: 13px">Data Access Layer
<ul>
<li style="font-size: 13px">We must support Legacy configs. Someone should be able to taken an existing <code style="font-size: 13px">sip.conf</code> and use the new SIP channel driver. A new configuration schema can also be defined, and we can implement a mechanism of exporting the in-memory objects to create a new SIP config file.</li>
</ul> </li>
<li style="font-size: 13px">Need to agree upon a set of functionality to have implemented for Asterisk 12.</li>
<li style="font-size: 13px">The channel driver must provide layers of abstraction - modular in nature.</li>
</ul> </li>
<li style="font-size: 13px">New SCCP Channel driver
<ul>
<li style="font-size: 13px">SCCP being developed by Avencall team. Very interested in replacing the existing <code style="font-size: 13px">chan_skinny</code>.
<ul>
<li style="font-size: 13px">Asked to provide a team branch for Asterisk 1.8. Asterisk Test Suite can be pointed at the team branch.</li>
<li style="font-size: 13px">Forward port to trunk</li>
<li style="font-size: 13px">Double check feature parity with chan_skinny</li>
<li style="font-size: 13px">Work with Damien Wedhorn (current maintainer of chan_skinny) to determine feature set</li>
<li style="font-size: 13px">Find ways to integrate development processes with Asterisk. This includes testing, project pages, etc.</li>
</ul> </li>
</ul> </li>
<li style="font-size: 13px">chan_rtp - or find a way to expose creating a media stream without signalling
<ul>
<li style="font-size: 13px">RTP API exists and is implemented as a resource module.</li>
<li style="font-size: 13px">Expose RTP functionality without requiring signalling?</li>
</ul> </li>
<li style="font-size: 13px"> <code style="font-size: 13px">chan_agent</code>, or the future of it.
<ul>
<li style="font-size: 13px">Current implementation is buggy and prone to problems. Multiple folks have experienced memory corruptions with no resolution (yet).</li>
<li style="font-size: 13px">Should we get rid of it? You <em>technically</em> can do everything without it. However, its existence makes abstraction of the agent easy (doable without chan_agent, but hard).</li>
<li style="font-size: 13px">On that same note, can we replace app_queue with tiny pieces?</li>
<li style="font-size: 13px">We noted that we could have further discussion on this within APIs</li>
</ul> </li>
</ul>
<p class="diff-context-placeholder" style="font-size: 13px">...</p>
</div>
</div>
</div>
<table id="email-actions" class="email-metadata" cellspacing="0" cellpadding="0" border="0" width="100%" style="border-top: 1px solid #bbb; color: #505050; margin: 8px 0 0 0; padding: 0; color: #505050">
<tbody>
<tr>
<td class="left" valign="top" style="font-size: 13px; padding-top: 8px; max-width: 45%; text-align: left"> <span class="email-list-item"><a href="https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2012" style="color: #326ca6; text-decoration: none">View Online</a> </span> <span class="email-list-divider" style="color: #505050; padding: 0 0.350em">·</span> <span class="email-list-item"><a href="https://wiki.asterisk.org/wiki/plugins/likes/like.action?contentId=21463921" style="color: #326ca6; text-decoration: none">Like</a> </span> <span class="email-list-divider" style="color: #505050; padding: 0 0.350em">·</span> <span class="email-list-item"><a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=21463921&revisedVersion=18&originalVersion=17" style="color: #326ca6; text-decoration: none">View Changes</a> </span> <span class="email-list-divider" style="color: #505050; padding: 0 0.350em">·</span> <span class="email-list-item"><a href="https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2012?showComments=true&showCommentArea=true#addcomment" style="color: #326ca6; text-decoration: none">Add Comment</a> </span> </td>
<td class="right" width="50%" valign="top" style="font-size: 13px; padding-top: 8px; text-align: right"> <span class="email-list-item"><a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST" style="color: #326ca6; text-decoration: none">Stop watching space</a> </span> <span class="email-list-divider" style="color: #505050; padding: 0 0.350em">·</span> <span class="email-list-item"><a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action" style="color: #326ca6; text-decoration: none">Manage Notifications</a> </span> </td>
</tr>
</tbody>
</table> </td>
</tr>
</tbody>
</table> </td>
</tr>
<tr>
<td id="email-footer" align="center" style="font-size: 13px; padding: 0 16px 32px 16px; margin: 0"> <small style="font-size: 11px"> This message was sent by <a class="email-footer-link" style="color:#505050;font-size:11px;text-decoration:none;; color: #326ca6; text-decoration: none; color: #505050; font-size: 11px" href="http://www.atlassian.com/software/confluence">Atlassian Confluence</a> 5.1.5, <a class="email-footer-link" style="color:#505050;font-size:11px;text-decoration:none;; color: #326ca6; text-decoration: none; color: #505050; font-size: 11px" href="http://www.atlassian.com/software/confluence/overview/team-collaboration-software?utm_source=email-footer">Team Collaboration Software</a> </small> </td>
</tr>
</tbody>
</table>
</body>
</html>