W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

Re: ReplaceTrack and track.id (Re: ReplaceTrack - need to evaluate alternatives)

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 17 Apr 2015 09:28:28 +0200
Message-ID: <5530B61C.4020305@alvestrand.no>
To: Jan-Ivar Bruaroey <jib@mozilla.com>, public-webrtc@w3.org
On 04/17/2015 08:19 AM, Jan-Ivar Bruaroey wrote:
> (Ah, this is where you explained how A talks to B. I missed it)
>
> On 4/15/15 3:01 AM, Harald Alvestrand wrote:
>> Just reiterating what I percieve as the original purpose of having 
>> IDs on these items:
>> To let Javascript applications talk to each other about the tracks.
>>
>> That is:
>>
>> A sends X and Y to B
>>
>> A sends (data channel, via web server, whatever) to B, something like:
>> {'display_map: { 'X': 'left', 'Y: 'right' }}
>>
>> B displays X to the left and Y to the right.
>>
>> If tracks have IDs that are consistent over the connection, this can 
>> be done by an application without referring to any property of the 
>> PeerConnection whatsoever; it just looks at the tracks.
>>
>> I'd like that property to remain - it's not necessary, because the 
>> receiver could look up the RTPReceiver for the track and get the 
>> identifier value from there, but it makes life easier in the simple 
>> case.
>
> If RtpSender.id = original_track.id, and RtpSender.id is used in SDP 
> (as I think someone suggested, can't find the post right now sorry), 
> then your model would seem to hold, provided that iff A wants to use 
> replaceTrack, it would remember to indirect through its senders, e.g. 
> send {'display_map: { [senderX.id]: 'left', [senderY.id]: 'right' }}
>
> People who don't use replaceTrack would be unaffected.

I liked the suggestion that went:

A: addTrack(X) => senderX with senderX.id = X.id
B: ontrack => XatB.id = senderX.id, receiverX.id = senderX.id

replaceTrack doesn't touch senderX.id
javascript can set senderX.id if it wants to
renegotiation only looks at senderX.id
renegotiation may update receiverX.id from senderX.id
B will end XatB and create XprimeAtB when receiverX.id changes

ie replaceTrack functions as a replacer, and A can affect whether old 
track is replaced at B or not, but it will only happen if A wants it to 
happen.

If we don't think we will ever want to make that happen, make senderX.id 
immutable.
Received on Friday, 17 April 2015 07:28:59 UTC

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