[Kamailio-Users] Question regarding kamailio transaction processing.

Siddhardha Garige siddu999 at yahoo.com
Wed May 27 16:57:08 CEST 2009


Hi all,





I have a question regarding kamailio transaction processing.
Any help is greatly appreciated.

We are load testing kamailio using SIPP tool. Kamailio is
working in outbound proxy mode and routing SIP messages in-between SIPP servers.
SIPP generates REGISTER requests and SIP calls.

Registration load is 100 registrations per second. A steady
stream of registration requests are generated throughout the test duration.

Call load is 100 calls per second with average call duration
of 3.5mins with a max load of 10,000 concurrent calls. SIPP starts with a call
rate of 100 call/sec and makes 10,000 concurrent calls. Calls terminate at
3.5mins and SIPP will make new calls to maintain 10,000 concurrent call load.

We monitored kamailio transactions using “kamctl moni” for
current transaction in use. If kamailio has more than 1000 standing transaction
in memory, we notice REGISTRATION retransmissions. Kamailio takes more than
300ms to process some registration requests. However requests related to call
transactions are not affected. No INVITE or 200OK retransmissions were noticed
in this process. By decreased call load to 10 call/second and registration
retransmissions reduced considerably. Again by increased call load to 100
call/sec and we started noticing REGISTER retransmissions. 

Here is our question. If number of transactions in kamailio memory
contributes to processing delay should not it affect both REGISTRATION and CALL
transactions equally? Why only REGISTRATION are getting affected while calls
are fine without any retransmissions. 

Is kamailio prioritizing processing call transactions over
REGISTRATION transactions? Can someone throw some light on this please?

-Sid



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20090527/edb6be62/attachment.htm>


More information about the sr-users mailing list