基于 P2P 的解决方案更喜欢使用 SIP 或 XMPP (Jingle) 进行信令
这只是一个开始，我在 P2P 方面进行更多探索，并在可扩展性或其他任何方面寻找原因：SIP 或 XMPP (Jingle) 用于以下用例：
P2P 客户端应用程序能够在所有网络遍历场景中执行文件传输。
// 对于信令（例如，连接/定位/断开对等点），XMPP (Jingle) 或 SIP 均可用。
我可以知道使用什么的可能原因以及为什么吗？有什么实际用途吗？例如;可扩展性或任何对上述用例真正产生影响的东西
It’s just a start where I am exploring more in P2P side, and finding reasons in terms of Scalability or anything else for : SIP or XMPP (Jingle) for following use case :
P2P Client Application Capable to perform File Transfer on all Network Traversal Scenarios.
// For Signaling (e.g.; to connect/locate/disconnect peers) both XMPP (Jingle) or SIP are available.
May I know possible reasons to use what and why? Any practical use? e.g.; Scalability or anything which really makes a difference for the above Use Case
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Jingle 是一个 XMPP 扩展来处理多媒体会话。实际上，Jingle 相当于 SIP 的 XMPP。
就 P2P 文件应用程序而言：
就可扩展性而言，Jingle 和 SIP 大致相当。两者都将信令和媒体分开，通过服务器端组件的部署方式提供了更大的灵活性（因此也变得更加复杂）。
XMPP/Jingle 具有更好的安全设计，使得使用 SSL 信令层强制客户端更加实用。 SIP 确实支持 SSL，但它更复杂，而且在现实世界中也没有得到广泛支持，
就 NAT 而言，两者都会遇到同样的问题。当涉及 NAT 时，通过独立的信令和媒体路径获得的可扩展性就会发挥作用。有几种不同的机制来处理 NAT，最新的尝试是 ICE。 ICE 是尝试解决不同 NAT 配置的不同机制的集合，值得注意的是，并非所有配置都可以解决，后备方法是使用媒体代理服务器，例如 转向。
如果我是您，我会使用 XMPP，但在开始之前我会弄清楚需要支持哪些 NAT 配置。如果您需要从互联网上的任何地方支持任意客户端，那么您将无法始终能够在客户端之间建立直接的 P2P 通信，而这正是您将面临的最大挑战。
Jingle is an XMPP extension to handle multimedia sessions. In effect Jingle is the XMPP equivalent of SIP.
As far as a P2P file application goes:
Jingle and SIP are roughly equivalent as far as scalability goes. Both separate the signalling and media providing more flexibility (and consequently complications) with the way server side components can be deployed.
XMPP/Jingle has a better security design making it much more practicable to enforce clients using an SSL signalling layer. SIP does support SSL but it's more convoluted and also doesn't enjoy widespread support in the real World,
As far as NAT goes you're going to have the same problems with both. The scalability you get from having separate signalling and media paths comes back to bite when NAT is involved. There are a few different mechanisms to deal with NAT the latest attempt is ICE. ICE is collection of different mechanisms to try and resolve different NAT configurations and it's worth bearing in mind that not all configurations can be resolved and the fallback is to use a media proxying server such as TURN.
If I was you I'd use XMPP but before starting I'd work out exactly what NAT configurations need to be supported. If you need to support arbitrary clients from anywhere on the internet then you will not be able to rely on always being able to establish direct P2P communications between your clients and that's where you will face your biggest challenge.