javascript WebRTC：如何在提供和回答后添加流？

WebRTC: How to add stream after offer and answer?

提问by Konga Raju

I am working on webRTC video calling. I got datachannel successfully implemented. Now I would like to add video stream to the same peer connection.

我正在开发 webRTC 视频通话。我成功实现了数据通道。现在我想将视频流添加到同一个对等连接。

I have read that stream should be added before answer and offer. Is there a way to add stream after answer or offer?

我已经读过应该在回答和提供之前添加流。有没有办法在回答或提供后添加流？

In case I have added stream before offer or answer, how could I stop streaming and start it again when needed?

如果我在提供或回答之前添加了流，我怎么能停止流并在需要时重新启动它？

Could there be any issues in maintaining so many streams?

维护这么多流会不会有什么问题？

采纳答案by Konga Raju

To add stream after creating complete signalling, the Peer connection should renegotiatewith stream.

要在创建完整信令后添加流，对等连接应与流重新协商。

pc1.addstream(stream)

Then once again create offer and send it to other Peer.

然后再次创建报价并将其发送给其他 Peer。

Remote peer will add stream and send answer SDP.

远程对等体将添加流并发送应答 SDP。

To stop streams:

要停止流：

stream.stop();
pc1.removeStream(stream);

回答by sandover

In my experience, what Konga Raju advised didn't work. I couldn't send an "updated offer" and have the video streaming actually happen.

根据我的经验，Konga Raju 的建议行不通。我无法发送“更新的报价”并让视频流实际发生。

I found that this sequence of events works for my case, in which I wish to stream video from peer 1 to peer 2.

我发现这一系列事件适用于我的情况，在这种情况下，我希望将视频从对等 1 传输到对等 2。

1. set up some way for the peers to exchange messages. (The variance in how people accomplish this is what makes different WebRTC code samples so incommensurable, sadly.)
2. On each side, set up handlers for the important signalling events. (Some folks have reported that you need to create these handlers at special times, but I haven't found that to be the case. ) There are 3 basic events:
   • an ice candidate sent from the other side ==> call addIceCandidatewith it
   • an offer message ==> SetRemoteDescription& make an answer & send it
   • an answer message ===> SetRemoteDescription
3. On each side, create the peerconnection object with the event handlers we care about: onicecandidate, onremovestream, onaddstream, etc.
   • ice candidate pops out of the peerconnection object ===> send it to other side
4. When both peers are present and all the handlers are in place, peer 1 gets a trigger message of some kind to start video capture (the getUserMediacall)
5. Once getUserMediasucceeds, we have a stream. Call addStreamon the peer connection object.
6. Then peer 1 makes an offer
7. Due to the handlers we set up earlier, peer 2 sends an answer
8. Concurrently with this (and rather opaquely), the peer connection object starts producing ice candidates. They get sent back and forth between the two peers and handled (steps 2 & 3 above)
9. Streaming starts by itself, opaquely, as a result of 2 conditions:
   • offer/answer exchange
   • ice candidates received, exchanged, and handled

1. 为对等方设置某种方式来交换消息。（令人遗憾的是，人们如何实现这一点的差异使得不同的 WebRTC 代码示例如此不可通约。）
2. 在每一侧，为重要的信号事件设置处理程序。（有些人报告说您需要在特殊时间创建这些处理程序，但我没有发现这种情况。）有 3 个基本事件：
   • 从另一方发送的冰候选人 ==>addIceCandidate用它调用
   • 报价信息 ==>SetRemoteDescription并做出答复并发送
   • 回复信息 ===> SetRemoteDescription
3. 在每一侧，使用我们关心的事件处理程序创建 peerconnection 对象：onicecandidate、onremovestream、onaddstream 等。
   • ice 候选对象从 peerconnection 对象中弹出 ===> 将其发送到另一端
4. 当两个对等点都存在并且所有处理程序都到位时，对等点 1 会收到某种触发消息以开始视频捕获（getUserMedia调用）
5. 一旦getUserMedia成功，我们就有了一个流。调用addStream对等连接对象。
6. 然后 peer 1 提出要约
7. 由于我们之前设置的处理程序，peer 2 发送了一个答案
8. 与此同时（并且相当不透明），对等连接对象开始生成 ice 候选对象。它们在两个对等点之间来回发送并处理（上面的第 2 步和第 3 步）
9. 由于 2 个条件，流式传输本身不透明地开始：
   • 提供/答复交换
   • 接收、交换和处理的冰候选人

I haven't found a way to add video after step 9. When I want to change something, I go back to step 3.

在第9步之后我还没有找到添加视频的方法。当我想改变一些东西时，我回到第3步。

回答by Vinay

MediaStream should be added to peerconnection first only then exchange of offer, answer ,candidates should be done. If the onAddStream() is called ,that mean you are receiving the remote video.

MediaStream 应首先添加到对等连接中，然后才应交换报价、回答、候选人。如果 onAddStream() 被调用，则意味着您正在接收远程视频。