Total Bandwidth per call

Mr BigMr Big Member Posts: 47 ■■□□□□□□□□

I was monitoring a conference call (total of 3 phones) and was trying to figure out how much consumption it used on our bandwidth. Question - isn't the bandwidth consumption per caller for a G.711 75 - 85K per caller per phone? Wouldn't that be a total consumption of 250K? I was monitoring it and it showed a peak consumption of 75K total.



  • Mr BigMr Big Member Posts: 47 ■■□□□□□□□□
    Common 44 views and no one knows?
  • mikej412mikej412 Member Posts: 10,086 ■■■■■■■■■■
    Is voice activity detection enabled?
    With circuit-switched voice networks, all voice calls use 64 Kbps fixed-bandwidth links regardless of how much of the conversation is speech and how much is silence. With VoIP networks, all conversation and silence is packetized. Using Voice Activity Detection (VAD), packets of silence can be suppressed.

    You could always get everyone to talk at once and see what happens.
    :mike: Cisco Certifications -- Collect the Entire Set!
  • sexion8sexion8 Member Posts: 242
    mikej412 wrote:
    Is voice activity detection enabled?


    You could always get everyone to talk at once and see what happens.

    Note: This is a real world scenario, not a test question based answer... The metrics I use when building out production systems is to use the highest numbers available period. e.g. Right now I have a client with about 40 phones, its a mixture of 729 and 711 on the network. When we spec'd out their machine, my math was 40phones x 64kbps of constant traffic without shaping so I told them they'd need nothing less then two t1's irrespective of the fact they didn't expect everyone to be on the phone at the same time. I ran a network analyzer for about a week to get traffic patterns for shaping, to get a better understanding of what was going on, and found they had two old school printers saturating their network with broadcasts, so I segmented them out... AnyWHO... I'd rather use the high end number at a constant rate to have a buffer.

    You could get into VAD, CBWFQ, etc., but if it's a design question, a real world question, safer to be on the high end of things. cRTP, I've yet to use it. Might work for interoffice, but the sound quality is horrible with too much compression going on. Real world scenario, run a traffic monitor and opt for the high end. I constantly run iptraf on their machine constantly to see their usage since they have two intergrated t1's (frame relay) and have certain workers there who spend too much time surfing for garbage.
    "Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth." - Marcus Aurelius
  • Johnny 5Johnny 5 Member Posts: 24 ■□□□□□□□□□
    A G.711 call on a Frame Relay connection without IP/RTP header compression or VAD should take about 82.4 kbps. The formula I'm using for this is:

    {(64,000 / 50) + 320 + 48} * 50

    The 320 is for the IP, UDP, and RTP headers (in bits) and the 48 is for Frame Relay headers (also in bits).

    I came up with the 50 by assuming a rate of one packet every 20ms, which is the default. 64,000 is obviously the bandwidth used by G.711. For G.729, the formula is the same just use 8,000 instead :)

    So to answer the original question...if it was a conference, you'd only see one stream to each phone. Were all 3 phones on the same port?
  • Johnny 5Johnny 5 Member Posts: 24 ■□□□□□□□□□
    For Ethernet, instead use 112 bits (14 bytes) for the Layer 2 overhead and you'll come up with:

    {(64,000 / 50) + 320 + 112} * 50 = 85.6 kbps

    For an IPSec VPN, overhead is roughly 4X as much (estimate 480 bits). So you get:

    {(64,000 / 50) + 320 + 480} * 50 = 100.4 kbps

    If you've enabled IP/RTP header compression the overhead goes from 320 bits to 16-32 bits. This doesn't make a huge difference with G.711, but with G.729 the bandwidth savings are quite significant (as much as over 50%)

    G.729 on Frame Relay without IP/RTP header compression:

    {(8,000 / 50) + 320 + 48} * 50 = 26.4 kbps

    Same but with IP/RTP header compression:

    {(8,000 / 50) + 32 + 48} * 50 = 12.0 kbps
Sign In or Register to comment.