On Tuesday 23 December 2003 11:40, Rich Adamson wrote: > There's no reassembly with udp, and there is no sense of packets arriving > in the same order as what was sent. Udp is a best-effort low-overhead way Right, UDP itself does not care about order, but at the application layer you can keep track of it. You can design your application to buffer X packets and then reorder them according to sequence numbers.
> of transmitting data (with UDP often times referred to as the Unreliable > Data Protocol). Changing to TCP would allow reassembly, however the > overhead would be substantial. > > ------------------------ > > > The problem occurs when the software is expecting the packet in a certain > > timeframe so that it can reassemble it in a timely manner. It's not a > > big deal with a web page or something along that lines. But when a voice > > application cannot get reassembled in a timely manner, you'll surely > > notice it! > > > > -----Original Message----- > > From: Joel Maslak > > To: [EMAIL PROTECTED] > > Sent: 12/23/2003 10:41 AM > > Subject: Re: [Asterisk-Users] Asterisk SIP Packet Time (20ms) > > > > On Tue, 23 Dec 2003, Rich Adamson wrote: > > > If a collision or dropped packet occurs (in a voip udp environment) > > > > there > > > > > is no way to retransmit the missing/damaged packet. Missing one packet > > > > isn't > > > > > a big deal, but if you have collisions and/or dropped packets, there > > > > is a > > > > > very high probability that lots of packets will be dropped. If too > > > > many > > > > > are dropped, you'll hear the result in the undecoded voice as choppy > > > voice. > > > > Actually, collisions occur at Layer 2, not Layer 3, and the layer 2 > > hardware automatically resends packets involved in a collision - layer 3 > > is never aware of it happening (although it may cause additional delay). > > Eventually the ethernet card will give up if too many collisions occur > > during retries, but this is very rare in practice unless the network is > > *VERY* loaded. > > > > > Assuming alaw/ulaw codecs in use (about 80k bps), a half duplex 10 meg > > > ethernet would handle roughly 20-25 rtp sessions before bumping into > > > > the > > > > > problem (your milage may vary). The majority of the folks on this list > > > seem to be running home/soho systems and would likely never run into > > > > the > > > > > issue. But the heavier users will. > > > > For a duplex mismatch, my experience is that if one end on a 100 Mb/sec > > link is half and the other is full, bandwidth is limited to about 8 > > Mb/sec > > max. This is based on some tests I've accidentally conducted. If you > > try > > to send 9 Mb/sec over that link, yes, some packets will get dropped as > > they simply won't fit. (But I do agree that for a half-half link, you > > can > > get about 20 Mb/sec) > > > > -- > > Joel > > _______________________________________________ > > Asterisk-Users mailing list > > [EMAIL PROTECTED] > > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ > > Asterisk-Users mailing list > > [EMAIL PROTECTED] > > http://lists.digium.com/mailman/listinfo/asterisk-users > > ---------------End of Original Message----------------- > > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
