On 12/12/13 17:09, [email protected] wrote:
NACK exists for video packets, but audio is a different story, and some people's connections have high loss.
For connections with high loss, you'll want to keep in mind that TCP is likely to make life for your users worse, not better.
The problem is that you're going to end up with TCP head-of-line blocking. If you lose a single packet and wait for a TCP retransmit, that's possibly okay, depending on what your TCP parameters have converged to. Once you get into high loss situations and lose two consecutive packets, you've pretty much blown any "real-time-ness" of your TCP connection.
At best, a sophisticated implementation might play packets out slightly faster than real-time, hopefully with appropriate frequency adjustments. More realistically, you'll probably have implementations either become permanently behind by 500ms, 1000ms, or more; or drop received packets on the floor to catch up. A delay on that order makes the connection unusable for conversation, and I can't imagine forcing the receiver to drop packets is in any way preferable to letting the network lose them instead.
So, yeah, there's a really good reason real-time communications are done over UDP whenever possible. TCP should be a last resort.
I guess the overarching issue here is that ICE-TCP provides what I consider to be an imperceptibly small improvement over TURN-TCP. But, as Eric says, if you want to give us patches, we're not opposed to ICE-TCP on principle -- it's just that the return on investment is so very, very small.
One final thought: If you're absolutely determined to use TCP for your audio, even after carefully considering the factors above, you can set up your conference server to act as a TURN-TCP server (just speak the TURN over TCP protocol, with RTP encapsulated inside it, but process and generate the RTP locally), and configure your PeerConnections to use it as their sole ICE server.
-- Adam Roach Principal Platform Engineer [email protected] +1 650 903 0800 x863 _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
