Re: draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0

> 
> In the current state of WebRTC 1.0, track IDs are not guaranteed to be symmetrical between the sending and receiving PeerConnection. This is because "addTrack" not only creates an RtpSender, but a whole RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with a generated ID. So if "addTrack" is called, and a remote description is set later, it's the MID that correlates the "m=" section with the track, not the track ID, and the track ID in SDP is effectively ignored.

I'm not following the problem here ... yes, webrtc ends up with the track from A to B and B to A having different track IDs but the msid draft clearly allows the offer and answer to have different app data in the MSID line. What's the issue on this?


PS - As side note, I've argued since before 2013 that we did not need to signal track ID in SDP but I think that train left the station long ago and I'd rather not change it at this point. The mostly compelling argument I recall on why we need this was hangouts uses it.