Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

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.

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