Before I reinvent the wheel and go write it, is there a utility which will simulate making & receiving calls (i.e. SIP conversations, **plus RTP**) in scale (to answer a question like "will my SIP+RTPproxy deployment scale for {100,1000,10000,100000} users using the following parameters for average call duration, % phones in use etc."
If not, anyone have any recommendations for a (free) stack that does a decent UAC/UAS job, including audio, and will run without GUI?
Alex
Hello,
On Thursday 11 March 2004 08:53, Alex Bligh wrote:
Before I reinvent the wheel and go write it, is there a utility which will simulate making & receiving calls (i.e. SIP conversations, **plus RTP**) in scale (to answer a question like "will my SIP+RTPproxy deployment scale for {100,1000,10000,100000} users using the following parameters for average call duration, % phones in use etc."
there are definitely call simulators with audio/RTP simulation available on the market. At least they were present at the last SIPit.
If not, anyone have any recommendations for a (free) stack that does a decent UAC/UAS job, including audio, and will run without GUI?
The tools mentioned above are for sure not freely available.
And if you plan to develope such a tool: keep in mind what will reach its bottleneck first the tester or the tested device. RTP simulation with the numbers you are looking for is probably only possible with specialist hardware and not with normal PC (at least these guys at SIPit had special hardware boxes for these tests and i guess they know why). I guess that a normal PC will reach its own limits at 1000 or at least at 10000 simultaneous RTP calls, maybe even earlier.
Greetings Nils
On Mar 11, 2004 at 09:05, Nils Ohlmeier nils@iptel.org wrote:
Hello,
On Thursday 11 March 2004 08:53, Alex Bligh wrote:
Before I reinvent the wheel and go write it, is there a utility which will simulate making & receiving calls (i.e. SIP conversations, **plus RTP**) in scale (to answer a question like "will my SIP+RTPproxy deployment scale for {100,1000,10000,100000} users using the following parameters for average call duration, % phones in use etc."
there are definitely call simulators with audio/RTP simulation available on the market. At least they were present at the last SIPit.
If not, anyone have any recommendations for a (free) stack that does a decent UAC/UAS job, including audio, and will run without GUI?
The tools mentioned above are for sure not freely available.
And if you plan to develope such a tool: keep in mind what will reach its bottleneck first the tester or the tested device. RTP simulation with the numbers you are looking for is probably only possible with specialist hardware and not with normal PC (at least these guys at SIPit had special hardware boxes for these tests and i guess they know why). I guess that a normal PC will reach its own limits at 1000 or at least at 10000 simultaneous RTP calls, maybe even earlier.
Depends on the codec and network you use. 10000 gsm would be easy. You also don't need to encode some valid stuff, you generate on packet and just slightly modify it before sending. On gigabit you can send 120Mb/s over udp (athlon 2000+).
Andrei
On Thursday 11 March 2004 09:18, Andrei Pelinescu-Onciul wrote:
On Mar 11, 2004 at 09:05, Nils Ohlmeier nils@iptel.org wrote:
And if you plan to develope such a tool: keep in mind what will reach its bottleneck first the tester or the tested device. RTP simulation with the numbers you are looking for is probably only possible with specialist hardware and not with normal PC (at least these guys at SIPit had special hardware boxes for these tests and i guess they know why). I guess that a normal PC will reach its own limits at 1000 or at least at 10000 simultaneous RTP calls, maybe even earlier.
Depends on the codec and network you use. 10000 gsm would be easy. You also don't need to encode some valid stuff, you generate on packet and just slightly modify it before sending. On gigabit you can send 120Mb/s over udp (athlon 2000+).
Ok i was not speaking about just blowing out packets, but also compare what did you received. AFAIK these commercial tools also provide some statistics about the sound quality (packet loss rate etc.). And on the other side i do not consider gigabit as normal, because this is only realistic in a local environment but not for a public server (naturally you can put a gigabit card into your server, but a gigabit uplink just for your server is a little bit unrealistic today, or?)
Nils
On Mar 11, 2004 at 09:30, Nils Ohlmeier nils@iptel.org wrote:
On Thursday 11 March 2004 09:18, Andrei Pelinescu-Onciul wrote:
On Mar 11, 2004 at 09:05, Nils Ohlmeier nils@iptel.org wrote:
And if you plan to develope such a tool: keep in mind what will reach its bottleneck first the tester or the tested device. RTP simulation with the numbers you are looking for is probably only possible with specialist hardware and not with normal PC (at least these guys at SIPit had special hardware boxes for these tests and i guess they know why). I guess that a normal PC will reach its own limits at 1000 or at least at 10000 simultaneous RTP calls, maybe even earlier.
Depends on the codec and network you use. 10000 gsm would be easy. You also don't need to encode some valid stuff, you generate on packet and just slightly modify it before sending. On gigabit you can send 120Mb/s over udp (athlon 2000+).
Ok i was not speaking about just blowing out packets, but also compare what did you received. AFAIK these commercial tools also provide some statistics about the sound quality (packet loss rate etc.).
Packet loss and jitter are quite easy to find with rtp streams. They will have only a minor performance impact.
And on the other side i do not consider gigabit as normal, because this is only realistic in a local environment but not for a public server (naturally you can put a gigabit card into your server, but a gigabit uplink just for your server is a little bit unrealistic today, or?)
Well, yes you are right, but if you want to measure the speed you will need a gigabit network. If you don't use gigabit 10000 calls will exceed your bandwidth ( in the rtpproxy case you need 2*bandwidth so for 10000 calls at 1k/s => 20Mb/s => 160 megabits/s, more than fasteth). In normal scenarios, with normal internet connections you won't be able to have more them 1000 simultaneous calls due to bandwidth limitations (and this without bandwidth hungry codecs).
Andrei
--On 11 March 2004 09:18 +0100 Andrei Pelinescu-Onciul pelinescu-onciul@fokus.fraunhofer.de wrote:
Depends on the codec and network you use. 10000 gsm would be easy. You also don't need to encode some valid stuff, you generate on packet and just slightly modify it before sending.
Yep I planned to build an audio stream ONCE (on initialisation) into a list of packets, and just blat them out each time getting the spacing roughly right, rather than use any CODEC on the test device. And I will dump the inbound audio stream beyond checking I've got it. I'm trying to test the stuff actually arrives with the right IP addresses etc., rather than test audio quality or transcoding etc.
Alex
On Mar 11, 2004 at 07:53, Alex Bligh alex@alex.org.uk wrote:
Before I reinvent the wheel and go write it, is there a utility which will simulate making & receiving calls (i.e. SIP conversations, **plus RTP**) in scale (to answer a question like "will my SIP+RTPproxy deployment scale for {100,1000,10000,100000} users using the following parameters for average call duration, % phones in use etc."
No, at least not a free one. It will be really great to have one.
If not, anyone have any recommendations for a (free) stack that does a decent UAC/UAS job, including audio, and will run without GUI?
Be carefull when you choose a stack. It must be fast, or the bottleneck will be your testing tool. We had a few surprises with ser, which is faster in general than the testing tools on the same hardware.
In the rtpproxy case the bottleneck would be the number of nathelper commands it can process and not forwarding of the rtp traffic. I did a simple test on a gigabit interface and rtpproxy was able to forward 60Mb/s on an Athlon 2000+. This was on a single session, having a lot of simultaneous sessions will decrease its forwarding capability (lots of time spent in pool), but I still don't think this will be the bottleneck.
Andrei
-
Alex Bligh -
Andrei Pelinescu-Onciul -
Nils Ohlmeier