WebRTC offer 和 answer 有什么区别？答案

【问题标题】：What is the difference between WebRTC offer and answer?WebRTC offer 和 answer 有什么区别？
【发布时间】：2020-11-26 06:37:10
【问题描述】：

我正在尝试将使用 WebRTC 的音频/视频聊天功能添加到现有的文本聊天应用程序中。聊天室参与者已经在聊天，但是当他们决定需要音频/视频时，他们按下按钮开始音频/视频。无论哪个客户端按下按钮，我都会调用myPeerConnection.createOffer().then(function(offer){setLocalDescription(offer)}，然后将offer（JSON.stringified）与客户端ID 一起发送到服务器。在X 秒后，我禁用加入音频/视频聊天的按钮，向服务器发送通知以将所有offers 分发给参与者。此时，所有愿意加入音频/视频聊天的客户端都拥有来自所有剩余对等方的一整套 SDP。

我的问题是，我需要为每个客户的每个报价发送答案吗？我的理解是 SDP 描述了客户端处理音频/视频的能力。我可以使用其他人提供的 SDP 给setRemoteDescription(SDP) 吗？我遇到的所有示例、教程、问题和帖子都使用了 offer/answer 的范式，并且没有一个人在谈论 offer 和 answer 之间的区别。任何信息或指针表示赞赏。

这是从我的代码简化的jsFiddle 代码段。请查看控制台输出，它只显示媒体功能。所有可能区分 SDP 的 ICE 和网络信息都来自交换此提议 SDP 和答案之后，因此这还不是通过信令通道完成的此提议（和答案）交换的一部分。

PS：严格来说，我的场景没有任何启动通道的发起者或发送者。所有参与者都是平等的。也没有办法确定或排序它们。当功能和网络信息正确交换后，它们就会开始音频/视频聊天。

【问题讨论】：

标签： javascript video-streaming webrtc p2p sdp

【解决方案1】：

SDP 包含一些对所有参与者都相同的元素，例如支持的编解码器。还有其他特定于 peerconnection 实例的元素（或者更确切地说是行）。特别是候选冰（ip/port）和冰-ufrag/冰-pwd。这些不能在对等连接之间共享。

（部分是实现细节；参见 webrtc forking group interim meeting slides/recording on ice-forking）

【讨论】：

感谢您的链接。 ICE 信息不是通过信令通道完成的提议/答案交换的一部分。请检查我为说明调用.createOffer() 时的SDP 内容而制作的jsFiddle。刚刚调用 createOffer() 后，SDP 没有关于 ICE/IPs/Ports 的信息，这些信息将发送给对等体，并且对等体生成的应答 SDP 也没有这些信息。据我所知，调用 createOffer() 和 createAnswer() 方法时不需要 ICE（STUN/TURN 服务器信息）。
ice-ufrag 和ice-pwd 是信令信息的一部分。候选人需要在某个时候收到信号才能建立联系。
抱歉这个新手问题，但我无法弄清楚这个OFFER SDP中的哪个部分是ufrag/pwd。 "OFFER: v=0 o=- 7352028919973714015 2 IN IP4 127.0.0.1 s=- t=0 0 a=msid-semantic: WMS " ANSWER SDP 也是如此。除了信号发送过程中的“类型”之外，我看不到提供和回答之间的任何区别。我不知道我的 SDP 对象是否丢失了某些东西，但这是在 ICE 出现之前在我的情况下在信令期间交换的内容。如果我在此 SDP 中遗漏了一些值，请提出建议。