[WXC/VFX] How much bandwidth does VFX use?

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [WXC/VFX] How much bandwidth does VFX use?

brianthomas

31 posts

Geek

#18980 31-Jan-2008 17:40

I have seen reports of about 32kbps mentioned in other places but I googled for the codec it uses and its supposed to only use 8-9kbps is that right?

sbiddle

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#107812 31-Jan-2008 17:47

G.729 uses around 8kbps bitrate for the encoding in each direction. You also have to factor in TCP/IP overhead into this which will vary slightly depending on the packet size (which is typically around 20ms -30ms for most codecs). This gives a total of around 31.2 kbps in total in each direction so you're looking at kust on 64kbps for a phonecall.

If you use G.711a or G.711u you're looking at 64kbps + overheads which is around 87kbps in each direction.

AliExpress

Shop now on AliExpress (affiliate link).

Fraktul

836 posts

Ultimate Geek

Trusted

#107816 31-Jan-2008 18:36

Short answer:
Depends on your setup and where you measure.

Long answer:
Codec selection, sample size, samples per frame, VAD, if parties are talking or not if VAD is enabled. equiv OSI layers 1-4 utilised, redundent transmission, point in the network you are measuring amongst other factors all play a part.

For example Steve says approx 31.2kbps one way utilisation, if you measuing that on your lan though you need to factor in Ethernet overheads which bring this up closer to 39kbps. However those Ethernet overheads go away once this is transmitted over your ADSL connection and are replaced by a whole new set of overheads, PPP and ATM.. and there are a new set over overheads again once you leave the DSLAM/ASAM/ISAM etc.

hpj2007

117 posts

Master Geek
Inactive user

#109619 10-Feb-2008 11:33

Thought this might be interesting to the original poster and others, got this during a VFX call when nothing else was using the internet. Looks like upstream is steady at around 30kbps and downstream varies continuously.

Niel

3267 posts

Uber Geek

Trusted

#109631 10-Feb-2008 12:56

Makes sense. At the point where you are measuring your device has no issues sending data to the server but receiving data has to come through the internet with varying latency etc. Good to actually see the graph, nice. What is the time scale on the graph? Was it an incoming or outgoing call? Was it between 2 VFX numbers or was one POTS or mobile?

Does anyone know if the VFX server does any further compression, as in the ATA only digitize for outgoing but decompress for incoming while the server does the outgoing compression, or does the ATA also perform the compression and the server simply route the data and manage QoS? If it is the former, then that explains why the average incoming data is less than the average outgoing data nad would also make the ATA cheaper as typically it cost more for a compression license than for a decompression license. Just wondering (and it relates to the topic).

You can never have enough Volvos!

hpj2007

117 posts

Master Geek
Inactive user

#109638 10-Feb-2008 13:30

Timescale from the start of the data flow to the end of the graph is a bit less than 8 minutes. The vertical axis line on the left of the point where data starts is 8 minutes from the end of the graph.

It was an outgoing call to Australia most likely not VOIP.

grant_k

3539 posts

Uber Geek

Trusted

#109649 10-Feb-2008 13:57

hpj2007: Timescale from the start of the data flow to the end of the graph is a bit less than 8 minutes. The vertical axis line on the left of the point where data starts is 8 minutes from the end of the graph.

It looks to me as though you would have been doing most of the talking for the last 2 minutes of the call. Each upwards blip is when the called party responds. Note especially the upward blip right at the end when the called party would have said goodbye. The VFX server was probably doing Silence Suppression on the incoming audio, hence the downwards track for most of the last 2 minutes of the call, when the called party was mostly listening.

That's my take on it anyway

It's interesting to see the graphs; thanks for posting them.