Re: [rtcweb] To multiplex or not!

[Harald Alvestrand <[e-mail]>]

On 07/20/11 13:10, Magnus Westerlund wrote:
> On 2011-07-20 11:49, Harald Alvestrand wrote:
>> Magnus, I cannot parse your list of choices.
>>
>> In the case where you have
>>
>> Sender A
>> Recipient B
>> Three video streams going from A to B
>> Three audio streams going from A to B
>> One video stream going from B to A
>> One audio stream going from B to A
>>
>> with the application not requiring the network to treat the packets any
>> differently, and with the application using the CNAME mechanism to match
>> audio streams with corresponding video streams
>>
>> it is completely unclear to me whether your choice A) requires 8
>> transport flows, 4 transport flows or 2 transport flows, and it is
>> completely unclear to me what C) actually means. (I assume "transport
>> flow" = "RTP sessions" here)
>>
>> Please - can you clarify what your question is intended to mean?
> With choice A I do mean that one for each RTP session use one UDP flow
> in each direction. And that these two UDP flows will be symmetric, i.e.
> a bi-directional UDP flow.
>
> This in contrast to B and C when you use some multiplexing to map all
> RTP sessions, independently of how many you have onto one bi-directional
> UDP flow.
>
> The above example you give is at least two RTP sessions, one for audio
> and one for video. It might be more than these two if the reason you are
> sending multiple video streams is because the streams should be
> differently treated, for example in a RTP mixer. Where you perform
> composition of video streams of the participants and simply switch a
> demonstration camera. Or it may be that entity A above is transport
> relay and it is forwarding the camera from three different conference
> participants and all video streams are the same RTP session.
>
> It is the application that has do make these choices about if it needs
> more than one RTP session or not.
Magnus, if the number of UDP flows is constant (even if it's slightly 
larger than 1) when the number of video streams changes under your 
solution A, I think this is a viable option.

If the number of UDP flows was linear with the number of video streams, 
I believe that a number of scenarios we want RTCWEB to support, 
including stuff like the Google+ Hangouts, would be basically unsustainable.

So - with the understanding that an application is going to put as many 
video streams it wants down one RTP session if that's appropriate for 
the purposes of the application - I am in favour of the "no 
multiplexing" solution.

                      Harald
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
>