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。
