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

On Thu, Jul 30, 2015 at 9:42 AM, Peter Thatcher <pthatcher@google.com>
wrote:

> You mean that you want the RtpReceiver.track created by the RtpReceiver to
> have a particular track.id instead of being some random thing?
>

Yes. For proper mapping of the msid behaviour of the PeerConnection API
there is the additional problem of getting the stream id right....

I hadn't thought of that, but now that you mention it, it does sound
> reasonable.  We can't add track.setId(...).  That's outside the scope of
> ORTC.  But maybe we could have a RtpReceiver.setTrackId(...) that can only
> be called before you call RtpReceiver.receive() (calling it after would
> either blow up or be a no-op).
>

How about passing an attribute to .receive()? (I am assuming the track
property does not exist before this is called)

On the other hand, I think that apps shouldn't use track IDs for anything
> anyway.  They should use MIDs instead.  So 'd prefer that this weren't
> needed in the first place.
>

The usecase I have in mind multiparty. In the PeerConnection API I am using
the stream id to associate the onaddstream calls with participants (think
of calling SRD with a bunch of new msid lines).
At a higher level, my code expect to correlate the stream id to a
participant.

(that said, I don't see a way to control the _stream_ id so I might have to
go back to the drawing board; ORTC makes this simpler since I don't get
callbacks randomly but am in control so it might work)

>
>
> On Sun, Jul 26, 2015 at 2:45 PM, Philipp Hancke <fippo@andyet.net> wrote:
>
>> i am thinking about mapping
>> https://tools.ietf.org/html/draft-ietf-mmusic-msid-10
>>
>> 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.
>>
>
>