blocks|key|4710328|text|是。只要每个客户端收到另一个客户端的SDP+(包括候选ICE+)，您就应该能够建立PeerConnection。WebRTC与应用程序开发人员采用的信令机制解耦。但必须传输这些信号，以便每个客户端知道它应该注意哪个IP端口组合。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4710329|现在，请求用户手动交换和处理这些信号可能会变成一项乏味的任务。我建议使用Socket.io设置一个简单的服务器，它可以让你轻松地传递信号。你也可以随时使用AJAX轮询。|4710330|entityMap|0|LINK|mutability|MUTABLE|url|http://socket.io/#how-to-use^0|15|E|0|10|9|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|S|8|@]|D|@$9|T|A|U|1|V]]|E|$]]|$1|H|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

Yes. As long as each client receives the other client's SDP (which includes the ICE Candidates), you should be able to establish a <code>PeerConnection</code>. WebRTC is decoupled from the Signalling mechanism the application developers adopt. But it is imperative that these signals are transmitted, so that each client knows which IP-Port combination it should be paying attention to.

Now requesting the users to manually exchange and process these signals might turn out to be a tedious task. I'd recommend setting up a simple Server using <a href="http://socket.io/#how-to-use" rel="nofollow">Socket.io</a> that would let you relay the signals with ease. You can always use AJAX Polling too.

blocks|key|877122|text|是的，你可以通过电子邮件或任何其他传输方式发送它。我不认为对用户来说结果会是最好的，但这是一种方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|877123|我要向您解释的是，收到SDP提议的用户必须在浏览器中输入该提议，获取SDP答案，然后将其发送回发起请求的用户。但我假设当你说它在本地工作时，你正在做所有的事情。|877124|您也必须等待ICE候选人，因为您只发送一次提议和答案，以便允许对等连接。|877125|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Yes you can send it over email or any other transport. I don't think the result for the user will be the best, but it's one way to do it.

I would explain to you that the user that receives the SDP offer, must enter it in the browser, get the SDP answer, and send it back to the user that started the request. But I assume that when you say it works locally, you are doing all that.

You must wait for the ICE candidates too, as you are sending the offer and answers one time only, in order to allow peers to connect.

blocks|key|203474|text|是。一些有趣的点是setLocalDescription()、setRemoteDescription()、createOffer()和createAnswer()。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|203475|这里有一个概念验证：https://github.com/cjb/serverless-webrtc/|offset|length|203476|现场演示：http://cjb.github.io/serverless-webrtc/serverless-webrtc.html|203477|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/cjb/serverless-webrtc/|1|http://cjb.github.io/serverless-webrtc/serverless-webrtc.html^0|0|A|15|0|0|5|1P|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

Yes. Some points of interest are setLocalDescription(), setRemoteDescription(), createOffer(), and createAnswer().

Here's a proof-of-concept:
<a href="https://github.com/cjb/serverless-webrtc/" rel="nofollow">https://github.com/cjb/serverless-webrtc/</a>

Live demo:
<a href="http://cjb.github.io/serverless-webrtc/serverless-webrtc.html" rel="nofollow">http://cjb.github.io/serverless-webrtc/serverless-webrtc.html</a>

blocks|key|4227745|text|不--据我所知，你不能简单地通过电子邮件发送会话描述。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4227746|ICE建立对等体之间的最佳路由，我认为ICE候选的数量可能会根据两个客户端的当前网络情况而有所不同。|4227747|如果接收到ice候选和会话描述，然后客户端移动物理位置(例如，加入不同的wifi网络)，则将使得ice候选无用-这意味着客户端无法连接。|4227748|我不是专家，所以很容易出错。这个答案来自于我在使用webrtc为2个客户端设置自己的信令系统时获得的webrtc知识。|4227749|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

No - as I understand it, you can't simply email Session descriptions.

ICE establishes the best route between peers, and I think the amount of ICE candidates may differ according to both client's current network situation.

If ice candidates and session desc are received, and then the client moves physical location (joining a different wifi network, for example), it would render ice candidates useless - meaning that the clients cannot connect.

I'm not an expert, so could easily be wrong. That answer is just from the webrtc knowledge i have gained whilst setting up my own signalling system for 2 clients using webrtc...

blocks|key|203469|text|是的你可以。SDP只是一堆文本，所以你可以选择任何你想要的媒体。SDP的一个重要部分是ICE候选，我建议将其作为SDP的一部分包括在内；因此，它都可以作为一个大字符串通过您选择的媒介(ajax、websockets等)发送。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|203470|请注意，您通过调用createOffer获得的第一个SDP将不包含ICE候选。至少要等到"onicecandidate“回调被调用一次，才能拥有一些ICE候选对象。然后在您的对等连接上再次调用createOffer，它将拥有所有信息(ICE候选人和其他SDP)。|203471|还请注意，onicecandidate将根据需要被调用任意多次，直到计算出所有本地ICE候选对象，因此您可以等待所有这些候选对象，直到生成完整的SDP提议发送到另一端。|203472|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Yes you can. SDP is just a bunch of text, so you can choose any medium you want. An important piece of the SDP are ICE candidates, which I recommend including as part of the SDP; so it can all be send as one big string over medium of your choice(ajax, websockets, etc...).

Note that first SDP that you get from calling createOffer is not going to contain ICE candidates. You have to wait until "onicecandidate" callback gets called at least once to have some ICE candidates. Then you call createOffer again on your peer connection, which will then have all information(ICE candidates plus rest of SDP).

Also note that onicecandidate will be called as many times as needed until all of the local ICE candidates are figured out, so you could wait all for all of them until then to generate a complete SDP offer to send to the other side.

blocks|key|4227898|text|免责声明:我在Pusher工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4227899|是的，你可以通过任何交通工具发送。然而，现在websockets是一个很好的选择，因为大多数browser+support+it。|offset|length|4227900|正如@Vishnu提到的，你可以设置一个socket.io服务器，或者如果你不想经历设置的麻烦，你可以使用像Pubnub或Pusher这样的托管解决方案。如果你感兴趣的话，我写了一个webRTC+signaling教程，使用Pusher和Webosckets+(%2B回退)。|4227901|http://pusher.com/tutorials/webrtc_chat|4227902|entityMap|0|LINK|mutability|MUTABLE|url|http://caniuse.com/websockets|1|http://pusher.com/|2|3^0|0|1A|I|0|0|1P|6|1|2J|G|2|0|0|13|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@$D|11|E|12|1|13]|$D|14|E|15|1|16]]|A|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@$D|18|E|19|1|1A]]|A|$]]|$1|J|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|I]]|U|$5|M|N|O|A|$P|I]]]]

disclaimer: I work at Pusher.

Yes you can send it over any transport. However, websockets is a pretty good option these day since most of the <a href="http://caniuse.com/websockets" rel="nofollow">browser support it</a>. 

As mention by @Vishnu, you can setup a socket.io server or if you don't want to go through the hassle of setting that up, you can use hosted solutions like Pubnub or <a href="http://pusher.com" rel="nofollow">Pusher</a>. I wrote a <a href="http://pusher.com/tutorials/webrtc_chat" rel="nofollow">webRTC signaling</a> tutorial using Pusher and thus Webosckets (+fallbacks) if you are interest.

<a href="http://pusher.com/tutorials/webrtc_chat" rel="nofollow">http://pusher.com/tutorials/webrtc_chat</a>

I read that RTCPeerConnection doesn't care about the transport mechanism chosen to exchange signals (websocket, google channel, etc..). Do you think it would be possible to collect those signals, encode them with JSON and ask the user to send them to the other peer using an external mechanism (chat, email, ...) in order to completely bypass the need of a remote server? 

I've done a little POC and this seems working only when both peers are on the same machine; any clue? 

Thanks!

Exchanging WebRTC RTCPeerConnection signals manually

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我读到RTCPeerConnection并不关心用来交换信号的传输机制(websocket，google channel等)。您认为是否有可能收集这些信号，使用JSON对它们进行编码，并要求用户使用外部机制(聊天、电子邮件等)将它们发送给另一个对等体？为了完全绕过对远程服务器的需要？我做了一个小的POC，这似乎只有当两个同级在同一台机器上时才有效；有什么提示吗？谢谢!

问手动交换WebRTC RTCPeerConnection信号
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问手动交换WebRTC RTCPeerConnection信号EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问手动交换WebRTC RTCPeerConnection信号
EN