W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2011

Symmetrical streams

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 29 Jun 2011 10:32:55 +0200
Message-ID: <4E0AE337.3030502@ericsson.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
All, in role of contributor.

(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)


Received on Wednesday, 29 June 2011 08:33:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:20 UTC