W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Next steps on RTCRtpSender "doohickey" proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 08 May 2014 09:46:52 +0200
Message-ID: <536B366C.4080602@alvestrand.no>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 05/08/2014 09:43 AM, Stefan Håkansson LK wrote:
> On 2014-05-08 08:07, Harald Alvestrand wrote:
>> (as contributor) +1 from me.
> Ditto.
>> One nit: The following should be legal:
>> addTrack(track, streamId1)
>> addTrack(track, streamId2)
>> this means that one track should be presented to the receiver as part of
>> two streams.
> I still think that conveying the MediaStream(s) a track belongs to using
> SDP adds unnecessary complexity to the API and the solution.
> But if we should, why not make the second (and optional) argument to
> addTrack a list of streamId's instead (I proposed that in [1])?
> If you can call addTrack several times with the same track as first
> argument but different streamId's, what should happen at the far end if
> you carry out an SDP O/A between the calls?

The same thing as happens when you add two different tracks and do an 
SDP O/A between them: The SDP O/A reflects the state at the moment the 
CreateOffer / CreateAnswer is called.

This is needed to make it possible to polyfill AddStream without adding 
a bunch of special cases.
Received on Thursday, 8 May 2014 07:47:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC