1

After a WebRTC session has been established, I would like to stop sending the stream to the peer at some point and then resume sending later.

If I call removeStream, it does indeed stop sending data. If I then call addStream (with the previously removed stream), it resumes. Great!

However, is this safe? Or do I need to re-negotiate/exchange the SDP after the removal and/or after the re-add? I've seen it mentioned in several places that the SDP needs to be re-negotiated after such changes, but I'm wondering if it is ok in this simple case where the same stream is being removed and re-added?

PS: Just in case anyone wants to suggest it: I don't want to change the enabled state of the track since I still need the local stream playing, even while it is not being sent to the peer.

logidelic
  • 1,525
  • 15
  • 42
  • Can you clarify what you mean by "safe"? Not sure what you're asking. – jib Feb 16 '17 at 22:56
  • Based on your answer, you knew what I was asking. :) Safe, as in, is it legitimate or is it a fluke that it works. – logidelic Feb 17 '17 at 15:27

1 Answers1

4

It will only work in Chrome, and is non-spec, so it's neither web compatible nor future-proof.

The spec has pivoted from streams to tracks, sporting addTrack and removeTrack instead of addStream and removeStream. As a result the latter isn't even implemented in Firefox.

Unfortunately, because Chrome hasn't caught up, this means renegotiation currently works differently in different browsers. It is possible to do however with some effort.

The new model has a cleaner separation between streams and what's sent in RTCPeerConnection.

Instead of renegotiating, setting track.enabled = false is a good idea. You can still play a local view of your video by cloning the track.

Community
  • 1
  • 1
jib
  • 40,579
  • 17
  • 100
  • 158