Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

I think this is an interesting idea, but unfortunately it leads to other
questions:

1) offerToReceiveVideo can be set with a lower number to create a=sendonly
m= lines. That is, lines with only a sender, but no receiver. Clearly
createRtpReceiver cannot accomplish this, so what do we do?

One option could be to *always* generate a RtpReceiver when a RtpSender is
created, and then .active can be set to false on the RtpReceiver to make
the overall line a=sendonly.

2) what happens if you call createRtpReceiver on the callee side?
OfferToCreateVideo only affects the offerer, but with createRtpReceiver
we'd need to understand the callee behavior as well.

It seems like it would create an 'extra' receiver, similar to how this is
handled on the offerer side, and therefore require a renegotiation to take
effect.

On Wed, Aug 26, 2015 at 2:54 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> It looks like we'll soon be adding PeerConnection.createRtpSender, which
> is a way to create an RtpSender before one has a track to send.
>
> The logic corollary is PeerConnection.createRtpReceiver, which would be a
> way to create an RtpReceiver before any media negotiation has occurred.  In
> other words, it would serve the same purpose as "offerToReceiveVideo".
>
> In both implementing offerToReceiveVideo and using it in JS, I found it
> awkward.  I think the following example code would be more natural:
>
> var receiver = pc.createRtpReceiver("video");
> // The offer now acts like it currently does with "offerToReceiveVideo =
> 1".
> var offer = pc.createOffer();
> // JS can use the receiver.track immediately.
>
>
> I think this would be more natural, and more logically consistent with
> PeerConnection.createRtpSender.
>
>
> If you'd like to see how it would look in a PR, here it is:
>
> https://github.com/w3c/webrtc-pc/pull/279/files
>
>
>
>
>
>
>