An RTCRtpTransceiver has a null mid until it's been associated with a media description (with a mid) [1]. During that time, it's identified by a provisional mid that might become its real mid, but the transceiver can also get its mid assigned by a remote media description. In the second case, the mid value is initially unknown. A transceiver's RTCRtpSender must directly (synchronously in the script) provide a muted remote source that is playable by, for example, media element. This source is initially registered in the MediaEndpoint (WebRTC backend) with the transceiver's provisional mid. So, if the real mid is set by a remote description, the registered mid must be updated to preserve the association between the registered source and the transceiver. [1] https://w3c.github.io/webrtc-pc/archives/20160913/webrtc.html#dom-rtcrtptransceiver-mid
Created attachment 291082 [details] Proposed patch
Comment on attachment 291082 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=291082&action=review > LayoutTests/fast/mediastream/RTCPeerConnection-remotely-assigned-transceiver-mid.html:10 > + let offer; offer seems unused. Will remove in next iteration.
Created attachment 291087 [details] Updated patch
Comment on attachment 291087 [details] Updated patch Thanks Eric
Comment on attachment 291087 [details] Updated patch Clearing flags on attachment: 291087 Committed r207052: <http://trac.webkit.org/changeset/207052>
All reviewed patches have been landed. Closing bug.