这件事说实话我现在想起来还有点后怕。那是我们刚做完5G SA商用部署测试，VoNR功能已基本跑通，IMS注册、呼叫流程都能成功。但在一个中型城市正式开放5G语音服务后的第一个周末，突然收到多个投诉，说打电话时莫名掉线，而且是在进地下停车场或电梯间时发生的特别多。

第一反应是：是不是覆盖差？还是VoNR音频断流？
但很快我们意识到问题没那么简单。这不是语音质量问题，而是整通话中断，表现为掉话。而且终端根本没自动回退4G语音，而是直接挂断。

我们紧急调了信令分析工具，把一段投诉终端日志导出来分析。从NAS流程和SIP信令看，VoNR语音建立时都正常，但进入弱NR覆盖区域后，UE没能触发SRVCC回落到LTE或2G，而是直接释放会话。

而且在这之前，我们一直以为“切换失败可以靠VoLTE兜底”，但事实是——我们忘了开SRVCC参数！

检查AMF配置发现，S-NSSAI绑定策略中根本没有设置支持切回LTE的配置；同时，gNB侧也没有配置支持SRVCC回落的选项，导致NR信号下降后，UE根本不知道该怎么做。

这事传到总部以后，专家直接指出我们配置漏项：

1. AMF到MME的接口没打通，导致不能触发EUTRAN回退；

2. IMS策略中没有配置SIP会话保持的“pending机制”，导致一旦释放就立刻挂断；

3. UE的SRVCC能力检测也没做，部分终端根本不支持强制回退。

我们当晚连夜改了配置：

• 在gNB侧开启了handoverPreparationSRVCC参数；

• 在AMF中新增与MME的N26接口路径；

• SMF调整为支持切换触发后session重建；

• 最关键的是，在IMS系统里启用了**“early media hold”**机制，避免突然断话。

第二天重新测试后，场景切换终于正常了。在停车场电梯入口，NR信号逐步衰弱，UE成功触发回落请求，呼叫不中断地切到了LTE网络，并完成语音保持。我们还特意测试了一次VoNR→SRVCC→VoLTE→断网恢复→VoNR的完整流程，总算安心了。

从这件事我学到两个教训：

第一，VoNR的稳定运行并不只是“建通话”那么简单，切换机制必须同步打通。尤其是NR的弱覆盖区域，没有SRVCC兜底就等于强行掉话。

第二，**所有的“回落机制”必须提前规划好链路通路、接口连接、策略联动。**如果你只做了NR部分，看不到LTE那头，那出了问题基本靠撞。

顺带一提，我们当时还在UPF配置上踩了一个坑：VoNR回落时，RTP路径要切换到LTE对应的UPF出口，如果不配置成多路径路由，会导致音频方向错乱或单向听不到。

所以我的建议是：

• 部署VoNR时，一定要规划好SRVCC、eSRVCC、或VoLTE fallback方案；

• 网络、核心网、IMS、策略平台必须统一对齐；

• 不同终端能力要实际验证，有些模组默认不支持SRVCC切换；

• 如果使用分片/切片网络，还得确保每个切片都支持完整语音服务链路。

这次事件以后，我们把VoNR切换策略独立成一套专项测试方案，包含5类场景、15种组合测试流程，所有新站上线前必须跑完再开服务。

写这篇只是希望还在搞5G语音的同行能早点避坑，SRVCC配置不是选配项，它是5G SA商用场景下保命的底线