- From: Magnus Westerlund <magnus.westerlund@ericsson.com>
- Date: Wed, 13 Jul 2011 11:57:46 +0200
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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