2023年底，我们项目组接了一个SA组网下的5G高清视频通话试点工作，客户很明确地要求支持VoNR业务。由于之前一直是NSA组网，语音业务靠的是VoLTE，VoNR算是我们第一次真正落地。

刚开始建完站以后，UE挂上SA，NR信号满格，数据业务也能跑起来。但在做语音拨打测试时，我们发现一个严重问题：多数终端根本无法注册VoNR，拨号直接报错，偶尔能拨通也是几秒后掉线。

这种现象说大不大，说小也不小。一开始大家都觉得可能是IMS参数配置不一致，毕竟不同厂家的IMS对接接口细节多，有个别字段没填对也可能导致注册失败。于是我们先从最常见的配置着手排查：

1. 检查UE侧IMS设置，确认Profile已启用；

2. 确认APN配置正确，DNN为ims，S-NSSAI匹配默认；

3. 核查AMF是否成功触发IMS注册流程，SIP消息是否已转发。

这一步我们发现AMF确实收到了Initial Registration消息，并已下发PDU Session Establishment，终端也返回了PDU accept。日志上看，PDU建立流程没问题，IMS Profile也被推送到UE了。

但奇怪的是，SIP REGISTER请求没发出来。

我们用信令工具跟踪UE行为，发现问题卡在了SMF到PCF之间的接口。SMF在处理DNN=ims的PDU Session时，请求PCF返回策略，但PCF返回的policy中根本没有语音业务相关的QoS rule。

说白了，UE想注册IMS，但从核心网视角看，根本没把这次Session当成“语音会话”来处理。

这个时候我开始往SBA架构深挖，想办法验证整条链路。我们去查看PCF配置，才发现当时运营侧误将IMS业务的DNN归类为普通数据业务，策略模板里根本没有放入IMS的QCI=1、5QI=1规则。导致SMF无法判断它是VoNR业务，自然也不会触发IMS注册流程。

改完策略模板，再次发起注册流程，这次SIP REGISTER果然顺利走通，后续INVITE、180 RING、200 OK也都正常返回，IMS注册完成，VoNR首次通话成功。

我们原以为这就搞定了，结果新的问题又来了——通话过程中对方听不见声音，单向音频问题。

这又是一个棘手问题。我们用抓包工具分析了RTP流，发现UE->UPF->IMS SBC方向的音频是通的，而从IMS侧返回的RTP流在UPF就没出去了。再查发现，UPF的转发策略只配置了上行PDR，下行RTP端口范围没有放开，被默认丢弃了。

也就是说，IMS那边回音回来了，但UPF根本没让它转给终端。

这时候我已经彻底服了，也更深刻地意识到，VoNR作为全IP语音方案，它不但对核心网中各模块要求严格，而且端到端都要保证路由可达、策略匹配和QoS保障统一。

最终我们补上了UPF策略，下行RTP口段正常开放，VoNR通话质量也恢复正常。

整个过程用了整整两天，除了我和同事，厂家也派了两个人协助分析SMF日志和IMS参数。事后我总结了这次排障的几个关键教训：

• 不要以为IMS注册失败都是SIP问题，SMF+PCF策略分配也是核心环节；

• VoNR依赖的QoS Flow必须有策略保障，否则即便建立成功也会出现业务不通；

• UPF不是“配置好就行”，要明确每一个流方向的PDR/FAR是否到位；

• SIP注册只是起点，语音流是否能回到UE，往往要靠策略工程师去兜底。

这次经历让我真正理解了VoNR落地的难点，也彻底打消了“5G核心网是拼配置”的想法。

它的每一步，几乎都要人脑对全链路进行完整理解，才可能搞得清楚。

目前我们已整理出一个VoNR部署Checklist，从DNN、S-NSSAI、PCF策略、IMS参数到UPF转发配置，一项项验证，避免踩坑。如果有同行在做VoNR试点，建议你提前规划好端到端流程，不要等到出问题再补。

下篇我准备写写我们在VoNR下做SRVCC退回4G失败的一次大型“翻车现场”，那一次的故障居然是因为回退路径里某个参数厂商默认禁用了。

有兴趣的朋友可以留言，我继续整理实战过程分享。