[SR-Users] Dimension a kamailio server
rizkhan at gmail.com
Tue Apr 1 09:12:10 CEST 2014
Thanks a lot Pedro.
Just one question? Do we have module for Mongodb? how do i use it?
On Mon, Mar 31, 2014 at 5:52 AM, Pedro Niño <nino.pedro at gmail.com> wrote:
> As Alex said, I/O and calls per second (CPS) is Dependant on what type of
> design you are using.
> As a tip, mysql is good for small to medium sizes, but begin to choke at
> 1000 of concurrent connections. but in a scalable size like you are
> planning, I would recommend to make a design with resilience and high
> availability, with mongodb or postgres as db back end.
> There are some good examples on internet about enabling multiple kamailio
> server with high availability configuration, using heartbeat and some other
> A nice design would be:
> 2 or more kamailio servers, maybe virtual or physical, with high
> availability configuration (if one goes down, the other takes all the load)
> 2 or more DB servers, also with high availability design.
> At least 10G connection, server and switch (for the call flow you're
> expecting) remember to make estimation for calls established, and codec
> used, (using g711, rtp audio might come up to 80kbps, so like 120.000 calls
> is the top for a 10G connection)
> Also separate vlan for calls and server control, too.
> Just my 2 cents
> El mar 28, 2014 11:58 AM, "Rizwan Khan" <rizkhan at gmail.com> escribió:
> Thanks Alex.
>> What are the components that I should take into account. Based on answer
>> in another thread I will be using SIP trunk with an NGN to route the
>> outside traffic (other than SIP-SIP).
>> I'll have NATed clients so I'll need the media proxy or rtp proxy as
>> well. What about their dimensioning? I am sorry if some questions are
>> really naive. I am new to all this and trying to get hold of the whole
>> technology stack.
>> On Mar 28, 2014 3:41 PM, "Alex Balashov" <abalashov at evaristesys.com>
>>> 1. Kamailio does not handle RTP, so audio is not a scaling factor at all;
>>> 2. The only scaling factors are transactional memory (TM) and any dialog
>>> state you are keeping;
>>> 3. Without I/O wait from external sources, Kamailio can handle a
>>> practically infinite amount of concurrent calls and CPS. But, most
>>> practical applications of Kamailio require database backing;
>>> 4. Therefore, performance and throughput will depend almost entirely on
>>> the database you are using for database backing, and any tuning on its
>>> settings. This certainly includes the CDRs and storage, and getting the
>>> most performance out of your database is outside the domain of your
>>> question (or this list);
>>> 5. A quad-core host with 8 GB of RAM should be more than sufficient for
>>> Kamailio itself to meet your needs. But most of the answers to your
>>> question don't have much to do with Kamailio.
>>> -- Alex
>>> On 03/28/2014 06:36 AM, Rizwan Khan wrote:
>>> HI Guys,
>>>> can you refer me to some resources which help me dimension the hardware
>>>> for a setup.
>>>> Total users will be 20,000. What percentage should i assume for
>>>> concurrent audio and video calls? What is the standard practice? How
>>>> does this all map to the cpu, ram and storage etc. given that I will be
>>>> storing the cdrs as well.
>>>> In the futute this setup should be scalable so that it should support
>>>> 200,000+ users within a span of 6-8 months. What would be the ideal
>>>> Rizwan Khan
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>> Alex Balashov - Principal
>>> Evariste Systems LLC
>>> 235 E Ponce de Leon Ave
>>> Suite 106
>>> Decatur, GA 30030
>>> United States
>>> Tel: +1-678-954-0670
>>> Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users at lists.sip-router.org
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users