It seems just like yesterday that Asterisk 13.8.0 was released but here we are with an Asterisk 13.9.0 (and subsequently 13.9.1). This post shines the light on some notable changes that may impact and be useful for everyone.
app_queue
A change went in to Asterisk 13.8.0 to fix an issue where the wrapuptime would not be respected on some calls. Unfortunately this change introduced a regression where a crash could occur when determining if a member can be dialed. This regression has now been fixed. If you’ve been experiencing any crashes when updating to Asterisk 13.8.0 with queues in the “can_ring_entry” function then you can upgrade to 13.9.0 to resolve the problem.
func_odbc
In Asterisk 13.8.0 changes were done to improve performance of the ODBC support in Asterisk. This has been previously discussed on the Gutting of ODBC blog post. Feedback from the community showed that the behavior of connection usage in func_odbc had been changed and resulted in some people experiencing problems with their queries. This has now been fixed so the previous behavior is restored and the same connection will be used for each DSN. Since this does introduce a performance penalty a separate issue has been created to eventually allow this to be toggled on and off as not all usage requires the same connection to be used.
res_pjsip
Through the testing and feedback of the Asterisk community PJSIP bundle support has been improved to work on a wider range of distributions and distribution versions. If you have previously experienced any problems with this please give 13.9.0 a try and if you run into any problems please file an issue on the issue tracker.
Realtime usage in res_pjsip has been improved to be more specific in what information it is requesting. This has resulted in fewer database queries and less data being retrieved by the res_pjsip module. Depending on the number of things you have stored in the database you may find that Asterisk starts up faster and generally works better.
res_pjsip_dialog_body_generator
The application/dialog-info+xml NOTIFY type is used by a few devices (such as Cisco SPA and Snoms) to get the extension state for hints. Some of these phones also allow ringing calls to be picked up using this method. Previously the constructed message did not contain the required attribute to allow this call pickup functionality to work. This attribute is now present and call pickup should work for these devices.
res_rtp_asterisk
For those using WebRTC you may have noticed problems with decrypting RTCP traffic. This was a problem as the same SRTP material was used for both RTP and RTCP. This was incorrect according to the RFC. As of Asterisk 13.9.0 both are negotiated independently and use their own SRTP information.
This is by no means a complete list of changes in Asterisk 13.9.0 so if you’d like to see everything that has gone into the release check out the ChangeLog which you can find on the downloads site or in the 13.9.0 tarball itself.
Notice though that since this blog post was written a 13.9.1 release has gone out. The 13.9.1 release is the latest you should download if you are installing 13.9. If you’re interested in why 13.9.1 exists stay tuned as a future blog post will go into detail on it.
7 Responses
how to activate the odbc pooling now?
is this example correct? is the FileUsage and Threading Level ok to use the unixODBC Pooling? res_odbc will or have a setting to activate this?
Example:
[ODBC]
Trace = N0
Trace File = /var/log/unixodbctrace.log
Pooling = Yes
[MSSQL]
Driver=/usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so
FileUsage=1
Threading=2
DontDLClose = 1
CPTimeout = 120
[MYSQL]
Description = MySQL 5.1 ODBC MyODBC Driver
Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc5a.so
FileUsage = 1
Threading = 2
DontDLClose = 1
CPTimeout = 120
There are no settings required in res_odbc to use this. It will use it automatically as the underlying ODBC is configured. An example is provided on the wiki[1] that’s been tested. As well I’d suggest you take any future questions to the Asterisk community site[2] for a wider audience and so others can more easily find the discussion.
[1] https://wiki.asterisk.org/wiki/display/AST/Getting+Asterisk+Connected+to+MySQL+via+ODBC
[2] https://community.asterisk.org/
> This has resulted in fewer database queries and less data being retrieved by the res_pjsip module.
Just to be sure – pjsip does not necessary require using DB? Can I use res_pjsip without configuring odbc at all?
PJSIP can still be configured using text files.
Hello Joshua,
I have asterisk 13 installed in a server and i already implemented a ARI application to handle the Stasis and everything in c++.
Right now I wanted to test performance comparing stasis and dialplans.
1- For stasis i already simulated several simultaneous calls and have the results.
2- For dialplans, i decided to send a UserEvent to let my client knows the call has ended (as i already did on Asterisk 11). That’s when the doubts came:
2.1) Can I send a UserEvent in the dial plan and capture it on my ARI client ? (I mean, i opened the socket connection using ari user configured in ari.conf) or do I need to enable manager.conf and configure a username there to connect to?
Is there any documentation I can use to make that performance test?
Do you have a benchmark test that shows a comparison between a very large amount of simultaneous calls using ARI (Stasis) and AMI. When I put ARI X AMI, I am talking about having a client application connected to the Asterisk to manage all the calls. So i need to register when the calls started and when all the calls ended. In my test i have 500 simultaneous calls where each call takes 1 min duration and hangups.
Thanks in advance,
Fabio Carvalho
I don’t believe that the UserEvent from the dialplan is sent out over ARI, but it is not something I have experimented with. Using AMI would definitely work. As for documentation about a performance test there is nothing official – as performance testing really depends on the application and environment. One minor change in what you are doing can cause different results. I am not aware of any benchmarks for that.
Oh, I see. As far as I’ve already tested, the UserEvent is not sent over ARI. At least I don’t see it in my client.
I will implement a connection to use AMI instead.
Thanks for your quick response !