It’s been a few months since our update on Asterisk 12, and during that time period, the Asterisk Community has been hard at work enhancing and testing Asterisk – both for existing users of Asterisk 12 as well as in preparation for the next Long Term Support release, Asterisk 13. These new features focus heavily on improving the user experience in the new PJSIP stack and enhancing the existing APIs as well as the new Asterisk REST Interface (ARI). Several of these new features have been released recently in versions 12.2.0 and 12.3.0 – a few highlights include:
- Several new CLI commands were added for the PJSIP stack in Asterisk. These commands allow a system administrator to see the specific contacts associated with a registered SIP endpoint, detailed information about those contacts, currently configured outbound registrations, and the current PJSIP channels in Asterisk.
- A new PJSIP module has been added that integrates Asterisk with a HOMER SIP Capture server. This allows Asterisk to act as a SIP capture agent, forwarding all SIP traffic processed by the PJSIP stack to a HOMER SIP capture server. This is particularly useful for deployments with many Asterisk servers who need scalable monitoring of their message traffic.
- The creation of channels and other resources in both ARI and AMI have been improved by allowing user specification of the resource’s unique ID. Both of these interfaces have asynchronous components, and allowing the user to specify the unique ID of the resource being created makes it easier for applications to tie asynchronous events back to the operations that caused them to occur.
- ARI play operations – on both channels and bridges – now allow for indication tones to be played back to their respective resources. This allows application developers to take full advantage of indication tones defined in Asterisk.
- ARI now exposes finer grained control over bridge creation. When creating a bridge through the interface, an application can specify properties that it desires about the bridge – such as whether or not the application will want to consume DTMF from the participants in the bridge. Doing this allows for applications to take advantage of higher performance bridge mixing technologies when situations allow for it.
- User events can now be raised directly from ARI. These user events can be identical to the UserEvent raised from the dialplan, but can also reference and include information from multiple channels, as well as bridges. This allows ARI application developers to emit information to existing or new AMI applications.
A number of community members participated in the definition, development, and testing of these features. In particular, a huge thank-you to Alexandr Dubovikov of QSC AG, Ben Langfeld of Mojo Lingo, Alistair Cunningham of Integrics, George Joseph of Fairview 5 Engineering, and every one else who discussed, tested, reviewed, and developed the work that went into Asterisk 12.2.0 and Asterisk 12.3.0.