Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

On Thu, Aug 27, 2015 at 2:23 PM, Justin Uberti <juberti@google.com> wrote:

> 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.
>

​Ah, good point.  That's a use case I had forgotten about.  I think the
option of always creating an RtpSender that can be
deactivated/closed/removed/whatever with addTrack makes sense.   That's
effectively what it does already.  But then we'd need to make it clear that
"addTrack" really means "sendAndReceiveTrack".
​


>
> 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.
>
>
​I think it would create a new m-line, which would fire onnegitationneeded,
just like createRtpSender does.​



> 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
>>
>>
>>
>>
>>
>>
>>
>