estimating VoIP data traffic size from VoIP signaling traffic size ?

Sun Oct 23 18:26:30 UTC 2005

>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

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.)

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