Re: [rtcweb] To multiplex or not!

[Colin Perkins <[e-mail]>]

On 20 Jul 2011, at 15:11, Cullen Jennings wrote:
> On Jul 20, 2011, at 4:08 , Emil Ivov wrote:
>> На 20.07.11 02:05, Cullen Jennings написа:
>>> I'd like to see it that devices MUST support multiplexing and I'd probably be in favor of also MUST support non multiplexed flows. The multiplexing is a big advantage for any device that needs to deal with NATs so I suspect many "legacy" devices would be moving to this even if there was no need to deal with the browser like devices. I also think that allowing this type of multiplexing will make firewall traversal easier where a device can configure a firewall to open just one specified port and use it for RTP.
>> 
>> I don't really agree with this part. Devices would still need to handle candidates that come from  STUN, TURN, UPnP, host IPv4, host IPv6, and potentially VPN, MIPv6 and other tunnelling mechanisms. Whether or not this only happens for a single component/stream doesn't really simplify code does it?
>> 
>> According to my personal experience with our work on ice4j.org, managing multiple checklists was far less resource consuming than implementing TURN tunnels and persmissions, STUN multiplexing, synchronisation and even getting pacing right.
> 
> Ahh, I think we have come to the key issues here - perhaps I have not been explaining myself very well. So in your experience roughly how long does it take to set up a for two scenarios using ICE as is today. 
> 
> First scenario: I have two devices that want to set up a single audio stream and they each have the candidates from: local v4 IP address, v4 stun, v4 turn, local v6, turn v6. Obviously they could have a lot more but that seems like a reasonable starting point. 
> 
> Second scenario: same as first address wise but instead of a single audio stream they want to set up a single audio stream  to a conference bridge plus 7 video streams for the video from the 5 people on the bridge plus a presentation stream and stream of video from active speaker. I don't really care much about the scenario other than there are 8 streams being set up. But this type of scenario is becoming very common for multi party video chat as it allows you to see perhaps small versions of everyone plus a large version of active speaker. 
> 
> My experience is the answer to the first scenario is not as quick as you would like and the answer to how long the second takes is about 8 times longer than the first one. You might do a bit better than that depending on how clever your implementation is but it still a lot longer. 

I may be misunderstanding, but why would this take 8 times as long to set up? Wouldn't you implement it as one UDP flow for the RTP audio, plus one UDP flow for the RTP video (with the 7 video streams multiplexed by SSRC, since RTP has always allowed multiparty flows of the same media type in a single RTP session)? This might take twice as long to setup as a single audio flow in the worst case, but not eight times as long.

Cheers,
Colin