语音通话偶尔断续，未必是服务器配置不足，也可能是跨境链路抖动、丢包或上行带宽被挤占。香港节点部署实时语音业务的网络参数设置，建议按“先测路径、再定阈值、最后压测并发”的顺序进行。以下五步适用于使用 RTP/UDP 或 WebRTC 的实时语音系统，具体结果仍取决于用户所在地、运营商路由和终端网络。
第一步：先确定测试路径和业务协议
列出实际通话两端到香港节点的路径，分别测用户至节点、节点至用户的表现；不要只看数据中心内部网络。若采用 WebRTC，可通过实际会话观察 ICE 建连结果，确认媒体流是否走 UDP，还是因网络限制回退到 TCP 或 TURN 中继。回退链路可能增加时延，需单独记录。
使用接近真实通话的测试端点，在不同时段测量至少数分钟。ICMP ping 可用于初筛，但它不一定与语音媒体流走相同的路由或优先级，不能代替 RTP/UDP 测试。
第二步：核对时延，而不只看往返时间
实时语音应关注单向时延。ITU-T G.114 将单向时延低于约150毫秒视为多数语音应用较理想的范围；约150至400毫秒时，交谈体验可能逐渐受影响，具体感受与回声控制、交互方式和编解码处理有关。这里的端到端时延还包括采集、编码、网络传输、缓冲和播放，不等同于服务器 ping 值。
分别记录中位数和高分位时延，例如 P95，避免平均值掩盖短时尖峰。若时延偏高，比较不同运营商、接入地点和时段的结果，再检查媒体是否绕行或经过额外中继。
第三步：测抖动、丢包并设定缓冲
抖动是相邻语音数据包到达间隔的变化。对常见实时语音，持续抖动控制在约20至30毫秒以内通常更容易保持连续播放；短时波动可由抖动缓冲吸收，但缓冲设得越大，也会增加交谈延迟。先观察实际分布，再按产品可接受的延迟调整缓冲，不宜只设一个固定值后不复测。
同时检查丢包率和连续丢包情况。接近1%或更低通常较有利于语音质量，但编解码器、丢包位置及抗丢包能力都会影响结果；突发丢包往往比均匀的少量丢包更难听。必要时核对队列拥塞、无线网络干扰和路由变化。
第四步：按编码、封装和并发量估算带宽
带宽要按方向分别核算，并计入包头、加密封装及控制流量。以 G.711 为例，音频载荷为64 kbit/s；加上 RTP、UDP、IP 等开销后，实际网络占用通常会更高，且受每包承载时长和链路封装影响。Opus 可按配置使用不同码率，不能只凭编解码器名称推算固定占用。
做容量初估时，可将每路双向通话按每方向约80至100 kbit/s作为保守起点，再依据抓包或监控中的实际流量修正；这不是所有网络的固定值。若有100路同时通话，可先按每方向约8至10 Mbit/s估算媒体流，再留出至少约30%的余量应对突发和其他业务。最终以高峰并发压测结果为准。
第五步：压测并形成复核表
- 建立基线：记录测试地点、运营商、时段、协议、并发数，以及时延、抖动、丢包和上下行吞吐。
- 逐档加压：按预计并发量分阶段增加通话，观察高分位时延和丢包是否随负载明显上升。
- 核对链路：检查网卡、出口队列和防火墙是否造成拥塞或限制 UDP；服务质量标记如 DSCP EF 只有在网络设备实际配置并承认时才可能发挥作用，不能视为公网优先通行保证。
- 调整后复测：每次只改一类参数，例如缓冲或出口容量，避免无法判断改善来自哪里。
把五项结果——路径、时延、抖动、丢包、并发带宽——放在同一张记录表中，才能比较调整前后差异。香港节点部署实时语音业务的网络参数设置不是一次性填写数字：应以真实用户路径和高峰负载为依据，定期复测并在路由或容量变更后重新核对。
常见问题
只看 ping 延迟够不够？
不够。ping 主要反映往返探测结果，需结合实际媒体流的单向时延、抖动和丢包判断。
应该优先增加带宽还是调大抖动缓冲？
若链路已拥塞，先处理容量或队列问题；若只有短时到包波动且时延有余量，再评估缓冲。缓冲不能修复持续丢包。
TCP 也能传语音吗？
可以作为特定网络条件下的回退方式，但丢包重传可能增加延迟。能否使用 UDP，应结合用户网络、防火墙和实际连接成功率决定。