WebRTC在C#中不能直接运行
WebRTC是浏览器原生支持的实时通信技术，核心实现在C++（如libwebrtc），JavaScript只是它的控制层。C#没有官方WebRTC SDK，所谓“C#集成WebRTC”，本质是调用底层libwebrtc的封装库，或通过进程/服务桥接浏览器——不是在C#里跑WebRTC协议栈。
常见误区是想找一个NuGet包
Install-Package WebRTC一装就通，实际不存在这样的纯托管实现。所有可行方案都绕不开本地二进制依赖或外部运行时。
主流可行路径：使用WebRTC.NET或SIPSorcery
WebRTC.NET（GitHub: martinoj2009/webrtc.net）是基于libwebrtc的C# P/Invoke封装，提供
PeerConnection、
MediaStream等类，但需手动编译或下载预编译的
webrtc.dll（Windows x64/x86），且仅支持 .NET 5+ 和 Windows 平台。
SIPSorcery更轻量，不依赖libwebrtc，而是用纯C#实现SIP信令 + 基于
NAudio和
FFmpeg.AutoGen处理音视频编解码与传输，适合构建SFU/MCU服务器，但不支持P2P的SDP协商全流程，浏览器端仍需自己写JS信令逻辑。 选
WebRTC.NET：需要P2P、低延迟、复用浏览器SDP流程，能接受Windows-only和DLL分发 选
SIPSorcery：需要跨平台、可控信令、接受中继架构（如用它搭TURN/STUN服务），或只需服务端媒体处理 两者都不支持直接从C#发起
getUserMedia—— 浏览器采集必须由前端JS完成
浏览器与C#后端协作的关键点
真正落地时，C#角色通常是信令服务器（Signal Server）或媒体中继（TURN/STUN），而非媒体端点。浏览器JS负责SDP生成、ICE候选收集、
RTCPeerConnection管理；C#只做消息转发或会话状态维护。
典型结构：
前端JS调用navigator.mediaDevices.getUserMedia获取流 → 创建
RTCPeerConnection→ 生成offer → 通过WebSocket发给C#后端 C#后端（如ASP.NET Core）用
Microsoft.AspNetCore.SignalR或原始WebSocket接收offer，广播给目标客户端 双方JS完成answer/ICE交换后，音视频走P2P直连，C#不再参与媒体流 若P2P失败，需部署独立的TURN服务器（如
coTURN），C#不替代它
错误做法：试图在C#里解析SDP并“模拟”浏览器行为——SDP语义复杂，且ICE候选绑定、DTLS握手、SRTP密钥派生等均无法安全可靠复现。
调试中最容易卡住的三个地方
即使代码逻辑正确，90%的失败集中在基础设施层：
本地开发时浏览器用http://localhost，但
getUserMedia要求HTTPS或localhost，Chrome对
file://完全禁用 —— 必须起本地HTTP服务（如
dotnet watch+ Kestrel 或
live-server） ICE候选为空：没配STUN服务器（如
{"urls": "stun:stun.l.google.com:19302"}），或防火墙/NAT阻止UDP连通；用Wireshark抓包看是否发出STUN Binding Request
音频静音/黑屏：检查浏览器地址栏是否显示麦克风/摄像头权限被拒；C#后端转发SDP时误删了 a=ssrc或
a=msid行（这些是媒体轨道标识，删掉会导致track匹配失败）
WebRTC不是“连上就能通”的协议，C#在这里更像是胶水和调度员，真正的硬核工作仍在浏览器和网络中间件里。别指望靠改几行C#代码绕过ICE或DTLS。
