- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Fri, 17 Apr 2015 02:19:33 -0400
- To: Harald Alvestrand <harald@alvestrand.no>, public-webrtc@w3.org
(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.
.: Jan-Ivar :.
Received on Friday, 17 April 2015 06:20:04 UTC