Bidirectional discussion Bandwidth

[Rob]

Archived from groups: comp.dcom.voice-over-ip (More info?)

When 2 people initiate a voip conversation. Is a 64k channel for voice
created both ways.
In a 256K link would 128k be consumed?

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

"Rob" <robertmcconnell@optusnet.com.au> wrote in message
news:42131f24$0$1998$afc38c87@news.optusnet.com.au...
> When 2 people initiate a voip conversation. Is a 64k channel for voice
> created both ways.
> In a 256K link would 128k be consumed?

It would be 64k (or whatever) in each direction.

Ivor

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

In article <37gnsnF5d4ocuU1@individual.net>, ivor@despammed.invalid
says...
>
> "Rob" <robertmcconnell@optusnet.com.au> wrote in message
> news:42131f24$0$1998$afc38c87@news.optusnet.com.au...
> > When 2 people initiate a voip conversation. Is a 64k channel for voice
> > created both ways.
> > In a 256K link would 128k be consumed?
>
> It would be 64k (or whatever) in each direction.

Well..., no.

First of all, the bandwidth used is a function of the codec and protocol
involved. G.711 is nominally 64 kbps, and with overhead it works out to
about 88 kbps. High compression codecs will consume substantially less.

Second, the bandwidth used is NOT 64/88 kbps "in each direction" for an
end-point. For a switch/gateway, where both end-points of a call
traverse the pipe, your 2x math would apply.

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

"Rusty Shackleford" <DieSpammerDie@njabl.org> wrote in message
news:MPG.1c7d22e2d6a53d8f9896fa@news.comcast.giganews.com...
> In article <37gnsnF5d4ocuU1@individual.net>, ivor@despammed.invalid
> says...
>>
>> "Rob" <robertmcconnell@optusnet.com.au> wrote in message
>> news:42131f24$0$1998$afc38c87@news.optusnet.com.au...
>> > When 2 people initiate a voip conversation. Is a 64k channel for
>> > voice
>> > created both ways.
>> > In a 256K link would 128k be consumed?
>>
>> It would be 64k (or whatever) in each direction.
>
> Well..., no.
>
> First of all, the bandwidth used is a function of the codec and protocol
> involved. G.711 is nominally 64 kbps, and with overhead it works out to
> about 88 kbps. High compression codecs will consume substantially less.
>
> Second, the bandwidth used is NOT 64/88 kbps "in each direction" for an
> end-point. For a switch/gateway, where both end-points of a call
> traverse the pipe, your 2x math would apply.

Sorry, you've lost me. Speech in both directions passes down the cable
from my telephone to the ATA and through my router to the outside world,
so surely there is the same amount of data in both directions..?

Ivor

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

In article <37hgvrF5b53vpU1@individual.net>, ivor@despammed.invalid
says...
> > First of all, the bandwidth used is a function of the codec and protocol
> > involved. G.711 is nominally 64 kbps, and with overhead it works out to
> > about 88 kbps. High compression codecs will consume substantially less.
> >
> > Second, the bandwidth used is NOT 64/88 kbps "in each direction" for an
> > end-point. For a switch/gateway, where both end-points of a call
> > traverse the pipe, your 2x math would apply.
>
> Sorry, you've lost me. Speech in both directions passes down the cable
> from my telephone to the ATA and through my router to the outside world,
> so surely there is the same amount of data in both directions..?

Ignoring, for the moment, silence suppression, you are correct, and the
bandwidth figure for any given codec is the total for both sides of the
conversation. The nominal bandwidth for a G.711 call is 64 kbps, not 128
kbps.

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

Rusty Shackleford <DieSpammerDie@njabl.org> writes:
> Ignoring, for the moment, silence suppression, you are correct, and the
> bandwidth figure for any given codec is the total for both sides of the
> conversation. The nominal bandwidth for a G.711 call is 64 kbps, not 128
> kbps.

Can G.711 even use silence suppression?

What about the packet overhead for the RTP header, UDP header, IP
header and the ATM header? Isn't that going to add another 50% to
the 64kbits/sec figure?

-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Hate software patents? Sign here: http://thankpoland.info/

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

In article <x7vf8sma0t.fsf@bonnet.wsrcc.com>,
wolfgang+gnus20050216T140716@dailyplanet.dontspam.wsrcc.com says...
>
> Rusty Shackleford <DieSpammerDie@njabl.org> writes:
> > Ignoring, for the moment, silence suppression, you are correct, and the
> > bandwidth figure for any given codec is the total for both sides of the
> > conversation. The nominal bandwidth for a G.711 call is 64 kbps, not 128
> > kbps.
>
> Can G.711 even use silence suppression?

I was using G.711 as an example.
>
> What about the packet overhead for the RTP header, UDP header, IP
> header and the ATM header? Isn't that going to add another 50% to
> the 64kbits/sec figure?

Please note the word "nominal", in the text you quoted. You are quite
right that there is additional packet overhead that will drive the
actual utilization of a G.711 closer to 90 kbps. The point I was trying
to make for the OP was that it is that the nominal 64 kbps figure (or
whatever is required for a given codec) is for the entire conversation.

 

[Ian]

