Re: sendonly streams in the offer

On 4/3/13 6:00 PM, Martin Thomson wrote:
> 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.

Yes, in a sense it is suboptimal; but the difference is not that great 
(the now offer adding video could go out as soon as the answer to the 
audio only offer has been sent). And I guess we would force it on 
developers rather than users.

That said, this is already solved for plan B (OfferToReceiveX).

>
> 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 Thursday, 4 April 2013 11:30:17 UTC