Hardware and concurrent limit

[terry]

1. Brekeke Product Name and version

2. Java version:

3. OS type and the version:Linux centos4.4

4. UA (phone), gateway or other hardware/software involved:

5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/networkpatterns.html :

6. Your problem:
Dear sir,
I am happy and used your sip proxy
I have 3 question as below
1 Now i will buy a new server for sip proxy ,But i am confuse about which one is better?do u have suggestion spec.?one is 2 Quad-Core 5310 1.6G X2 1066FSB (8M L2)/ 2GB ECC / Reg DDRII 667 FBDIMM / second is Xeon 3.0X2 cpu with 2G RAM
My server supplierasking me .do sip serevr need a lots calculation on CPU loading ?


2 Can u give me your suggestion spec for sip proxy, if i need 500 concurrect calls
3 RTP port is from 10000-10999 ,is it mean we can only have 250 concurrent calls?each call is used 4 ports?right ?
Can i change here bigger ,if i need 500 concurrect calls and behind NAT ?If my server performance is good and have enough bandwidth
Thanks
Terry

[Ahmed]

Hi terry !
I am also searching for such kind of infos: I am eagerly wanting to know about performance of BSS, so we can scale the hardware or even acts upon some params like the limit of a/v sessions if any !

[terry]

Hi,
all my friends,Thanks your full agree with me.
But unfortunately,offical Brekeke cannot give us good feedback
If i want running 500 NAT currect calls ,,what server spec. should I prepaired?I holp Brekeke can help us ,Thanks


Terry

[Ahmed]

terry, let's try to find a simulation tool, ie search for a program that can simulate the simultaneous access of multiple UAs to BSS.
And if one finds something then let it be shared with us all.

[terry]

Dear sir,
Have any official information can share ?
what the spec . of hardware can running 500 concurrent calls on sip server ?
Terry

[Peely]

I can't give you any official figures, but can give you some guidance to general capacity and what we experience.

Each concurrent dialogue uses one thread for the dialogue, then another thread for each port opened for media relay. This means you can expect five threads to be spawned for each call if you are relaying both RTP and RTCP. If you disable RTCP then you can save two threads per NATted call (net.rtcp.use=false in sv.properties). For REGISTER dialogues, Brekeke does not keep a thread for each long running dialogue, only the REGISTER > 401 > REGISTER > 200 cycle.

Each thread uses a certain amount of heap and an amount of CPU for context switching, so memory is as important as CPU.

Generally, on a dual quadcore Xeon machine with 4gb RAM we warrant the support of 100k concurrent registrations with 3600s expiry, 3,500 simultaneous non-natted calls and 400 media routed sessions. You may well find that your 500 user limit is easily achievable however, providing you can switch off RTCP. With shared databases (we use our own plugin but this can be achieved easily using the standard Brekeke options) you can simply add more proxies to scale out, maybe you want to consider this?

If you expect to take a lot of traffic, I would start applying some maximum call timers, as if you don't hairpin the media through the proxy then you'll have the possibility to keep calls up on the proxy indefinitely if both ends just switch off their UA mid-call.

If you're looking for some adequate test software, try Touchstone WinSIP, it's not the most stable software but does a good job at hammering SIP Servers and can support large numbers of registrations / calls.

Hope this helps.



Neil.

[Peely]

Another note, when you are relaying media, consider that the type of media and packet size really matters. You may want to decline media that is G.711 or only allow G.729 / iLBC. You can use &net.rtp.audio.payloadtype in a deploy pattern to force a specific codec.

If you do need to allow G.711, I don't know of a dial-plan rule which allows you to specify the ptime, but it would be worth ensuring somehow that you only accept ptime>= 20.

Regards,



Neil.

[terry]

Dear friends,
Thanks your information .
Terry