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: Sun, 30 Aug 2015 11:14:41 +0200
Message-ID: <55E2C981.1000607@alvestrand.no>
To: Peter Thatcher <pthatcher@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
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?
Received on Sunday, 30 August 2015 09:15:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC