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

Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 28 Aug 2015 23:20:43 +0200
Message-ID: <55E0D0AB.4090907@alvestrand.no>
To: public-webrtc@w3.org
Perhaps (freely fantasizing) our model should be that there always exist
as many RTPSenders and RTPReceivers as the number of m-lines in the next
SDP createOffer will create, and that what happens when you do addTrack
is either that you bind to an existing sender or add a new one (causing
negotiationneded)? And that the ones without a track always were

And we could let getRTPSender always return all of them?

This would map a few more semantics reasonably:

- "negotiationneded" means "there are more senders/receivers than the
current SDP (exception: When you need to change a parameter by offer/answer)
- "sendonly/recvonly/sendrecv" can be completely determined from
RTPsender.active and RTPreceiver.active (when calling createOffer), or
be set by a setLocalDescription / setRemoteDescription
- replaceTrack can be used on any RTP sender/receiver
- offerToReceiveVideo sets the minimum number of m=video media sections
(can only increase, can never decrease)
- createRTPSender always increases the number of m-lines by one, which
implicitly creates an RTPReceiver (and vice versa).

Or perhaps it makes life no simpler.....

On 08/28/2015 08:48 PM, Peter Thatcher wrote:
> On Thu, Aug 27, 2015 at 2:23 PM, Justin Uberti <juberti@google.com
> <mailto: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 <mailto: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

Surveillance is pervasive. Go Dark.
Received on Friday, 28 August 2015 21:21:16 UTC

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