|
Hm, I’m not sure I agree. UDP has a feature that TCP simply cannot
match: lossiness. This is a desirable trait for VoIP that TCP lacks.
If a voice packet gets dropped, it’s not merely unnecessary to
retransmit, it’s actually harmful to voice quality. Indeed, I expect they use TCP only on a
LAN precisely because they count on there being *no* congestion, because they recognize UDP is preferable in a
bandwidth-constrained environment (ie, the internet). This is because the
only real option for VoIP is to notice high packet lost (via something RTCP-ish)
and reduce your stream encode rate. In the event bandwidth is constrained,
TCP will just back up and destroy your voice quality, while complicating your
ability to detect and resolve the problem (and even if you do back off the encode
rate, it’ll need to send your huge backlog of data before the new encode
rate can kick in). Granted, I’ll entirely admit TCP is superior
to UDP for stream data that must be reliably delivered in order (which is its
whole point). Likewise, it is certainly easier to work with TCP streams
than reconstruct TCP on top of UDP. But for VoIP, UDP is the way to go.
If they’re using TCP, I think it’s
for reasons other than performance and voice quality. -david From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Michael Slavitch You can encapsulate and overload far more in a TCP stream than in a
sequence of UDP packets with less development effort. This is not novel, it is the basis for all communications theory since
the stone age of DECNET and SNA. Step back and think of the possibilities. Stop thinking of voice
as the endgame and instead as the beginning. M |
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
