W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2015

Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Thu, 27 Aug 2015 12:01:01 +0000
To: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B315889024018558@ESESSMB307.ericsson.se>
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 


Received on Thursday, 27 August 2015 12:01:28 UTC

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