On Mon, 12 Apr 2004, Scott Laird wrote: > I mean, even G.711 is only ~80 kbps (including overhead), so you > should be able to run hundreds of simultaneous conversations on 100 > Mbps Ethernet without running out of bandwidth.
Disclaimer: I do not build networks for a living -- the following comes from years of working near people who do, as well as a more-than-passing interest in making networks work well. Usually the LAN is not the problem. Wide-area links (such as your Internet connection) are where attention must be paid. ~80kbps is not much traffic, sure, but making sure that the packets that comprise that flow are delivered in a timely manner -- and not swamped by someone streaming video or doing a Windows Update -- is the trick. Even a T1/E1-sized IP link to head-office will give you grief if you're trying to conduct low-latency traffic at the same time as the VP's assistant sends the 50MB all-staff Xmas-Party-Invite.doc via e-mail... :) The problem can be in buffer sizes. One trick that router admins used to use to keep WAN links busy and happy (particularly links with a high round-trip-time such as satellite) was to increase the length of the transmission queues and the transmit and receive windows -- increasing the number of packets that get lined up for transmission, and making it more likely that we've continued transmitting instead of waiting for acknowledgements. This will utterly destroy anything real-time, as any large transfer will fill up the longer queue all at once (you'll know what I mean if you've ever tried to use telnet or SSH over a link that's simultaneously filled up with a big FTP or HTTP download, or the above example e-mail). So, the trick was to keep the queue short enough to maintain some degree of interactiveness, yet long enough that the link is kept active. Nowadays, we can use QoS and priority queueing to put interactive stuff straight to the front of the queue -- but we still have to hope that our ISPs and carriers treat that the same as we do. (Speaking of window sizes, I've heard that for extreme performance it is not wise to mix TCP and UDP on the same interface because of the different ways that windows and buffers are sized with TCP and UDP... I don't know enough to confirm or refute this. I can imagine that TCP's method of setting the window size -- blast it out until it doesn't fit any more -- might cause a problem for a UDP-based RTP stream already in-flight... Comments?) Back to LANs: it is possible to see problems on very busy Ethernets. In unswitched networks, if utilisation is high, collisions are more likely (we don't call it Crashernet for nothing). This might be sufficient to give you some loss of quality, or at least start to exercise your jitter buffering. In switched networks, if your backbone is being overworked you may get packet loss etc. Neither of these situations are directly helped by QoS -- if your packet can't get on the wire, or gets thrown off later, a few bits in a header won't change that much (although some routers and switches may make traffic with identified QoS less likely to be thrown out -- kind-of like how the Discard Eligible bit is used in Frame Relay). Cheers, Vic Cross _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
