Table of Contents
There are few configuration settings to tweak to reduce the CPU usage of the application or to produce the best performance out of pjsip:
The software AEC probably is the most CPU intensive
module in PJSIP. To reduce the CPU usage, shorten the EC tail length to
lower value (the
pjsua_media_config::ec_tail_len setting), or even
disable it altogether by setting it to zero.
Use low complexity codecs such as pcmu or pcma. When using
pcmu or pcma, make sure pjmedia chooses the table based
implementation, by setting
PJMEDIA_HAS_ALAW_ULAW_TABLE macro to 1
(this is default).
Resampling is a CPU intensive process, thus it should be avoided, by choosing uniform clock rate for all media components (sound device, conference bridge, codecs, WAV files, etc.).
Make sure that PJSUA-LIB selects the most effective sampling rate/clock rate for the
application. For example, if the application only supports narrowband
codecs (G.711, GSM, iLBC, G.723, or G.729), then the best sampling rate
to choose would be 8KHz. Choosing higher sampling rate will only just
waste CPU power due to resampling and more processing in general.
With pjsua, sampling rate can be forced with
option. In the application, this can be achieved by setting
If conferencing feature is not needed, replace the conference bridge with the
that is lighter and has less latency. To use the audio switchboard,
PJMEDIA_CONF_USE_SWITCH_BOARD to non-zero in config_site.h.
See Audio Switchboard for more
Speeding up logging can be achieved in two ways.
First is to make sure that the log writer callback function that is registered to PJLIB logging
writes the log as quick as possible. The default log writer callback is to print the log
to stdout, hence the performance depends on the performance of the terminal.
Application can supply its own log writer callback by calling
pj_log_set_log_func() function. The callback can control what gets
written by filtering the log level of the message.
The second way is to control what gets written to the log in the first place, by setting
the logging (verbosity) level, which ranges from 1 (fatal error) to 5 (verbose debug).
The default logging level is 5 to provide verbose information to assist
debugging. Logging level can be changed at run-time with
When absolute performance is needed, application can disable, at compile time, all logging calls
with verbosity greater than certain limit by setting
PJ_LOG_MAX_LEVEL macro to the desired level in config_site.h.
Use the optimum number of SIP worker threads in the application. The optimum number would be equal to the number of processors (or processor cores) in the system.
The libraries are equipped with run-time checks to prevent bad parameters from crashing the
software. This feature can be disabled by setting
PJ_ENABLE_EXTRA_CHECK to 0.
PJLIB is equipped with stack overflow detection. This feature can be disabled by
PJ_OS_HAS_CHECK_STACK to 0.
PJSIP is equipped with mutex protection to protect PJSIP modules from being
unregistered while they are still being accessed by PJSIP. If the
application doesn’t add/remove modules dynamically during run-time, you
can disable this protection by setting
PJSIP_SAFE_MODULE to 0.
By default, PJSIP will make a copy of escaped
message sequence before unescaping it. You can configure PJSIP to
unescape in-place by setting
PJSIP_UNESCAPE_IN_PLACE to 1. Note
that unescaping in place will modify the original message, so don’t do
this if the application needs to access the original message after it
has been parsed (pjsip does not need this access).
PJ_HASH_USE_OWN_TOLOWER to one, the hash
function will convert the key to lower case and calculate the hash value
in one loop.
Don’t forget to set the appropriate compiler optimization flag, and disable
There are few settings to tweak:
First apply the CPU reduction techniques above to maximize the performance.
Do not use PJSUA-LIB. PJSUA-LIB is designed for building client application.
By default, PJSIP is configured to handle only limited simultaneous SIP transactions and dialogs. This can be enlarged according to the requirement, by setting both
PJSIP_MAX_DIALOG_COUNTto the appropriate values (for example,
If large number of TCP/TLS connections are needed, increase
PJ_IOQUEUE_MAX_HANDLESto some large number (the default is only 64).
We’ve found that the simple GUID generator (used by GNU build system for *nix and MacOS X) will produce duplicate Id after approximately 2^14 generations. This would cause things like transactions to have duplicated branch as previous transactions! On Linux, the
./configurescript will detect the presence of
libuuid(part of e2fsprogs) and use it if available, to avoid this problem. If you encounter this problem, please check if
libuuidis available for
./configureon your system.
If you are using PJSUA-LIB, then the maximum number of calls supported is
pjsua_config::max_calls (default is 4). When
increasing the limit, compile time options
PJ_IOQUEUE_MAX_HANDLES also needs to be changed accordingly (set the
later to approximately 3 times
More info can be found here.