- From: Mark Roberts via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jul 2017 03:41:22 +0000
- To: public-webrtc-logs@w3.org
I agree with @fippo's [comment](https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-294522434) from early in this thread:
> so setRemoteDescription with an a=msid:streamid trackid fires ontrack with a track whose id is 'trackid' only with an offer but not with an answer?! This doesn't make sense...
>
> Not that track ids are useful but this seems to make the msid concept rather useless.
I just hit this behavior while evaluating Safari 11 Tech Preview. Safari does not currently implement `offerToReceiveAudio`, and this spec says `offerToReceiveAudio` should behave ["as if addTransceiver('audio') had been called once prior to the createOffer() call"](http://w3c.github.io/webrtc-pc/#dom-rtcofferoptions-offertoreceiveaudio), but if you shim it this way your MediaStreamTrack ID will not match your MSID attribute. See [JSFiddle](https://jsfiddle.net/gd159o0m).
@taylor-b
> I agree it doesn't make sense. But signaling track IDs is redundant in the first place, now that we have MIDs. So, from my perspective, this is just legacy baggage we have to deal with, and it doesn't really matter what we do as long as the behavior is predictable.
I have not yet read up on how to use MIDs in the newer APIs yet. Track IDs may be redundant and brittle, but my application expected them to behave in a predictable manner according to the MSID attribute. I found this new behavior surprising.
I think it could be nice if there were a way to get the previous behavior when shimming `offerToReceiveAudio` in terms of `addTransceiver`, e.g. an extra member in RTCRtpTransceiverInit. It could be optional in order to enable early media in the default case.
--
GitHub Notification of comment by markandrus
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-314636020 using your GitHub account
Received on Wednesday, 12 July 2017 03:41:28 UTC