这个问题我之前帮同行排查过类似场景，结合AppRTC特性和WebRTC的网络机制，大概率和ICE候选集处理、STUN/TURN配置或者iOS系统兼容性有关，给你几个具体的排查和解决方向：

• 检查STUN/TURN服务器的有效性与配置
  公网下两台iOS设备无法连通，很多时候是NAT穿透失败导致的——如果两台设备都在对称NAT后面，STUN根本无法穿透，必须依赖TURN服务器中转。AppRTC默认的appr.tc服务器的TURN资源可能存在并发限制或地域访问限制，导致iOS设备无法获取到可用的relay候选。
  建议你：

  1. 自己部署一套开源TURN服务器（比如coturn），配置好公网IP和认证信息；
  2. 在AppRTC的iOS客户端代码中，替换默认的STUN/TURN配置，指定你自己的服务器地址；
  3. 通过WebRTC日志查看ICE候选收集情况，确认是否生成了relay类型的候选（TURN候选）。

• 调整ICE候选的筛选与优先级策略
  AppRTC的iOS端对ICE候选的优先级处理可能和Android/web端不同，公网下可能优先选择了无法连通的host候选（本地局域网地址），而没有及时切换到relay候选。
  你可以：

  1. 查看AppRTC源码中RTCIceCandidate的排序逻辑，尝试提高relay候选的优先级；
  2. 确保开启Trickle ICE模式，让客户端逐步收集并尝试候选，而非等待全部候选收集完成再建立连接，这样能更快找到可用的连通路径。

• 排查iOS系统权限与WebRTC框架兼容性
  iOS的隐私权限和网络配置可能影响WebRTC的音视频传输：

  • 确认Info.plist中已经添加了NSCameraUsageDescription和NSMicrophoneUsageDescription权限描述，且用户已授予音视频权限；
  • 检查设备的蜂窝数据权限是否开启（部分用户会关闭App的蜂窝数据访问）；
  • 尝试更新AppRTC依赖的WebRTC框架到最新稳定版，旧版本WebRTC可能和新iOS系统存在兼容性问题，导致公网连接异常。

• 通过WebRTC日志与Stats定位具体问题
  开启详细的WebRTC日志是排查问题的关键：

  • 在iOS代码中设置RTCLogLevel为verbose，通过Xcode控制台查看ICE连接状态、候选收集情况以及媒体流的发送/接收日志；
  • 使用WebRTC的Stats API获取连接状态，比如查看iceConnectionState是否为connected，音视频流的bytesSent和bytesReceived是否有数据流动，以此判断是ICE连接失败还是媒体流传输异常。

• 验证NAT类型的兼容性
  不同NAT类型的穿透难度不同，对称NAT是最难穿透的类型。如果两台iOS设备都处于对称NAT环境下，必须依赖TURN服务器中转。
  你可以用WebRTC的NAT测试工具检测两台设备的NAT类型，如果都是对称NAT，确保你的TURN服务器配置正确，且客户端能正常获取到TURN候选。

内容的提问来源于stack exchange，提问作者Shourob Datta