Zoltan, It has nothing to do with bandwidth (well, it does, but not in the way you think).
When there is data being sent on the wire, the system allocates bandwidth to everything equally. That's kinda fundamental to how packet-based networks think (QoS is a bit un-natural, which is why it is so troublesome). So, whenever anything in your network sends a packet, it gets the whole link, whether your IP set is sending a tiny little <500byte packet, or your bit-torrent client is sending thousands of massive, fragmented packets. Pretty much all of the data on your network is going to send packets that are larger than your voice packet, and for the brief moment that they are transmitting, they get 100% of the pipe. Whether you have a 56K link or a 1Gig link, each packet gets 100% of the bandwidth for as long as it takes to get to the other end. When you do tests on a line that is in use, the bandwidth you see is not really measuring the transmission rate on the line, it is measuring the effective bandwidth between the testing application and the testing centre. These tests are only accurate if there is no other traffic on the line. Anyhow, the reason you have voice problems is that as far as the network is concerned, some other packets have priority over yours (simply because they got there first). It only takes a few milliseconds to get to the front of the line, but those milliseconds are enough for our ears to notice that the data hasn't arrived yet. Voice represents these tiny little packets that have to exist in a world of massive packets. If we could just always let the little voice packets to the front of the line, all would be well, but by default the network doesn't care what you are: take a number and wait your turn. What QoS attempts to do is ensure that the voice packets always get to the front of the line. This needs to happen at both ends of the circuit (and Rogers doesn't do this yet, AFAIK). If you have a lot of traffic, an overburdoned router may still have problems getting the voice to the front of the queue. And if it takes more that a few scant milliseconds, you hear the loss of packets as static and such. Please note that this is a very general overview of this stuff. Some of what I have said is probably techically innaccurate, but it is conceptually accurate enough to perhaps get a picture of what is happening. How much bandwidth you have is not nearly as important as the priority with which the voice traffic is handled. You can control what you send at your end with QoS, but Rogers controls what you receive. Jim > -----Original Message----- > From: Pittner, Zoltan [mailto:[EMAIL PROTECTED] > Sent: November 2, 2006 9:17 AM > To: [email protected] > Subject: [on-asterisk] Call waiting > > I guess first I owe you an answer on my sound quality question: > > The end results of the investigation: The loss of quality > seem to be caused by the choppy internet service Rogers > provides even if you pay $55 on the Extreme package. Once the > download speed falls under 2Mbps the call quality seems to > deteriorate dramatically. Anything over 3Mbps gives good > quality - which is a little strange since none of these > services require so much bandwidth. > > Another question: > > Is there a way to enable Call Waiting by default on all > extension - without having to key in *70 from all the extensions? > > The reason I am asking this is the following: > > I have a Bell line connected through a Sipura 3102 and an > Atlasvoice line trunked directly into Asterisk. > > I called Bell and asked them to disable the call waiting > function and enable a call forwarding on busy or no answer - > to my Atlasvoice line. It took them > 3 weeks and a few tries to get it right, but I think it is ok now. > > I did the same on the Atlasvoice line - it is forwarded to my > Bell line in case of busy or no answer. So the call waiting > signal is internal to asterisk now, and I should be able to > use it by flashing between the lines. > However every time I reboot the asterisk server it goes back > to default call waiting not enable mode. So is there a way to > enable that by default? > > Thanks, Zoltan. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.409 / Virus Database: 268.13.22/512 - Release > Date: 01/11/2006 >
