RE: RtpReceiver: controlling the id attribute of the received track?

The mid/muxId enables multi-party applications to avoid having to use SSRC-based matching, with associated signaling (e.g. a=ssrc in SDP).

Unfortunately, this requires addition of support for the mid header extension in browsers and SFUs so it may take a while for support to become widely available.

From: Philipp Hancke [mailto:fippo@andyet.net]
Sent: Sunday, July 26, 2015 2:46 PM
To: public-ortc@w3.org
Subject: RtpReceiver: controlling the id attribute of the received track?

i am thinking about mapping https://tools.ietf.org/html/draft-ietf-mmusic-msid-10<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-mmusic-msid-10&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c1c2a18aa64254994cd3a08d298659501%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=I86C8W9Qpo5AZgyNm3d3u8STT62vkgeEvAJ3aHx%2fU7A%3d>

At the javascript level, the gist of this is (as I understand it) to allow a correlation between SDP operations and onaddstream. For multiparty applications (using plan B) I add a new msid in the SDP and sometime later get an onaddstream and need some way to correlate that, in particular when adding multiple new streams at the same time.

Now ignoring that with ORTC i'm in charge and don't get streams/tracks popping up at random...
is there a way I can control the id of the Receiver's track? The track's id is readonly so I can't change it.