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

Received on Wednesday, 29 June 2011 18:12:55 UTC