The A2Billing Team has posted a note asking people to upgrade their systems urgently:
It has been widely reported that a recently discovered bug in OpenSSL compromises the security of communications data. Any A2Billing administrator who has installed an SSL certificate to provide HTTPS encryption on their website should upgrade OpenSSL.
We've also had a 3rd party security expert audit A2Billing in the interests of increasing security. They have found a major security issue. We've no evidence that this exploit is in the wild, but we advise in the strongest possible terms that you upgrade to A2Billing version 2.0.8 as a matter of urgency.
If you need assistance with upgrading your operating system or A2Billing or an installation with transfer of A2Billing data, then please contact us at firstname.lastname@example.org
Matt Jordan has posted details of some changes to integration between JIRA and SVN:
Hey everyone -
Due to a security vulnerability in JIRA, we recently had to upgrade JIRA to version 6.2. While this was a good thing (tm), it did break the snot out of the Subversion plugin. That plugin does a number of things; one of those things is auto-closing issues based on the commit message.
Traditionally, the plugin used the following nomenclature to close an issue:
(closes issue JIRA_ISSUE)
Likewise, tagging a commit with the following linked the commit message to the issue:
While I'd like to believe the Subversion plugin will get fixed at some point, our initial forays into getting it fixed haven't been fruitful. Part of this is reticence on our part to 'customize' the plugin or our JIRA instance further (more on that in a bit); another large part is Atlassian appears to be focussing on an alternate method for tying commit messages back to issues (more on that in a bit as well). Long story short, it doesn't appear like anyone is in a hurry to fix the old Subversion plugin.
Question: why not hack on the Subversion plugin and/or JIRA?
Answer: we could hack around on the Subversion plugin and/or JIRA (it isn't clear yet who is at fault), but the more customization we put into it the harder it is to upgrade the project's JIRA instance. This makes it harder to respond quickly to security vulnerabilities. We've done a lot of work over the past year or so minimizing the customizations so that we can respond quickly to said vulnerabilities in JIRA, and it's been very handy. Unless there's a giant outcry against what I'm about to propose, I'd hope that we don't have to try and modify the plugin ourselves.
Question: what is this alternate method that Atlassian has?
Since we have Fisheye integration with JIRA, we can use a different commit message format that will trigger the smart commits in Fisheye, which will do all of the auto-closing for us in JIRA. In fact, as the name 'smart commit' implies, it can do a lot more than just close the issue, including leaving comments and other fanciness. It does mean however that our commit message format will have to change.
The biggest implication of changing the commit message format is making sure that patch submitters are properly attributed, such that the release summary scripts and other parts of the Asterisk project pick up who actually wrote the patch. Right now, I'm proposing something like the following:
Lenz from QueueMetrics has posted a link to their free eBook on Call Center satisfaction. Sorry for the delay in getting this up:
We are pleased to announce that our first call-centre customer satisfaction survey is online as a free eBook. We want to thank you all for supporting us in this research and answering to our questions.
According to our corporate philosophy that binds accurate data measurement to relevant business improvements, in 2013 we sent you a survey about the usage of Asterisk® and QueueMetrics™ for your daily needs in call-centers management, analysis and statistics. This was done to assess your perceived needs so that we could prioritize future improvements.
The results are quite relevant to all professionals who create or manage call-centers with Asterisk®. Too often, an Asterisk-based PBX is still perceived as a risky proposition by clients switching from other systems. But definitely Asterisk® proved to be a valid platform to build contact centres with, and grants its users an impressive level of customer satisfaction.
Matt Jordan has posted details of a change to review board access:
For some time now, the Asterisk project has used Review Board for performing code reviews on submitted patches. While having a patch be formally reviewed has never been a hard requirement for its inclusion, over time, the status quo in the project has evolved such that patches of any reasonable complexity are nearly always reviewed before being included. This is not a bad thing - code review is an invaluable tool in ensuring quality in the Asterisk project. However, some technical limitations with how accounts are configured in Review Board made it difficult for everyone to submit patches and participate in the review process. The situation today is that the vast majority of patches on the issue tracker are only looked at when they are first put up for code review. This has led to some high quality patches not being included in the Asterisk project as fast as they otherwise could.
This weekend, we finalized the integration of Review Board with Atlassian Crowd, the service that provides user identification and authentication for the rest of the Asterisk community services. This removes the bottleneck - namely, me! - that prevented any contributor from submitting patches for peer review.
For users who currently have an account in Review Board, if your username is the same as your Atlassian (JIRA) username, simply use your Atlassian password when logging in. Reviews that you currently have open will still be associated with you. If your existing username in Review Board is different than your Atlassian username, you will unfortunately need to re-open the reviews you have in Review Board. If that happens to be the case, contact me in #asterisk-dev or reply to this e-mail and we'll work it out.
For users who do not currently have an account in Review Board, if you signed a License Contributor Agreement in JIRA, this change opens Review Board up to you. Instructions for posting patches to Review Board can be found on the Asterisk wiki, as well as workflow guidelines for participating in code reviews. The wiki has other items to help you prepare a patch for review, including a check list of items to be aware of when performing a review or submitting a patch, as well as the project coding guidelines. Finally, because this change opens up Review Board to a much larger audience, the patch submission process has been clarified on the Asterisk wiki.
Please remember that this may greatly increase the volume of code reviews being submitted. Contributors are highly encouraged to participate in other code reviews as well, and to be patient with any submission they make. Patches that are accompanied by well written explanations, conform to the coding guidelines, and have accompanying unit tests and/or functional tests in the Asterisk Test Suite are always easier to review and will naturally move through the review process faster.
As always, thank-you for your support and participation in the Asterisk project - we hope that these changes make the process easier and more beneficial for everyone.
Digium, Inc. | Engineering Manager
Matt Jordan has posted details of a new Asterisk Developer:
George Joseph has been doing a lot of great work on the new PJSIP stack for Asterisk 12. This includes adding the PJSIP_HEADER function, allowing users to add, modify, and remove headers from SIP messages; adding just about all of the CLI commands for the PJSIP modules; updating the Asterisk build system to support Lua 5.2 for pbx_lua; and fixing several bugs in the new PJSIP stack. Along the way George has done some serious work ironing out the kinks in the code that formats PJSIP sorcery-derived objects for various interfaces. We're thrilled to extend George commit access for the Asterisk project, and look forward to more of his contributions to the project and the new PJSIP stack.
Welcome George Joseph!
(And we're sorry you have to use subversion to commit things. Git... some day, some day.)
Digium, Inc. | Engineering Manager
39 Free Softphones August 14, 2009 Average Vote: 17.3
I decided to do another round up article, this time focusing on the 39 best free softphones.
Asterisk 11.0.0-beta1 Now Available August 11, 2012 Average Vote: 10
The Asterisk Development Team is pleased to announce the first beta release of Asterisk 11.0.0 (the first Long Term Support release since 1.8).
oFono 1.0 has been released November 10, 2011 Average Vote: 10
Steve Totaro has forwarded details of the latest release of a project called oFono.
Discount for Astricon 2012 August 31, 2012 Average Vote: 10
Astricon 2012 is rapidly approaching and will be held in Atlanta between October 23 and 25. The Daily Asterisk News has secured a 20% discount on all tickets if you use the discount code.
Asterisk 10.0.0-rc1 Now Available November 11, 2011 Average Vote: 10
The Asterisk Development Team is pleased to announce the first release candidate of Asterisk 10.0.0.
New SIP channel driver project page November 23, 2012 Average Vote: 10
Mark Michelson has posted details of a wiki page that has been created to guide the development of a new SIP channel driver for Asterisk.
Asterisk and Google August 26, 2011 Average Vote: 10
Malcolm Davenport has posted a request on behalf of Digium for someone to help maintain the Google channel driver when Google makes changes.
espeak module for Asterisk August 22, 2011 Average Vote: 10
Lefteris Zafiris has posted details of a new version of the app_espeak application for Asterisk - another speech synthesizer.