Re: Symmetrical streams

On 2011-06-30 05:03, jywang wrote:
> -Wang Jinyi
> ----- Original Message -----
> From: "Stefan Håkansson LK"<>
> To: "Cullen Jennings"<>
> Cc:<>
> Sent: Thursday, June 30, 2011 2:08 AM
> Subject: RE: Symmetrical streams
> ________________________________________
> From: Cullen Jennings []
> Sent: Wednesday, June 29, 2011 7:50 PM
> To: Stefan Håkansson LK
> Cc:
> 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
>>> 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?
What I can think of is a situation where there is more than one 
symmetrical Stream pair; if one of these are to be torn down and they 
haven't been properly paired at set up you would leave more connections 
open than required.

I can't say how common or relevant this would be though.
> 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 Thursday, 30 June 2011 13:56:18 UTC