pjproject 2.6 now qualified for use with Asterisk!

pjproject 2.6 now qualified for use with Asterisk!

This week, we’re pleased to say that we’ve updated the Asterisk 13, 14 and master branches’ bundled version of pjproject to 2.6.

Here’s a short recap of the steps we took to get here:

  • All of the the patches we were applying to 2.5.5 were verified to be in 2.6.
  • We looked for any other functional or API changes that might affect how Asterisk uses pjproject.
    • We found 1 minor improvement in how memory pools are released.  This resulted in 3 minor code tweaks that are backwards compatible.
  • We tested the build process looking for issues that might change how Asterisk compiles and links pjproject.
    • We found an issue with WebRTC…  In this release, pjproject now includes a WebRTC implementation in its third-party directory which we had to disable.  These were all minor updates but required to get pjproject to build successfully and they do not affect Asterisk’s ability to process WebRTC calls.
      • One of pjproject’s configure options was changed from ‘–disable-webrtc’ to ‘–without-external-webrtc’
      • The build of WebRTC was removed from the Makefile
      • A #define was added to config_site.h to prevent pjmedia from requiring WebRTC.
  • We ran the Asterisk Testsuite a few dozen times to make sure the functional tests still passed.
  • Finally, for the first time, we were able to run stress tests to look for any new performance or stability issues that might have crept in.  We didn’t find any.

Of course we could have missed something, which is why it’s important for the community to test for themselves.  If you’re using the bundled version of pjproject, and you should be :), checkout the Asterisk 13 or 14 branch and test it in your environment.  If you build pjproject yourself, you can try it with recent Asterisk releases.

For more information related to Astrerisk’s use of pjproject, visit Building and Installing pjproject on the Asterisk Wiki.

2 Responses

  1. can you share info about the stress tests? how many calls? which metrics was monitored?

  2. Each test cycle was 800 registers, 400 7 minute calls starting at 1 sec intervals, 800 unregisters.

    We measured CPU and memory from a system perspective and the time-to-originate, time-to-answer and jitter from a call perspective. Jitter doesn’t matter much in this case since we don’t use pjproject for audio but it’s a good indication of how the system is performing overall. The goal for this test was really to compare pjproject 2.6 to 2.5.5 to make sure we at least didn’t go backwards in terms of resource utilization or stability.

    We’re in the process of acquiring hardware specifically to do more performance/stress/stability testing in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.

About the Author

What can we help you find?