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

On Thu, Jul 30, 2015 at 9:01 PM, Philipp Hancke <fippo@andyet.net> wrote:

> 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)
>
>
Then we'd either need to dirty the parameter list or add it to
RtpParameters, neither of which seem great.  ​




> 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)
>

​Why not correlate the MID to the participant?  ​



>
>>
>> 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.
>>>
>>
>>
>