[webrtc-pc] Clarification around msid generation (#2782)

k0nserv has just created a new issue for https://github.com/w3c/webrtc-pc:

== Clarification around msid generation ==
[RFC 8829](https://datatracker.ietf.org/doc/html/rfc8829)(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#c_ts1658153872


Any guidance would be helpful 

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2782 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 10 October 2022 14:54:12 UTC