search

w3c / webrtc-pc

WebRTC 1.0 API
https://w3c.github.io/webrtc-pc/
Other
437 stars 115 forks source link

Clarification around msid generation #2782

Open k0nserv opened 1 year ago

k0nserv commented 1 year ago

RFC 8829(JSEP) says

  For RtpTransceivers that are not stopped, the "a=msid" line or
  lines MUST stay the same if they are present in the current
  description, regardless of changes to the transceiver's direction
  or track.  If no "a=msid" line is present in the current
  description, "a=msid" line(s) MUST be generated according to the
  same rules as for an initial offer.

How should this be interpreted? It sounds like it's saying, that after the first negotiation where a track is present is complete any change to the streams associated with that track are frozen, i.e., any changes will not be reflected in offers.

However, this seems to conflict with the RTCRtpSender.setStreams method its purpose modifying the streams of an existing RTCPRtpSender. Given the above interpretation of the RFC it would mean that any calls to setStreams have no observable effect on the remote side after the first negotiation that included the sender's transceiver.

There are further details on the Chromium issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=1342010

Any guidance would be helpful

jan-ivar commented 1 year ago

I agree with the discussion in the Chromium tracker that it looks like RFC 8829 wasn't updated when setStreams was added, as further evidenced by paragraphs like this one:

      -  For each MediaStream that was associated with the transceiver
         when it was created via addTrack or addTransceiver, an "a=msid"
         line, as specified in [RFC8830], Section 2, but omitting the
         "appdata" field.

...which doesn't account for: pc.addTrack(track).setStreams(stream).

As further mentioned in the Chromium tracker, since the introduction of mid, and with appdata now omitted, msid is AFAIK relegated to surfacing stream associations remotely (which can change with setStreams), with the stable identifier instead being mid.

@docfaraday can we file an errata on the RFC?

fippo commented 10 months ago

@alvestrand we need a spec decision on this one to determine the fate of the crbug