Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

On Sun, Aug 30, 2015 at 2:14 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 29. aug. 2015 06:44, skrev Peter Thatcher:
> >
> >
> > On Fri, Aug 28, 2015 at 2:20 PM, Harald Alvestrand <harald@alvestrand.no
> > <mailto: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.
>
> If the existence of an m-line implies that an RtpSender already exists
> for it, addTrack creating a new RTPsender would imply that you either
> replace the old one or that you end up with two RtpSenders referencing
> the same m-line.
>

​There are two ways two think about this on the answer side:

Option A;  setRemote​
​
​Description(offer) does not create an RtpSender, because it's possible for
an RtpReceiver to be "alone" without a matching RtpSender.  In this case,
addTrack would add a new RtpSender that would have the same MID as the
RtpReceiver.

Option B: setRemoteDescription(offer) creates an RtpSender, because there
must be an RtpSender for each RtpReceiver.  In this case, addTrack would
not add a new RtpSender, it would just "activate" the sender.

​
​
​Both could work, and have slightly different pros and cons.​
​


> Since the latter is breaking the model we just proposed, I assume that
> you mean the former - but why?
>

​I was suggesting Option A.  I had not thought of Option B until you wrote
your email.  But now I see that both are valid options to take.  But we
need to pick one.   The current spec is ore like Option A.​