Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt

Hi, Magnus -- thanks for the reply.

On Jul 19, 2011, at 8:52 AM, Magnus Westerlund wrote:

>> 
>> As the draft concludes, the multi-stream scenario is best handled by
>> SSRC-multiplexing, as was originally envisioned by RTP.  Given that
>> this is the case, it's not clear to me that it's a good idea to use a
>> separate (and in my opinion, less flexible) mechanism for the
>> specific special case of simulcast.  Instead, given the pressure from
>> groups such as RTCweb to reduce the port consumption of RTP, I'd
>> recommend SSRC-multiplexing across the board.
> 
> Jonathan lets me ask you a question. Is any hesitation to use several
> RTP sessions when most suitable due to the port consumption issue or for
> some other reason? And here we can debate what is most suitable.

Part of it is port consumption, but more importantly, architecturally, is the problem that architectures
that are designed around the "one source (in each direction) per session" assumption break badly in a
whole lot of scenarios that are more complicated than the simple point-to-point
one-source-per-media-type model.

> My view is that multiple SSRCs in an RTP session is a very good
> mechanism for streams that one expect to be treated the same way in both
> central nodes or in end-points. When it comes to sets of streams that
> needs a different treatment, I think it is logical and a powerful
> construct to use the RTP session for separating these sets of streams.

This is valid so long as you can make the simplifying assumption that you *can* treat every source in a
session identically, blindly, with no further information about the content of each one.  But there are
plenty of scenarios in which

>> Note also that in the case of multiple sources which are each
>> independently simulcast, the simulcast structure of different sources
>> could well be different.   (E.g., source A could be available in two
>> resolutions, while source B has only one and source C has three.)
>> It'd be extremely difficult to map this in session-multiplexed
>> simulcast, whereas for SSRC-multiplexed simulcast it should be no
>> more complex than the single-simulcast-source scenario.
> 
> This is a valid concern, but which I think we have a reasonable straight
> story for. In the direction you have a certain number of simulcast
> versions you negotiate that number of session and their individual
> configurations.

I'm not thinking about asymmetric sources in each direction -- I'm thinking about multiple,
heterogeneous simulcast sources in the *same* direction.  In this case, it's really unclear how one would
map the simulcast channels to multiple sessions. 

--
Jonathan Lennox
jonathan <at> vidyo.com

_______________________________________________
Audio/Video Transport Core Maintenance
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt