W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2017

Re: The uniqueness of track IDs?

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 3 Oct 2017 11:15:54 +0200
To: Henrik Boström <hbos@google.com>, public-webrtc@w3.org
Message-ID: <0a5f861d-69ef-7d8a-f6c9-26fbb81cb6a6@alvestrand.no>
On 10/03/2017 10:14 AM, Henrik Boström wrote:
> When setting a remote description containing audio and video tracks
> with the same ID, what is the expected behavior?
> Is this OK, and you have two tracks with the same ID, or should it be
> rejected?
> I've previously realized IDs aren't unique in the sense that you can
> add, remove, and then add again with the same ID and end up with
> multiple track or stream objects with the same ID, but I had thought
> that amongst streams and tracks currently in-use the IDs would be unique.
> Should the audio and video track IDs be considered separate domains?
> Or should I simply make no assumptions about the uniqueness of track IDs?
> I'm investigating a crash related to audio and video having the same ID.

The behavior must be well-defined, since the IDs in a remote SDP are
under the control of external parties (= attackers).

The choices are:

- Permit non-unique IDs

- Reject the SDP

I think we at one point permitted non-unique IDs because of the
following scenario:

(A connects to B)

A: pcB.addTrack(track)

(negotiation happens)

B: -> pcB.onTrack(track) => { pcB.addTrack(track) }  // Loopback

(negotiation happens)

At the time, we thought A needed to see the track, even though he's
already got a track with that ID.

I don't know if this is still the case.
Received on Tuesday, 3 October 2017 09:16:24 UTC

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