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

Re: [webrtc-pc] does MSID still work? (was: example 13: getReceivers semantics)

From: Mark Roberts via GitHub <sysbot+gh@w3.org>
Date: Wed, 12 Jul 2017 22:10:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-314912289-1499897409-sysbot+gh@w3.org>
@jan-ivar thanks for taking the time to address my comments. I think I can see some ways forward with this behavior.

I have one more question/suggestion. Assume I wanted to signal a "menu of tracks" in my application. The idea is that this menu represents metadata about each of the MediaStreamTracks that might be shared once I negotiate, and the menu is always shared before negotiation:

```js
const menu = {
  'track-1': 'metadata 1',
  'track-2': 'metadata 2'
}
```

During negotiation, I get some "track" events with MediaStreamTrack IDs that aren't necessarily in the menu, so I can't lookup my metadata:

```js
pc.ontrack = event => {
  console.log(menu[event.track.id])
  // => undefined
}
```

However, I do have `event.transceiver.mid`, so I ought to be able to recover the MSID by parsing the SDP. I could write a function `bad` that looks up the corresponding MSID and returns `remoteId`, allowing me to lookup my metadata:

```js
pc.ontrack = event => {
  const remoteId = bad(event.transceiver.mid, pc.remoteDescription.sdp)
  console.log(menu[remoteId])
  // => "metadata 1"
}
```

But the function `bad` is bad... so would it make sense to instead add a property to the RTCRtpReceiver? e.g.,

```webidl
interface RTCRtpReceiver {
    // ...
    readonly attribute string? remoteTrackId;
    // ...
};
```

Then, my example code becomes

```js
pc.ontrack = event => {
  console.log(menu[event.receiver.remoteTrackId])
  // => "metadata 1"
}
```

Thanks again,
Mark

-- 
GitHub Notification of comment by markandrus
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-314912289 using your GitHub account
Received on Wednesday, 12 July 2017 22:10:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC