[86110] in North American Network Operators' Group
Re: estimating VoIP data traffic size from VoIP signaling traffic size ?
daemon@ATHENA.MIT.EDU (Blaine Christian)
Sun Oct 23 21:28:24 2005
In-Reply-To: <20051023114819.GA63598@puck.nether.net>
Cc: Joe Shen <joe_hznm@yahoo.com.sg>, NANGO <nanog@merit.edu>
From: Blaine Christian <blaine@blaines.net>
Date: Sun, 23 Oct 2005 21:28:03 -0400
To: Jared Mauch <jared@puck.nether.net>
Errors-To: owner-nanog@merit.edu
>>
>> Use about 100k per call for 711u and it will help make the numbers
>>
>
> actually around 88.2k.
>
>
I did say round you know! Lol... Things like VAD would drop the
numbers even lower for G.711.
>> nice and round.
>> If you are trying to calculate busy hour search for
>> Erlang on your nearest web confabulator. There are also innumerable
>> spots on the web where you can find typical numbers for various
>> codecs.
>>
>
> I'd like to suggest to people looking at these things to
> insure that your stats toolset includes both bps and pps in the
> polls. SYNs are low bps rate, but a high pps rate of them can mean
> something bad.. it's useful to know how fast these counters are
> incrementing.
Agree with you on that one... PPS is commonly overlooked. Folks are
so interested in those bits per second they sometimes miss the
obvious. From the VoIP perspective it would also be helpful to keep
track of your signaling to RTP traffic ratio. If you find that your
signaling demands have increased dramatically compared to your RTP
traffic you may have "other" problems to worry about besides
maintaining link capacity. If you find that your RTP traffic has
suddenly increased it is certainly a potential worry factor as well.
I just finished dealing with a mysterious sudden growth in RTP
traffic. The bad part was that it caused initial happiness (the
money dance) followed by "oh crap we have a bug" a couple days
later. Incomplete signaling can bite you pretty hard when DSPs don't
know they are supposed to hang up.
