- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 29 Jun 2011 10:32:55 +0200
- 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 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? Stefan
Received on Wednesday, 29 June 2011 08:33:19 UTC