Thanks for your response. Here's my plea for ICE-TCP ;) I know that TURN/TCP has landed in Fx28 and that is one way to establish a TCP connection when UDP is blocked. However, UDP blockage is not the only reason to require TCP. Currently, I think that there is no way to force the client to use TURN/TCP when UDP is *not* blocked.
The reason this matters to me is for a group conference with a large fan out. For example, 1 person is speaking, and his audio/video stream is going out to 500 listeners. (a common scenario in my product). There is an enormous advantage to be gained if you can make sure no packets go missing between the sender and the MCU. When it is possible to craft an offer containing a single ICE TCP candidate, you can be certain that the sender is connected by TCP. However, if you have a UDP candidate only, along with a TURN server, the sender might use TURN/TCP, or he might not, depending on the connection check results. NACK exists for video packets, but audio is a different story, and some people's connections have high loss. When communicating 1:1 low latency is more important than packet loss. When communicating 1:N, I think that packet loss on the sender-server leg becomes very important for large N. On Thu, Dec 12, 2013 at 2:33 PM, Eric Rescorla <[email protected]> wrote: > ICE-TCP is not currently scheduled. > > We are currently working on BUNDLE but don't have a schedule. > I did know that. > > -Ekr > > > On Fri, Dec 13, 2013 at 4:29 AM, <[email protected]> wrote: > > Can you provide an update on when these features are expected to land? > > _______________________________________________ > > dev-media mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-media > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
