On 3/8/06, <b class="gmail_sendername">Rich Adamson</b> <<a href="mailto:radamson@routers.com">radamson@routers.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> IAX2 is carried on UDP packets and they, by definition, are not required<br>> to arrive in order of transmission (or even arrive at at all) at the<br>> application layer. This differs from TCP packets, who are required to be
<br>> presented to the application in order and with no gaps. It follows<br>> therefore that queueing and congestion on a larger network such as the<br>> Internet may cause the IAX frames to go astray.<br><br>Correction... there is no requirement that tcp packets arrive in order
<br>either. The tcp packets do have the information neessary for the IP stack<br>to put the packets back in order, and do a retransmission request for<br>any missing packets, but that's it.<br><br>In general terms, both udp and tcp packets are subjected to the exact
<br>same out-of-order issues in any network, including the Internet.<br><br></blockquote></div><br><br>I think you missed the "application layer" part. By the time the application sees the data in TCP, it's a stream instead of packets, and in order. You could implement the same thing on top of UDP, although you probably don't want things like retransmission for voip.
<br><br><br>--Tim