W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2018

[webrtc-pc] Multiple SRDs may leave streams and tracks in unexpected state.

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Mon, 22 Jan 2018 21:23:41 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-290620037-1516656220-sysbot+gh@w3.org>
jan-ivar has just created a new issue for https://github.com/w3c/webrtc-pc:

== Multiple SRDs may leave streams and tracks in unexpected state. ==
In https://github.com/w3c/webrtc-pc/issues/1729#issuecomment-356787787 I mention stream associations in theory can change between multiple SRD calls.

There's an issue even if we don't mangle SDP:

* If the first SRD described a new track A in stream S, but the second (corrective) SRD didn't, you wouldn't expect to find track A being part of stream S, especially if you're already playing S.

You might not expect `pc.getTransceivers()` to grow at all, but that's JSEP (use rollback for that).
You might not expect a `track` event, but we agreed that's hard to avoid in https://github.com/w3c/webrtc-pc/issues/1729.

But at least, you'd expect track A to be muted, and not part of stream S.

The muted state is likely not an issue since we never set it to false, so that part of the algorithm can probably stay as it is (dependent on delta-comparison against [[CurrentDirection]]) .

But as I mentioned in https://github.com/w3c/webrtc-pc/issues/1729#issuecomment-356787787 I think we should lift the call to [set the associated remote streams](http://w3c.github.io/webrtc-pc/#set-associated-remote-streams) out one level, basically always call it with the msids (or empty list if send-bit is off).

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1744 using your GitHub account
Received on Monday, 22 January 2018 21:23:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:58 UTC