iOS无服务器WebRTC（Multipeer Connectivity）疑问及视频异常咨询

我来逐个解答你的问题，都是WebRTC + Multipeer开发中常见的坑：

首先得明确这里的「无服务器」指的是不需要你维护自己的后端服务，而不是完全不依赖任何公共服务器。

STUN服务器（比如stun:stun.l.google.com:19302）的作用非常有限：它只是帮设备获取自己的公网IP地址和端口（Server Reflexive Candidate），或者在NAT环境下辅助打洞，让两个设备能找到彼此。但STUN不会存储任何你的业务数据，也不会转发媒体流——所有的音视频数据还是在设备之间点对点传输的。

而这款应用用Multipeer Connectivity框架解决了信令问题（设备发现、配对、SDP/ICE消息传递），不需要你自己搭建信令服务器；媒体流是点对点的，也不需要TURN中转服务器（除非跨复杂NAT，但同局域网下根本用不到）。所以说它是「无服务器」是合理的——你不需要部署和维护任何自己的服务器，只依赖公共的STUN（很多WebRTC应用都会默认用谷歌的公共STUN，这是行业惯例）。

同局域网下出现黑屏，本地正常，说明媒体采集没问题，问题大概率出在连接建立或媒体传输环节，给你几个排查方向：

• 权限问题：iOS 9和10对隐私权限要求很严格，检查两台设备是否都授权了相机、麦克风、网络（包括Multipeer的本地网络权限）。如果其中一台设备没授权相机，远程就收不到视频流；没授权网络的话，Multipeer甚至没法建立连接。
• ICE候选收集不完整：同局域网下，WebRTC应该优先使用「Host Candidate」（局域网IP），如果你的代码里强制使用STUN获取的候选，或者ICE收集过程中没拿到Host Candidate，可能导致连接失败。可以打印ICE候选列表，看看有没有局域网的IP地址。
• SDP协商问题：检查SDP里的媒体编码格式是否兼容。iOS 9和10的H.264编码Profile可能有差异，比如一台设备只支持Baseline，另一台用了Main Profile，导致解码失败。可以在SDP里查看a=rtpmap字段，确认编码格式一致。
• Multipeer信令传递丢包：Multipeer的sendData(_:toPeers:with:)方法有数据大小限制（大概1MB左右），如果SDP或ICE消息太大没做分片，就会发送失败，导致对方收不到信令，无法完成连接建立。可以检查信令发送的回调，看看有没有失败的情况。
• WebRTC版本兼容性：如果你用的是较新的WebRTC预编译库，可能已经放弃了对iOS 9/10的支持，导致旧系统上无法正常处理媒体流。建议换成兼容旧系统的WebRTC版本试试。

这得看你的应用场景，不能一概而论，我给你分析下优缺点：

优点： #

• 快速原型开发：Multipeer已经封装了设备发现、配对、点对点数据传输，你不需要自己写信令服务器的逻辑，能快速搭建起局域网内的音视频通话原型。
• 局域网内高效：同一WiFi下，Multipeer直接走本地点对点连接，延迟极低，不需要经过外部服务器，体验很好。
• Apple生态内无缝集成：如果你的应用只针对iOS/macOS用户，Multipeer的配对体验（比如AirDrop式的弹窗）比自定义信令更符合用户习惯。

缺点： #

• 平台局限性：Multipeer是Apple专属框架，一旦结合WebRTC，你的应用就只能在Apple设备之间使用，完全丧失了WebRTC跨平台（Android、Web、Windows等）的优势。
• 连接范围有限：Multipeer只能在同一局域网或蓝牙范围内发现设备，无法实现跨互联网的远程通话（除非额外结合STUN/TURN和自己的信令服务器，但这样就失去了「无服务器」的意义）。
• 扩展性差：Multipeer最多支持同时连接8个设备，对于需要多人通话的场景来说不够用。
• 调试难度高：Multipeer的信令流程是黑盒，出现连接问题时很难排查，而自定义信令服务器可以更灵活地日志和调试。

总结：如果你的应用是局域网内的Apple设备专属音视频工具，这个方案很合适；但如果需要跨平台、跨互联网，或者扩展性要求高，还是建议自己搭建信令服务器，用纯WebRTC方案。

内容的提问来源于stack exchange，提问作者Parvez Qureshi