1322998 - RTCPeerConnection: InvalidSessionDescriptionError: "Found multiple different webrtc msids in m-section 2. The behavior here is undefined.

Status: RESOLVED DUPLICATE of bug 1290948

(Core :: WebRTC: Networking, defect, P3)

Description

[mparisdiaz]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161130094234

Steps to reproduce:

Setting a remote description with more than one msid attr in a m-line like this:
v=0
...
m=audio
...
m=video
...
a=msid:{efcbec74-1032-416f-9533-6f8badc879e6} {f0c8ebb8-dca1-4d08-8e58-47e6e5976a8c}
a=msid:{64eee22f-dd4f-4000-b7e4-d1ed61137309} {f0c8ebb8-dca1-4d08-8e58-47e6e5976a8c}
...


Actual results:

I get the next error:
DOMException [InvalidSessionDescriptionError: "Found multiple different webrtc msids in m-section 2. The behavior here is undefined."
code: 0


Expected results:

Multiple msid attrs must be supported as defined in [1]:

   There may be multiple msid attributes in a single media description.
   This represents the case where a single MediaStreamTrack is present
   in multiple MediaStreams; the value of "msid-appdata" MUST be
   identical for all occurences.

Refs[1] https://tools.ietf.org/html/draft-ietf-mmusic-msid-15#section-2

Comment 1

[Nils Ohlmeier [:drno]]

Looks like we implemented only the draft up to revision 10, and from 11 on forward a track can be present in multiple streams.

Byron do you know if we just need to add the signaling logic for this, or does this require bigger changes to clone a single RTP stream into multiple MediaStreams?

Comment 2

[Byron Campen [:bwc]]

That text doesn't make any sense; multiple msid in a given m-section has nothing to do with having the same track in multiple streams, it is used when you want multiple tracks per stream. Also, the MSID spec does not say that multiple msid MUST be supported. Lastly, the JSEP draft explicitly says there are 0 or 1; it does not allow for multiple.

Comment 3

[mparisdiaz]

Hello Byron,
the way of specifying that a track is in multiple streams is having multiple "a=msid" attrs in the same m-line, and this is supposed to be supported by the specs [1]. Maybe JSEP is not properly updated...

Multiple track per stream is signaled adding "a=msid" attr in different m-lines with the same msid-id and different msid-appdata.

Refs
[1] https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtrack

Comment 4

[Byron Campen [:bwc]]

The text at https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtrack specifies that reusing an existing  RTCRtpTransceiver (ie; m-section) requires that its RTCRtpSender does not presently have a track. That implies that there will be at most one msid in the m-section.

Comment 5

[mparisdiaz]

addTrack [1] receives a list of MediaStreams associated to the MediaStreamTrack.
This is clearly related to support ultiple msid attrs in the same m-line [1]:

   There may be multiple msid attributes in a single media description.
   This represents the case where a single MediaStreamTrack is present
   in multiple MediaStreams; the value of "msid-appdata" MUST be
   identical for all occurences.


Refs
[1] https://www.w3.org/TR/webrtc/#rtcpeerconnection-interface-extensions
[2] https://tools.ietf.org/html/draft-ietf-mmusic-msid-15#section-2

Comment 6

[Byron Campen [:bwc]]

(In reply to mparisdiaz from comment #5)
> addTrack [1] receives a list of MediaStreams associated to the
> MediaStreamTrack.
> This is clearly related to support ultiple msid attrs in the same m-line [1]:

   That has nothing to do with m-sections. When a track is added to multiple media streams with addTrack, each stream/track pairing gets its own m-line, according to the W3C spec and the JSEP spec.

   If you want to dispute what the spec _should_ say, that's fine, but this is not the place to do it. Just be aware, this very argument played out years ago (plan B and unified plan), and everyone involved is now sick of that debate.

Comment 7

[mparisdiaz]

Byron,
what I interpret from specs is that a track is only related to an unique m-line, there is not a m-line per each stream/track pairing as you are saying.
In addition, if I do not misunderstand this sentence, it is saying the same:

   There may be multiple msid attributes in a single media description.
   This represents the case where a single MediaStreamTrack is present
   in multiple MediaStreams; the value of "msid-appdata" MUST be
   identical for all occurences.

Anyway, I might have lost something. Could you please point me to the section of the spec that says what you are interpreting?

Thanks!!

Comment 8

[Nils Ohlmeier [:drno]]

Probably the best documentation you can find about the unified vs plan B battle is this older blog post https://hacks.mozilla.org/2015/06/firefox-multistream-and-renegotiation-for-jitsi-videobridge/

I contacted Harald to check if the cited paragraph allowing multiples msid's per m-line is an oversight or left in on purpose for something outside of WebRTC's unified plan. I'll happily reported back once I hear something from Harald.

Comment 9

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.