- From: Mark Roberts via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jul 2017 17:46:16 +0000
- To: public-webrtc-logs@w3.org
@jan-ivar in my application, we want to be able to associate MediaStreamTrack additions on one end of a PeerConnection to "track" events on the other. Stamping an MSID attribute in the SDP for each track added and then getting MediaStreamTracks on the other end with IDs corresponding to the MSID attribute was good enough for us to tie these two together. `replaceTrack`, as I understand it, won't necessarily (ever?) update the MSID attribute, so that's one reason we haven't made use of it. > If the goal is to solve legacy (code already written) then no need to change the public API. When the spec says "as if", browsers don't actually have to call addTransceiver like JS does, just the internal equivalent. OK, maybe the `offerToReceiveAudio`/`offerToReceiveVideo` can be handled differently. I'm still more concerned with @fippo's original observation that > 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 Shimming `offerToReceiveAudio` was the first place I saw this behavior change WRT MSID. -- GitHub Notification of comment by markandrus Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-314844778 using your GitHub account
Received on Wednesday, 12 July 2017 17:46:36 UTC