Re: Symmetrical streams

-Wang Jinyi
-CNIC CAS
----- Original Message ----- 
From: "Stefan Håkansson LK" <stefan.lk.hakansson@ericsson.com>
To: "Cullen Jennings" <fluffy@cisco.com>
Cc: <public-webrtc@w3.org>
Sent: Thursday, June 30, 2011 2:08 AM
Subject: RE: Symmetrical streams



________________________________________
From: Cullen Jennings [fluffy@cisco.com]
Sent: Wednesday, June 29, 2011 7:50 PM
To: Stefan Håkansson LK
Cc: public-webrtc@w3.org
Subject: Re: Symmetrical streams

On Jun 29, 2011, at 2:32 AM, Stefan Håkansson LK wrote:

>> (The discussion below involves PeerConnection. As we all know this is only one of the API proposals, and no decision has been 
>> taken on what starting point(s) the WG should use. But I thought it would be nice to discuss API functionality for a change! And 
>> the discussion may be relevant for the other API as well.)
>>
>> It is likely that many uses of APIs for real-time communication will be for symmetrical services - symmetrical in the sense that 
>> the Streams flowing from A to B will have counterparts flowing from B to A.
>>
>> Video conferencing is a typical example, there will likely be one Stream containing one audio and one video component from A to B 
>> and a corresponding Stream from B to A.
>>
>> For cases when all streams are not multiplexed over the same 5-tuple it would be beneficial if the IP-addresses and ports found 
>> to work for the A to B streams are re-used for B to A streams for several reasons:
>> -reduce NAT traversal problems
>> -simplify QoS handling
>> -simplify interop with legacy systems
>>
>> However, in the current PeerConnection API there is no way ask for pairing symmetrical Streams in this way. There are several 
>> ways this could be added, one way could be to add a second Stream as a second (optional) argument to addStream. When this 
>> argument is used the PeerConnection pairs the transport of the added Stream with the incoming Stream (identified by the label).
>>
>> The use would be (refer to http://www.whatwg.org/specs/web-apps/current-work/webrtc.html#peer-to-peer-connections):
>> 1. A side does addStream with a locally generated Stream as argument
>> 2. B side gets an onaddstream event
>> 3. B side does addStream with a locally generated Stream _and_ the received Stream as arguments
>> 4. Under the hood the PeerConnections makes the Streams use the same 5-tuples for transport
>>
>> (Other options include:
>> * adding an optional argument to addStream that the A side uses to indicate that a return stream is expected; the application on 
>> the B side is notfied about this and is expected to provide a Stream
>> * having the PeerConnections automatically re-use open channels; if there is an RTP audio stream flowing from A to B, and B adds 
>> a Stream that contains an audio component, that audio would flow on the same channel)
>>
>> Comments?

>Hi Stefan,

>I agree we need want to have this symmetry property when possible. When I read the whatwg proposal I just >assumed that it actually 
>worked in the  way you mention on your last option ( the PeerConnections automatically >re-use open channels ). Upon closer 
>reading, it does not seem to say that all. I'll have to think more about this but >having the underly thing setting up the streams 
>just take care of this seem like a nice property.

>I guess the question comes down to step 3 of your proposal - do we need to pass the received Stream or not? >Either way sees like 
>the underlying function could figure it out.

>Thoughts?

Hi Cullen,

yes I agree to that what it basically comes down to is: should this be visible from the API (either when A side adds a Stream, or 
when B side does as a response to the A side's new stream) or not.

Stefan

Hi All,

Is there any valuable use case which show that an application or a user need to know this, or they want to configure streams 
separately?
Making this property is visible or not is not a difficult thing, isn't it?
Therefore, if we need the visibility for some cases, we should open this feature to user; otherwise, leave this issue to the underly 
thing.
Moreover, the property can be added in the future.

Wang Jinyi

Received on Friday, 1 July 2011 05:32:57 UTC