|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: estimating VoIP data traffic size from VoIP signaling trafficsize ?
As mentioned in prior responses to this thread: there are several ways to guess, but mostly the answer is "No, not easily." The good news is that excepting proprietary protocols like Skype and efficient trunking protocols like IAX2, RTP is standardized. This means one VoIP protocol is pretty similar to the other as far as RTP size goes, so at least that part of the equation isn't open-ended. (I'll assume you're looking for end-user statistics, and not inter-nodal statistics where some type of aggregated IP header compression or trunking might make flows more IP-header-friendly.)Hi, is there any statistics on aggregated VoIP signaling bandwidth and aggregated VoIP data bandwidth? eg. if we monitored there is 2Mbps(average) traffic on VoIP signaling protocol ports ( including SIP, H.323, MGCP), how could we estimate average VoIP data bandwidth? Joe Looking just at protocols that use RTP, it's still not quite possible to map RTP volume simply from signalling volume without opening up the signalling to see what codec is being used. If you have a mix of codecs, then your bitstreams for the RTP can range from (typically) ~24kbps for G.729 up to ~80kbps for G.711 (1). Each call can be different, depending on the ability of the originating and terminating gateway/useragent to accept or prefer each codec during the call set-up. You'd need a clear understanding of what codecs your user community was utilizing in order to build an assumption table on number of streams using each codec and/or protocol. The media stats in SIP BYE signalling Bill Woodcock mentioned in his message (jitter, packets, loss, latency, etc.) are only available in a few end devices at the moment, notably Cisco. The RTCP XR (RFC3611) standards might be visible in signalling soon via SIP NOTIFY messages (2), but I don't know of any equipment that supports this right now. I think the best way to do this would be to graph the signalling volumes and the media volumes over a week or two, and then build assumption charts for future use. It may not be a big win if the effort to measure signalling is the same as the effort to measure the media, since you have to sample at a point(s) where all this data crosses your measurement instrumentation. If you're really a masochist, or you can't see the media for architecture reasons, you could write an extension to tethereal or ettercap or a similar network monitoring and packet analysis tool which unfolded each signalling message, extracted the codec descriptors, and calculated flows. You'd then have to keep state on each call, etc. etc. etc. - not simple, but not impossible. Lastly, I'm betting there are some signalling analysis tools on the market that already do this, but I would expect that they will not be cheap. If you're looking at traffic generated by Skype or other closed-protocol system, you're really hanging out in the wind but I'm sure that can be averaged and extrapolated if you have access to a number of media streams from your user population to examine. (Does Skype use extensively variable bitrates depending on endpoint capabilities?) JT (1) http://www.erlang.com/calculator/lipb/ (note: RTP for SIP and H323 is identical) http://www.voxgratia.org/docs/codecbw.html Take all media flow estimates with a grain of salt; typically numbers are higher than reported, like G.711 being just shy of 90kbps instead of 80kbps as noted in most charts. (2) http://www.ietf.org/internet-drafts/draft-johnston-sipping-rtcp-summary-08.txt
|