11 Mar
2004
11 Mar
'04
7:53 a.m.
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
11 Mar
11 Mar
8:05 a.m.
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
8:18 a.m.
On Mar 11, 2004 at 09:05, Nils Ohlmeier <nils(a)iptel.org> wrote:
Hello,
On Thursday 11 March 2004 08:53, Alex Bligh 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.
On gigabit you can send 120Mb/s over udp (athlon 2000+).
Andrei
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.
8:30 a.m.
On Thursday 11 March 2004 09:18, Andrei Pelinescu-Onciul wrote:
On Mar 11, 2004 at 09:05, Nils Ohlmeier
<nils(a)iptel.org> wrote:
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
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+).
8:41 a.m.
On Mar 11, 2004 at 09:30, Nils Ohlmeier <nils(a)iptel.org> wrote:
On Thursday 11 March 2004 09:18, Andrei
Pelinescu-Onciul wrote:
Packet loss and jitter are quite easy to find with rtp streams. They
will have only a minor performance impact.
On Mar 11, 2004 at 09:05, Nils Ohlmeier
<nils(a)iptel.org> wrote:
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 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+). 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
8:33 a.m.
--On 11 March 2004 09:18 +0100 Andrei Pelinescu-Onciul
<pelinescu-onciul(a)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
8:12 a.m.
On Mar 11, 2004 at 07:53, Alex Bligh <alex(a)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
7619
days inactive
7619
days old
6 comments
3 participants
participants (3)
-
Alex Bligh -
Andrei Pelinescu-Onciul -
Nils Ohlmeier