Bug 192101 - [Unified Plan] Calling addTransceiver a second time with the same MediaStreamTrack generates a different MSID for the second m= section.
Summary: [Unified Plan] Calling addTransceiver a second time with the same MediaStream...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-28 13:49 PST by Manjesh Malavalli
Modified: 2018-11-28 16:53 PST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Manjesh Malavalli 2018-11-28 13:49:04 PST 
Steps to reproduce the problem:
• Run https://jsfiddle.net/1hu2gLvz/ in a new tab.
• Click on "Add the same audio track the second time".
• Observe JavaScript console.

What is the expected behavior?
MSID in the sdp should match the MediaStreamTrack's ID for both m= sections.

What went wrong?
MSID in the sdp does not match the MediaStreamTrack ID in the second m= section.
Comment 1 youenn fablet 2018-11-28 14:08:06 PST 
Thanks for the report Manjesh,

I do not think that the mapping between msid and track ids is guaranteed anymore.
See for instance https://github.com/w3c/webrtc-pc/issues/2005.

The only meaningful part on msid is the media stream id part.

I will close this one as WontFix.
Please reopen if needed.

Is it causing issues on your side?
Comment 2 Manjesh Malavalli 2018-11-28 16:53:02 PST 
Hi Youenn,

Yes. Because of this issue, it is not possible to map our application-level Tracks with the underlying MediaStreamTracks. We have tackled this issue in our newer versions by always cloning MediaStreamTracks before adding them to PeerConnections, but we still need to support older versions for some time.

- Manjesh