如何使用Unity官方WebRTC实现视图共享及为RTCServer设置ID标识

你拆分后无法连接的核心原因不是RTCConfiguration的ID标识问题，官方示例本身的实现是单进程内模拟双Peer，所有SDP协商、ICE候选交换都是在同一个进程内存里直接调用传递的，拆分到两个独立设备之后，缺少了跨设备的信令交换通道，这才是连接失败的首要原因。
同WLAN场景下若你的设备无法访问谷歌服务，示例默认配置的谷歌STUN服务器无法连通，也会导致ICE候选收集失败，属于次要影响因素。

1. 调整RTCConfiguration适配局域网场景 #

同WLAN下设备都在同一个子网，不需要公网穿透，可以简化ICE配置，避免外网访问限制导致的ICE收集失败：

private static RTCConfiguration configuration = new RTCConfiguration
{
    // 同局域网下可以留空，优先采集本地内网IP即可完成候选匹配
    iceServers = new RTCIceServer[] {}
    // 如果确实需要STUN服务，优先使用国内可用的公共STUN，替代谷歌的不可用地址
    // iceServers = new[] {new RTCIceServer {urls = new[] {"stun:stun.miwifi.com:3478"}}}
};

2. 补充跨设备信令通道 #

你需要在推流端和接收端之间加一个简单的信令传输层，用来传递SDP（Offer/Answer）和ICE候选，同局域网下可以用UDP广播或者TCP直连实现，逻辑如下：

• 推流端逻辑：
  • 调用CreateOffer生成Offer SDP后，通过信令通道发送给接收端
  • 本地生成ICE候选后，通过信令通道发送给接收端
  • 收到接收端返回的Answer SDP后，调用SetRemoteDescription设置
  • 收到接收端发来的ICE候选后，调用AddIceCandidate添加
• 接收端逻辑：
  • 收到推流端发来的Offer SDP后，调用SetRemoteDescription设置
  • 调用CreateAnswer生成Answer SDP后，通过信令通道返回给推流端
  • 本地生成ICE候选后，通过信令通道发送给推流端
  • 收到推流端发来的ICE候选后，调用AddIceCandidate添加
  • 监听OnTrack事件，接收音视频轨道并渲染

3. 拆分原有代码逻辑 #

把原来单进程里的Local Peer和Remote Peer逻辑分别拆分到两个项目：

• 推流端只保留原有pc1Local相关逻辑，删除所有Remote Peer的代码
• 接收端只保留原有pc1Remote相关逻辑，删除所有Local Peer和推流相关的代码

4. 运行环境检查 #

打包运行时要确保两台设备的系统防火墙允许你的Unity程序访问网络，且都连接到同一个WLAN，子网IP可以互相ping通。

内容的提问来源于stack exchange，提问作者Li Ziming