- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Jul 2020 12:55:02 +0000
- To: public-webrtc-logs@w3.org
Forgive me if I'm still confused, I'm trying to reply based on my understanding. Even if the SFU uses a custom protocol, the the client (browser endpoint) needs to perform setRemoteDescription, which means either the SFU or the client is constructing SDP. The entity that is constructing the SDP needs to know the index. And if it is powerful enough to generate SDP, it needs to know the m= line index in order to do its job anyway. - Option A: If the SFU is constructing the SDP, it seems the m= line index is known by the SFU, and client and SFU can correlate transceivers by mid. So this would be a non issue, but also a case you want to avoid due to latency if I understand correctly? - Option B: If the client is constructing the SDP, it seems the m= line index is already known by the client, or else it couldn't have constructed the SDP in the first place. > So the real problem is, someone joins the conference and provides one additional video stream to the conference - no other changes - how do you configure the client to start receiving that stream? You need valid remote SDP, and it sounds to me like the client is generating it. Because SDP needs to be consistent between offer/answer rounds, you would need a "virtual remote endpoint" that is generating SDP consistently between O/As. You could generate SDP to add an additional m= line for the new stream, or it could be more intelligent and reuse old m= lines that have become inactive, I think it is up to this "virtual endpoint" that understands and generates SDP. So I don't quite understand why on top of this, you would then also need to parse the SDP after setting it? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/44#issuecomment-661021571 using your GitHub account
Received on Monday, 20 July 2020 12:55:07 UTC