[sr-dev] Kamailio vs RTPEngine Performance

[M S]

Hi,

I was asked some interesting questions yesterday by a rather techy client
related to Kamailio and RTPEngine performance.

Q1:
For Kamailio we have say 8 child processes, which means there are 8 threads
per listen address to process sip messages, i.e. for example 8 INVITE
messages at any instance of time can be processed by Kamailio. If say, one
INVITE takes 200ms to be processed and send out to destination, then we can
estimate processing power of kamailio to be 40 INVITE requests per second
per listen address, right?

Q2:
If so, then assuming each INVITE requires to engage RTPEngine. How can we
ensure that RTPEngine would be capable to handle these 40 INVITE requests?
The only relevant parameter I see in RTPEngine daemon script is
"NUM_THREADS" (default value 5). What does this represent? Does this
analogs to children as in Kamailio?

Q3:
How does RTPEngine manages SRTP <=> RTP translation (e.g. if one endpoint
is WebRTC and other is traditional SIP)? My understanding is that RTPEngine
has a kernel module (assuming kernel module is installed) which also
manages this conversion besides forwarding the media packets. The Linux
kernel already has encoders / decoders for nearly all encryption algorithms
which are utilized by RTPEngine for doing the conversion in kernel space,
right? if not then how it is done?

Q4:
Continuing to Q2, If these NUM_THREADS process actual media packets (RTP or
SRTP) then are these synchronous or asynchronous? I think these are
asynchronous, just want to confirm (otherwise RTPEngine won't process more
then e.g. 5 calls at a time). So, assuming asynchronous how many packets
can be queue to each thread? This would help estimating RTPEngine
throughput using various codecs in calls. (e.g. assuming G.711 codec we
have 50pps, if each thread queue size is 1000 then each thread can process
1000/50=20 concurrent calls and whole RTPEngine would process 20x5=100
concurrent calls).

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20151013/906b27cd/attachment-0001.html>