【VoLTE案例分享】数据配置错误导致呼叫eSRVCC切换时媒体不通
【现象描述】
现场测试发现VolTE用户A在4G网络下拨打另一个4G网络下的VOLTE用户B，被叫应答以后，主叫在通话在呼叫过程中发生eSRVCC切换，切换成功后通话没有中断，但是主被叫均听不到对方的声音。
【问题分析】
判断可能原因如下：
-
eMSC 和 ATGW 之间的媒体面IP承载不通；
-
ATCF 和 eMSC 信令之间的媒体协商有问题 ；
-
eMSC 和 ATGW 之间的媒体流有问题。
【问题排查】
1、首先eMSC和ATGW之间的媒体面互ping均能 ping通，基本可以排除eMSC 和ATGW之间的媒体面IP承载不通导致语音不通的可能性。
2、VolTE用户在4G下拨打2G的用户，主叫发生切换以后，语音双方都能听到，所以完全排除eMSC和ATGW之间的媒体面IP承载不通导致语音双方不同的可能性。
3、对比一下4G打4G和4G打2G的eSRVCC呼叫流程，SDP的offer和 answer的信息也都是一样的，这样就将ATCF和eMSC信令之间的媒体协商问题排除。
4、仔细分析4G打4G和4G打2G的呼叫场景，虽然在eSRVCC发生时，流程和SDP都没有啥区别，但是呼叫建立里，SDP的消息还是有区别的：
1）4G打4G时，是VoLTE终端之间的SDP协商，协商出来的codec是AMR-WB；
2）4G打2G时，是VoLTE终端和MGCF之间的SDP协商，协商出来的codec是AMR。
eMSC是不支持AMR-WB的，发出的INVITE携带的codec是AMR以及其他一些codec，因此无论是4G打4G还是4G打2G，eMSC和ATCF之间协商出的codec都是AMR。
5、我们知道，eSRVCC发生时，主叫切换的媒体不会影响到被叫，同样被叫的切换媒体也不会影响到主叫。
-
4G打4G，主叫发生eSRVCC时，eMSC和ATGW之间是AMR，ATGW和被叫之间是AMR-WB，在ATGW上需要做编解码转换；
-
4G打2G，主叫发生eSRVCC时，eMSC和ATGW之间是AMR，ATGW和被叫之间是AMR，ATGW不需要做编解码转换。
那么会不会是ATGW上编解码转换有问题导致媒体不通呢？
为了验证我们的这个想法，在SBC上将AMR的优先级提升，使之高于AMR WB，这样VolTE终端协商出来的codec就是AMR，此时主叫再做eSRVCC切换，主被叫双方都能听到语音。 至此，我们确认了是ATGW上AMR和AMR-WB之间的编解码转换有问题导致语音不通。
6、经过最终排查，发现是ATGW上有个开关被错误的打开了，正常情况下该开关应该是 disable。
【问题定位】
ATGW上AMR和AMR-WB之间的编解码转换有问题导致语音不通。
【解决方案】
在ATGW上执行以下命令，将该开关关闭，问题就得到了解决。
def profile h2 statistics pack bjbgw xnq disable