Re: [rtcweb] To multiplex or not!

[Magnus Westerlund <[e-mail]>]

Cullen,

I mostly agree with Colin here. But looking at the advanced use case
this might be considered, and a bit on the control hierachy around it I
would say that this is either 2, 3 or 4 RTP Sessions. It is primarily
about how you would write your application and what type of RTP
conference mixer you have and what behavior it has.

For an application that has over the top labeling of the streams and
where the RTP mixer also can handle these streams appropriate it can be
only two RTP sessions. One for audio and one for video using SSRC
multiplexing to mux all the video streams.

In case you have your 5 participants being composited together in the
mixer and delivered as one stream, or some other behavior in the central
node you likely need to have one RTP session for that behavior. The
Active speaker and the presentation could simply be relayed as equal
SSRC multiplexed streams in one RTP session. Thus giving us one audio
and two video.

In worst case from a session perspective, the application writer has
decided that it is simplest to put map the stream semantics to the RTP
sessions, thus creating one Video for conference participants, one for
the presentation, and one for the active speaker(presenter) video. Thus
resulting in four streams.

There is two main things affecting the RTP session usage in an
particular application. The need of the application itself, and the
capabilities of any central node to perform the behavior desired by the
application.

Yes, I know that RTP Sessions appear a difficult concept. But, I would
recommend that everyone remembers that:

- An application can contain any number of RTP sessions.
- An RTP session can carry multiple media streams of the same type
- Multiple RTP sessions for the same media type can be used to separate
streams of different usages/behavior/processing in the applications or
any central node.

Cheers

Magnus

On 2011-07-21 00:21, Colin Perkins wrote:
> On 20 Jul 2011, at 15:11, Cullen Jennings wrote:

>> 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.
> 
-- 

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]
----------------------------------------------------------------------