<p>RTP stands for Real-Time Transport Protocol. TCP is not designed to deal with real-time data transfer as it takes time to acknowledge packets and re-send them if missing. All audio video data transfer happens in real time, and it doesn&#39;t make any sense to retransmit missing packets. Real time packets mixed with old missing packets which are submitted would result in an non-understandable audio and video. So how come any system can use TCP for real time data transfer, while assuring the quality at the same time. Does their exist any such system? I would certainly like to try it, maybe they are doing it right using some trick which I don&#39;t know yet.<br>
</p>
<p>Zeeshan A Zakaria</p>
<p>--<br>
Sent from my Android phone with K-9 Mail.</p>
<p><blockquote type="cite">On 2010-04-24 1:48 PM, &quot;David Backeberg&quot; &lt;<a href="mailto:dbackeberg@gmail.com">dbackeberg@gmail.com</a>&gt; wrote:<br><br><p><font color="#500050">On Fri, Apr 23, 2010 at 3:21 PM,  &lt;<a href="mailto:adamk@3a.hu">adamk@3a.hu</a>&gt; wrote:<br>
&gt; i have to put an * between two other SIP ga...</font></p>Don&#39;t do it.<br>
<br>
There have been any number of posts to asterisk-users begging asterisk<br>
to bend over backwards to accommodate Microsoft&#39;s foray into the world<br>
of VoIP. Nobody seems to be asking Microsoft to build a stack<br>
compatible with the rest of the world of VoIP.<br>
<br>
I disagree that sending SIP over TCP is superior to sending it over<br>
UDP. Think about it for a second. UDP is &#39;unreliable&#39; in that lost<br>
packets are not rebroadcast.<br>
<br>
Now let&#39;s say you have an &#39;unreliable&#39; connection where it&#39;s just<br>
barely good enough that the SIP call setup goes through, but the RTP<br>
stream immediately fails.<br>
<br>
Why would that be superior to having the SIP call setup getting<br>
dropped? The end result of no reliable voice is the same, but now you<br>
have a funkier debug condition that&#39;s going to be more complex to<br>
track down. I personally think it would be superior to see the bad<br>
connection as early in call setup as possible.<br>
<br>
And of course, SIP over UDP is the way the rest of the world works. If<br>
anybody wants to speak up about a framework that supports BOTH SIP<br>
over UDP AND SIP over TCP, maybe somebody already built a middleware<br>
layer that will let Microsoft join the world of voip.<br>
<p><font color="#500050"><br>-- <br>_____________________________________________________________________<br>-- Bandwidth and Colocati...</font></p></blockquote></p>