Archived from groups: comp.dcom.voice-over-ip (More info?)

Rusty Shackleford <DieSpammerDie@njabl.org> wrote in message news:<MPG.1c7d4f933b9aa2c49896fb@news.comcast.giganews.com>...
> In article <37hgvrF5b53vpU1@individual.net>, ivor@despammed.invalid
> says...
> > > First of all, the bandwidth used is a function of the codec and protocol
> > > involved. G.711 is nominally 64 kbps, and with overhead it works out to
> > > about 88 kbps. High compression codecs will consume substantially less.
> > >
> > > Second, the bandwidth used is NOT 64/88 kbps "in each direction" for an
> > > end-point. For a switch/gateway, where both end-points of a call
> > > traverse the pipe, your 2x math would apply.
> >
> > Sorry, you've lost me. Speech in both directions passes down the cable
> > from my telephone to the ATA and through my router to the outside world,
> > so surely there is the same amount of data in both directions..?
>
> Ignoring, for the moment, silence suppression, you are correct, and the
> bandwidth figure for any given codec is the total for both sides of the
> conversation. The nominal bandwidth for a G.711 call is 64 kbps, not 128
> kbps.

For G711 each sampled packet is 64K + approx 12K of overhead and this
is each way.. SO a conversation using full duplex will require approx
80K in each direction G729 is 8K + 12k therefore 20K in each
direction. If your router supports stats you will see this.

Ian

 

[Guest]

Archived from groups: comp.dcom.voice-over-ip (More info?)

In article <eaa2ab80.0502190204.51c715b1@posting.google.com>,
google@bathfordhill.co.uk says...

> For G711 each sampled packet is 64K + approx 12K of overhead and this
> is each way.. SO a conversation using full duplex will require approx
> 80K in each direction G729 is 8K + 12k therefore 20K in each
> direction. If your router supports stats you will see this.
>
> Ian
>

A router WOULD see such numbers, as it is handling TWO connections, one
upstream and one downstream. An END POINT (soft phone, IP Phone, etc.)
requires approximately 88 kbps for a G.711 conversation, not 196 kbps.

You can read here, for a more thorough explanation:
http://www.voip-calculator.com/bandwidth.html

 

[Ian]

Archived from groups: comp.dcom.voice-over-ip (More info?)

Rusty Shackleford <DieSpammerDie@njabl.org> wrote in message news:<MPG.1c82c157e12b32db989700@news.comcast.giganews.com>...
> In article <eaa2ab80.0502190204.51c715b1@posting.google.com>,
> google@bathfordhill.co.uk says...
>
> > For G711 each sampled packet is 64K + approx 12K of overhead and this
> > is each way.. SO a conversation using full duplex will require approx
> > 80K in each direction G729 is 8K + 12k therefore 20K in each
> > direction. If your router supports stats you will see this.
> >
> > Ian
> >
>
> A router WOULD see such numbers, as it is handling TWO connections, one
> upstream and one downstream. An END POINT (soft phone, IP Phone, etc.)
> requires approximately 88 kbps for a G.711 conversation, not 196 kbps.
>
> You can read here, for a more thorough explanation:
> http://www.voip-calculator.com/bandwidth.html


And in the real world a call is made up of two parts:- Upstream and
downstream. and for example my sftphone is full duplex and I CAN see
the conversation and the bandwidth is 79K in EACH direction. The site
you mention is only taling about transmiting packets. Try it for your
self. Setup calls on an ADSL line and your callers will get serious
degridation after thr 3 or 4th call ( based on 256K upstream link
wereas you wont hear any degridation.

This experiance is based on Lab testing and Packet sniffing with
Mitel, Cisco and Asterisk IP PBXs

When designing IP networks the bandwith consideration has to be based
on FULL duplex IE 80K or 20K in each direction. The fact that yes
people often dont talk when someoe is taking to them doesn mean they
wont. Or for even more of a laugh and to see the effects of your
theory set the switch port to half duplex then try having a
converation.

Ian

 

[RC]

Archived from groups: comp.dcom.voice-over-ip (More info?)

I little something I threw together, and always round up.

EBW=Estimated BandWidth in Kbps
SR=Sample Rate in ms
IPH=IP Header in Bytes
L2H=Layer 2 Header in Bytes
CD=Codec (ie G.729=8 and G.711=64) in Kbps

EBW=(((SR*(CD/8)+(IPH+L2H))*8)*(1000/SR))/1000

This in non-product related, it doesn't mater if it's Cisco, Nortel, Avaya,
Vonage, Asteriks or anything else (despite what their marketing says).

L2H varies from as little as 6 Bytes to 38 Bytes and maybe more. It also
will change depending on what you layer 2 is. It's ethernet at you PC but
it's likely PPP at the router, use the highest number.

Tunneling adds another round of overhead and this isn't just VPN. PPoE,
which is very common on residential DSL, is also a tunnel technology. Whith
these the EBW becomes the payload of the VPN or PPoE packet.

Now this is just the start, we still have to deal with QoS, Serialization
delay, Jitter, and Latency.


--
rcohen_at_cominc_dot_net.no-spam

The only thing I guaranty about my free advice is that it's mine and it's
free.