11 Mar
2004
11 Mar
'04
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