A：心理咨询通常为 1v1 或包含督导的 1v2、1v3 会话，架构选择需要精确平衡数据隐私性、服务器开销和弱网抗性。
对于 1v1 咨询，Mesh 拓扑（即 P2P 架构）是优先级最高的选择。在 P2P 模式下，媒体流通过 ICE 框架直接在咨访双方的客户端之间建立传输链路，无需经过任何媒体服务器中转。这种物理链路的直连最大程度保证了音视频数据的隐私。然而，由于国内复杂的 NAT 穿越环境，移动端对称 NAT 的普及导致纯 P2P 连接的打洞成功率通常只能维持在 70% 左右。
为了保证业务的绝对可用性，生产环境必须引入 TURN 服务器进行 UDP 流量的中继转发。对于包含督导机制的三方连线场景，SFU (Selective Forwarding Unit) 架构则更为合理。MCU (Multipoint Control Unit) 架构需要在服务端解码、混流再编码，不仅消耗大量 CPU 资源，而且从根本上破坏了端到端的数据保密性，在对隐私要求极高的系统开发中应严格规避。目前橙星云技术团队在处理跨地域或存在严重丢包环境下的连线请求时，采用的是以 P2P 为主、SFU 级联回退的混合架构，既保证了核心场景的超低延迟，又确保了复杂网络拓扑下的连通率。
Q：如何实现真正意义上的端到端加密 (E2EE)，避免媒体服务器被攻破导致隐私泄露？
A：WebRTC 标准规范默认通过 DTLS 和 SRTP 对媒体流进行加密。但在 SFU 架构下，DTLS 握手是在客户端与 SFU 中转服务器之间建立的，这意味着 SFU 拥有解密所有进入流的密钥。一旦服务器底层权限被非授权获取，心理咨询过程中的高敏音视频数据将面临极大的明文泄露风险。
要在 SFU 中转模式下实现真正意义上的端到端加密，必须绕过传输层的加密，在应用层引入 Insertable Streams API。工程实现流程如下：在发送端，通过调用 RTCRtpSender.createEncodedStreams() 拦截编码器输出后、封包发送前的媒体帧，利用 Web Crypto API 和咨访双方预先协商好的共享对称密钥进行 AES-GCM 算法加密；在接收端，通过 RTCRtpReceiver.createEncodedStreams() 拦截接收缓冲区中解码前的媒体帧，使用同一密钥进行逆向解密。
这里的关键点在于，密钥交换过程必须严格独立于现有的 SDP 信令。通常需要建立一个安全的旁路信道（例如基于 TLS 1.3 的 WebSocket 结合 PKI 机制）进行密钥动态协商。采用这种帧级别的加密机制后，即使是负责转发的 SFU 服务器也只能看到乱码字节流，彻底丧失了窥探咨询内容的能力。
Q：视频连线过程中，如何应对弱网环境导致的卡顿和音画不同步？
A：弱网流媒体优化不能依赖单一手段，必须从拥塞控制、前向纠错 (FEC) 和动态分辨率调整三个维度进行深度定制。
WebRTC 内置了 GCC 拥塞控制算法，通过分析接收端反馈的 RTCP 丢包率和 REMB 包到达延迟，动态计算当前网络链路的带宽预估值 (BWE)。在应用层开发中，需要利用 RTCRtpSender.setParameters() 动态调整 maxBitrate，防止发送速率超出网络瓶颈容量。
针对心理咨询这种高度重视对话连贯性的场景，语音流的 QoS 优先级绝对高于视频流。具体工程优化措施包括：
一是调整音频 NACK 和 FEC 的策略比例，增加 Opus 音频编码器的带内冗余包，以空间换时间抵抗不可预测的随机丢包。
二是在视频端采用 Simulcast（联播）技术。发送端利用不同编码参数同时输出高、中、低三种分辨率的流，SFU 节点根据各个接收端的网络状况独立下发适合的码流，避免在服务端进行高延迟的二次转码。
三是制定严格的主动降级状态机。当通过 getStats() 轮询发现网络质量指标低于预设阈值时，业务层自动挂起视频流，仅保留音频信道，彻底避免因视频关键帧拥堵导致的音频延迟堆积。
Q：在跨端开发时，如何统一信令协议和媒体状态机？
A：不同操作系统的原生平台和浏览器对 WebRTC 标准的底层实现存在显著差异。特别是小程序平台受限于沙盒环境，通常采用高度封装的私有推拉流接口，这使得跨端通信的信令协议抽象层设计极具挑战性。
信令协议的设计原则是不与底层传输通道强绑定，而是定义一套基于 JSON-RPC 规范的纯净控制消息载荷。核心会话状态机需精确管理如下生命周期节点：Idle（空闲）、Calling（呼叫中）、Connecting（ICE 候选者收集中）、Connected（已连接）、Reconnecting（断线重连中）和 Disconnected（已断开）。
在实际跨平台架构中，推荐采用 C++ 编写统一的媒体核心层，封装底层的 SDP 协商逻辑和 ICE 候选者交换时序，然后通过 JNI 和 Objective-C++ 暴露给移动端。对于 Web 浏览器和小程序，则需要在业务代码中抽象出独立的媒体适配器 (Media Adapter)。例如，当应用层接收到远端的 Offer 消息时，Web 适配器按标准流程调用 setRemoteDescription；而对应的小程序适配器，则负责解析 SDP 文本中的参数，隐式映射为对应 SDK 的私有推流指令。通过这种隔离机制，能够平滑屏蔽终端由于 API 碎片化带来的差异，保证全端连线系统状态机的一致性。