Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

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
active=false?

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.