Re: Symmetrical streams

On 2011-07-12 16:56, Harald Alvestrand wrote:
> 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.

In this discussion I think we should make it clear that there are two
different aspects of why media streams should be in different RTP sessions.

The first, is when the media streams properties are such that it is
unsuitable to have them in the same RTP session. Reasons behind this
include need for different RTP functionalities, RTCP behavior
restrictions, RTCP bandwidth.

The second aspect has to do with the application and what it is assumed
to do with media streams. If an end-point or a central node makes
significantly different choices will show different behavior based on it
knowing that a media stream really represents A or B then we have a need
for categorizing and labeling the media streams differently.

RTP sessions can be used for this separation. It is not the only method,
especially not for the second aspect. However, most existing signalling
for both RTP functionalities and labeling are operating on RTP session
level. Thus, we have an existing implementation base handles RTP
sessions and different configurations on session level.

I don't know about frameworks that allow for fine grained indication of
the media streams and what they represents so that both central nodes
and receivers can correctly differentiate this in an application context.

Yes, WEBRTC can attempt to break new ground in this aspects, as long as
one takes the technical limitations of RTP into account. But, one should
also keep in mind the existing implementation base and how much
modifications that are needed. That impact on interoperability and
thirdly the possibility for legacy interop or extra complexities
introduced in those cases.

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

Fully understood. From my perspective, this is really a question how you
can get an distributed application to interop correctly. We clearly need
a situation where an web-application developer that intends to rely on
centralized nodes, can map its application onto the functionality of the
centralized node, determine how media captures needs to be routed to
different RTP sessions to achieve the function the applications should
have. This in a case where the web-app is running on multiple different
implementations of browsers.

Yes, this is not an easy problem. And most people are used to the basic
communication application where all audio streams are basic equal. But
to support more advanced use cases, one needs to consider how to go
beyond the "all are equal".

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 Wednesday, 13 July 2011 09:58:29 UTC