Re: Symmetrical streams

On 2011-06-30 05:03, jywang wrote:
>
> -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?
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