Screensharing Issue about webrtc-experiment

[zdfs]

I think I need to have a webrtc connection for every stream type. Data, audio, video, and screen each get their own connection. Does that approach have merit, in your opinion?

[muaz-khan]

I think I need to have a webrtc connection for every stream type. Data, audio, video, and screen each get their own connection. Does that approach have merit, in your opinion?

It is useful only if you want to share screen along with audio and video. One peer can be negotiated for audio/video and one for screen.

It is true that multiple streams attachment is supported since long time; however video along with screen in a single peer connection still fails (out of duplicate video m-lines or overriding old m-line). Though, it is expected to be fixed in near future; where one m-line will have multiple streams.

Possible Scenarios

1. If you're sharing audio-only stream; you can renegotiate any other stream except a duplicate audio stream.
2. If you're sharing audio/video streams; you can renegotiate any other stream except a duplicate audio or video stream; screen capturing is also listed in video m-line; that's why renegotiation process fails.
3. If you're sharing data-only stream; you can renegotiate any other stream.

In last case; old data m-line can be overridden.

Sometimes overriding process works without any failure; however old streams will be stopped flowing.

...right now, I'm just trying to test this with two windows in Google Chrome, and I'm not sure if that's contributing to the issue...

Chrome doesn't allow multiple screen capturing requests per system; even if you're using two unique tabs or windows. That's why you should try oneway:true.