Re: Symmetrical streams

On 07/12/11 16:24, Magnus Westerlund wrote:
> On 2011-07-12 13:48, Harald Alvestrand wrote:
>> On 07/11/11 22:18, Magnus Westerlund wrote:
>>>> It's logical for these RTP sessions to be bidirectional.
>>> RTCP within an given RTP session should always be bi-directional for
>>> efficiency in number of transport flows needing to be established and
>>> NAT traversal. Some application usages will result in that some RTP
>>> session will only be unidirectional when it comes to actual media
>>> streams. And uni-directional media streams of different purposes should
>>> not be group together into a common RTP session over the same
>>> bi-directional transport just to create bi-directional flows as that
>>> messes with RTCP behavior.
>>>
>> To be clear about the word "purpose" here, since it's gotten me into
>> trouble several times:
>>
>> Sending two video streams from one sender (for instance a MUC) to one
>> recipient (for instance an user) counts as one "purpose", right? Even
>> though one may be a high-res document-sharing screencast and the other
>> is a thumbnail-appropriate talking head?
> I would say that document sharing and a view of the presenter are
> actually two different purposes. The reasons is that if one would have a
> central node performing switching operation on these streams, they would
> likely be different behaviors. If the usage scenario is that a group
> discusses a set of slides coming from one end-point. Then the slides
> should be distributed to all unconditionally. However, which speaker
> video stream to forward by the central unit is the one that is currently
> the most active speaker. Thus different behaviors.
I do not enjoy a distinction that says "it is likely that". In the model 
of a central node which separates RTP sessions to each of its clients, 
the choice of what streams to send and the choice of what streams to put 
into the same RTP session are (as far as I can see) totally independent 
decisions.
> I use the word purpose, in the meaning the streams purpose in the
> application, but it might be easier to think of this as different
> application behavior around the streams.
>
> In the end it is the application needs and behaviors that truly will
> separate the streams into different type of sessions.
The reason I'm driving so much at this is, of course, that we have 
people telling us that they want the lowest number of RTP sessions that 
will not create technical issues. So we need to draw a dividing line 
between "sending these two media streams in the same RTP session will 
get you into trouble" and "sending these two media streams in the same 
RTP session is OK if you want to do it".
>> While sending an audio stream and a video stream, even though they come
>> from the same source and are intended to be presented together, counts
>> as two different "purposes", right?
> To clarify in the case of two different media types, they always have
> different purposes/behaviors.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>

Received on Tuesday, 12 July 2011 14:56:49 UTC