- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 05 Feb 2012 17:40:53 -0800
- To: Randell Jesup <randell-ietf@jesup.org>
- CC: public-webrtc@w3.org, Randall Stewart <rrs@lakerest.net>
On 02/03/2012 01:50 PM, Randell Jesup wrote: > On 2/3/2012 12:49 PM, Stefan Hakansson LK wrote: >> On 02/03/2012 06:41 PM, Harald Alvestrand wrote: > >>> An advantage of bidirectional streams is that it doesn't matter which >>> end creates the data stream; with unidirectional, there either has >>> to be >>> a flag stating the direction or a convention that the data sender (or >>> receiver) always creates them. >> >> Or different objects; the one creating the dataStream has a "sink" and >> the the receiver a "source". But I think it is simpler if they are >> bi-directional. > > I believe I agree - it's simpler for the application developer; I see > no real advantage to their being unidirectional. (RTP is (normally - > symmetric RTP) bidirectional as well). Mumble.... RTP sessions are bidirectional unless declared unidirectional, but each SSRC within an RTP session is strictly unidirectional (there can only be one sender per SSRC at any time). We've mapped SSRCs to MediaStreamTracks, which are also unidirectional, and defined MediaStreams (which don't have a corresponding RTP construct - see draft-alvestrand-rtcweb-msid) as unidirectional too. So application developers in RTCWEB land are already dealing with unidirectional stuff.
Received on Monday, 6 February 2012 01:41:23 UTC