Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

On Fri, Aug 28, 2015 at 2:20 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

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

​I think that makes a lot of sense.​



> , and that what happens when you do addTrack is either that you bind to an
> existing sender or add a new one (causing negotiationneded)?
>


​I think addTrack would always create a new RtpSender, but that may bind to
an existing m-line.


> And that the ones without a track always were active=false?
>

​I think wether a track is active or not is independent of whether it has a
track or not.​

​


> And we could let getRTPSender always return all of them?
>

​I think it should always return all of them.  Which ones wouldn't it
return?

However, that does, I think, mean we need some kind of state variable on
the RtpSender to indicate whether it has been added to the local/remote
descriptions or it will be the next call to createOffer (perhaps change
active/inactive to new/active/inactive).​



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

​A good way to think about it is "creating an RtpSender or RtpReceiver can
add an m-line or change the direction of an m-line, both of which can
trigger onnegotiateneeded".​



> - "sendonly/recvonly/sendrecv" can be completely determined from
> RTPsender.active and RTPreceiver.active (when calling createOffer), or be
> set by a setLocalDescription / setRemoteDescription
>

​I think that's a great way to think about it.


> - replaceTrack can be used on any RTP sender/receiver
>

​Isn't it already a given that you can call replaceTrack on any RtpSender?​
​


> - offerToReceiveVideo sets the minimum number of m=video media sections
> (can only increase, can never decrease)
>

​I'd rather get rid of offerToReceiveVideo and just make the rule you get
as many sendrecv or recv m-lines as the number of RtpReceivers you create
(remembering that addTrack also creates an RtpReceiver in a roundabout
way).​



> - createRTPSender always increases the number of m-lines by one, which
> implicitly creates an RTPReceiver (and vice versa).
>

​Actually, this is the part where I think createRtpSender needs to be
fixed.  I think it *shouldn't* create an RtpReceiver.  If it does, we
should call it something else, like createRtpSenderReceiverPair and return
a pair.  And if we have that, then the question becomes: how do you create
just a sender and not a receiver?  Do you always create a receiver and then
deactivate it?
​


>
> Or perhaps it makes life no simpler.....
>
>
​I think there's something here that could make like a lot more simple.  A
model where "m-line = RtpSender + RtpReceiver pair with matching MID" makes
a lot of sense to me.  ​



>
>
> On 08/28/2015 08:48 PM, Peter Thatcher wrote:
>
>
>
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>