webrtc无法在c#中直接运行，因其核心为c++实现（libwebrtc），c#仅能通过p/invoke封装（如webrtc.net）或信令/中继服务（如sipsorcery）间接集成，且浏览器端必须负责getusermedia、sdp协商与p2p连接。

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。