Batch requests support for OpenSER v1.3.2
The performance of SIP proxies is critical for the robust operation of many applications. However, the use of even light-weight authentication schemes (i.e., digest authentication) can significantly degrade throughput in these systems. In particular, systems in which multiple proxies share a remote authentication database can experience reduced performance due to network latency.
In our study  we investigate how the application of parallel execution and batch requests can be used to maximize call throughput while carefully balancing demands for bandwidth and call failure rates
The basic idea behind batch requests is to avoid individual requests to the remote database. Instead, requests are temporarily stored at the proxy and sent together as one multi-condition request. Using this approach, we can reduce the impact of the latency and bandwidth overhead associated with individual requests.
OpenSER v1.3.2 (now known as OpenSIPS) was the SIP proxy used in our experiments. OpenSER supports parallel execution (multiple children processes) by default, however, it does not support batch requests. Therefore, it was necessary to modify OpenSER to add this mechanism. The changes required for this purpose are available below in the form of a software patch for OpenSER v1.3.2. We also include the instructions on how to apply the patch and test the batch requests mechanism.
It is important to notice that this is an experimental code and it is not intended for production environments. The batch request mechanism only support SIP INVITE message authentication. Finally, the code has been tested with OpenSER 1.3.2 only and it may not work with later versions of OpenSER or OpenSIPS.
To enable batch requests, you need to add the following lines to the OpenSER configuration file (openser.cfg):
where batch_size is an exported parameter of the auth_db module that defines the size of the batch request (10 in this example) and do_all() is an exported function of the auth_db module that performs all the routing logic of the SIP messages processed by the proxy (except location). The parameter realm is an opaque string that the user agent should present to the user so he can decide what username and password to use and table is the table to be used to lookup usernames and passwords (usually subscribers table). For more details see the auth_db module documentation.
Because the do_all() function performs all the call routing logic, a simplified configuration file was used in our experiments. An example of this configuration file can be downloaded here: openser.cfg
We used SIPp for generating the call load in our tests. We modified the default UAC scenario file to support digest authentication and injecting values (usernames and passwords) from a CSV file. An example of the modified UAC scenario file can be downloaded here: uac_auth.xml. Check SIPp documentation for more details about its use.
Finally, we recommend to test this modified version of OpenSER with a remote database (we used MySQL). With a local database, the batch requests do not help to improve performance (no network latency savings)
Please contact me if you have any question or comments.