W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Re: sendonly streams in the offer

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 3 Apr 2013 09:00:50 -0700
Message-ID: <CABkgnnXa0M7kZ44D=H5fURCUAaVvJG-x-SZxK6WD1JGzg3QkOA@mail.gmail.com>
To: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 3 April 2013 06:10, Stefan HÃ¥kansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> On 4/3/13 2:00 PM, Cullen Jennings (fluffy) wrote:
>> But I think we should rethink this whole OfferToReceiveVideo thing.
>> Say you wanted to receive 2 video stream but not offer any? How would
>> one do that. I think the best way would be to create some tracks
>> attached to a video element and add them to the PeerConnection. Or
>> something along theses lines.
> I'm not sure we need that kind of functionality. The current APIs are for
> the sender; so the sending app decides (what it adds to PeerConnection).
> If a certain application would like the receiver to decide, it could use app
> internal signaling (the receiving app tells the sending app what it wants,
> and the sending app adds that to the PeerConnection).

I think that Suhas had it right, but Cullen confused the issue.  When
I generate an offer, unless that offer contains m= lines (*) that
cover the video I am prepared to receive, then I wont be able to
receive it unless there is a renegotiation.  That's suboptimal.  We
could decide to force this upon users, but I think you may experience
some conflict if you try.

Cullen's idea of creating MediaStreams isn't going to work at all.  At
least not without a fairly significant change to MediaStream.

(*) Plan A or B are different here, but that isn't material to the argument.
Received on Wednesday, 3 April 2013 16:01:21 UTC

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