Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

On 2015-08-26 23:57, Peter Thatcher 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

I like this approach when you explicitly create a new receiver.

It eliminates the confusing with offerToReceiveAudio/Video whether the 
numbers represents *extra* media descriptions that should be added on 
top of those created by the addTrack() API or if the number represents a 
total.

/Adam