488临时错误码，VOLTE主叫用户直接在VOLTE网呼转到IMS固话用户概率性失败问题
问题描述 GSM用户呼叫本地VOLTE用户，VOLTE用户触发呼叫前转业务到 本地IMS固话，存在一定概率的前转失败情况，呼转失败时主叫侧 呼叫直接被挂断，未听到任何提示音。
原因分析 故障情况下来电提醒平台业务触发后向MGCF返回200 OK消息指示放音，MGCF随后发送ACM消息至关口局，关 口局收到的ACM消息携带的放音指示为： in-band-information-or-an-appropriate-pattern-is-now-available (1) 指示放音。 随后，关口局再将该消息回送至IMS核心网主叫侧放音，此时，其携带的ACM消息携带的放音指示为：noindication (0) 不指示放音。因此，主叫侧无法听到来电提醒放音。 查询关口局控制ACM放音相关参数为P116用于控制在BICC中继的情况下，本局在BAP表的哪些状态之前或处 于这个状态时，向对局发送ACM消息，并将该消息中Optional backward call indicators信元的In-band information indicator设置为“no indication”。该参数比特取值说明如下：00：BS_BAP_WAIT_APM；01： BS_BAP_WAIT_MGW_INFO；10：BS_BAP_WAIT_BEARER_INFO；11：BS_BAP_BEARER_ESTABLISHING。参 数默认值为11。当早回ACM消息或者呼叫失败后需要进行失败放音时，需要在承载建立过程中就给前向局回送 ACM消息，并将ACM消息中Optional backward callindicators信元的In-band information indicator设置为“no indication”，给主叫放回铃音或进行失败放音。
典型案例4：MGW打包时长软参设置导致VoLTE与CS域通话语音质量问题
原因分析 查询3GPP规范，Maxptime：最大打包时长，当ptime与Maxptime同时存在时，推荐使用ptime进行打包，以 减小时延，UMG有软参可以控制。VoLTE终端一般使用ptime打包。当同时存在ptime和maxpitme，按照最新的 26.114协议，按照ptime打包非冗余帧，按照maxptime打包冗余帧+非冗余帧。
已完成的26个省的测试，共计1979项测试。 已完成的测试情况如下： 其中Ut测试，有部分省份因不支持Ut业务，测试未通过。 IP短信业务目前不通项目只有江西萍乡测试卡不能接收短信一例，正在核查原 因。 基本业务测试的不通项目绝大部分为异常放音问题。除去异常放音，第一批省 份已测试通过，第二三四批平均每个省份有两到三个问题。正在逐步解决，下 文为解决过程中的案例。
典型案例1：VOLTE用户呼叫IMS固话用户回落2G问题
原因分析 考虑采用在核心网对INVITE消息中携带的编解码进行处理，来适配终 端ONU处理能力不足的缺陷。 由于IMS核心网有多个网元，VOLTE用户呼叫IMS固话用户，在IMS侧 相关的网元有I/S-CSCF，P-CSCF，SBC。而从对业务影响最小角度出 发考虑，选取离接入侧最近的网元SBC进行适配处理。 解决方案 在SBC上配置相关数据实现对编解码的过滤，由于IMS固话暂时不考虑 支持高清语音编解码特性，所以将AMR-WB编解码在SBC上过滤掉。 实施完成后，主被叫编解码协商成功，呼叫接续正常，ONU不再回复
解决方案 将MGCF网关UMG106软参的bit13-bit12值修改为10（UMG打包RTP包的时候根据ptime值打包），修改后测试正 常，同时比较上下行媒体包，包长也保持一致。
典型案例5：VOLTE用户呼叫IMS固话用户单通问题
问题描述
VoLTE用户呼叫本地IMS固话用户，呼叫接通后，VOLTE用户听不到IMS固话用户的声音，出现单通现象。 原因分析 通过信令分析，发现在通话接续后，仅有VOLTE向VOBB单向的媒体流，而无VOBB向VOLTE方向发送的媒 体流，故产生单通现象。咨询ONU厂家后答复，目前版本的ONU设备，当收到对端回复针对ONU主叫 INVITE消息的200 OK的SDP参数中携带b=***的相关字段时，由于处理失败导致媒体流异常，最终产生单 通。 若通过升级ONU版本解决，则涉及现网存量有上万台不同厂家不同型号的ONU设备，周期长，工作量大， 故由终端侧ONU解决难度较大。
典型案例5：VOLTE用户呼叫IMS固话用户单通
原因分析 考虑采用在核心网对200 OK消息中的b行进行处理，来适配终端 ONU处理能力不足的缺陷。 由于IMS核心网有多个网元，VOLTE用户呼叫IMS固话用户，在 IMS侧相关的网元有I/S-CSCF，P-CSCF，SBC。而从对业务影响 最小角度出发考虑，选取离接入侧最近的网元SBC进行适配处理。
问题描述 VOLTE测试中发现VolTE下号码与CS域号码通话时，概率性出现一方无法听清另一方声音的情况，或吞音或断续。 无法正常接听的现象既在VoLTE侧出现过，也在CS侧出现过。 原因分析 1、通过选取华为Mate7和三星S6终端，中兴和华为eNodeB场景，4G低业务量无线环境良好的地点定点拨测， 多次验证，排除终端及无线环境问题。 2、进行媒体面分析，媒体面路径为：空口->S1接口用户面->P-GW用户面->PSBC->IM-MGW->CS MGW。 CHR进行分析，发现通话为2G到LTE业务下行有语音质量差的记录，语音编码为12.2K，下行数据RTP号连续，丢 包很少，进一步查看发现下行两个数据包间隔为240ms左右（少量包为20ms），SBC侧200OK消息中指示 ptime=20ms,Maxtime=240ms。在SBC的媒体面消息跟踪中，也可以发现，UE上行媒体包包长明显小于SBC下 行媒体包，且UE上行媒体包的数量明显高于SBC下行媒体包数量。 UE上行媒体包 SBC下行媒体包：
6
典型案例1：VOLTE用户呼叫IMS固话用户回落2G问题
问题描述
VoLTE用户呼叫本地IMS固话用户，主叫回落到2G后方可接通。
原因分析 对比IMS固话用户收到的主叫用户分别在VOLTE网络和回落到2G 网络下发起的两个INVITE消息，发现VOLTE网络下的INVITE消息 携带10种编解码类型及相关事件参数，2G网络下的INVITE 消息携 带5种编解码类型及相关事件参数。 咨询ONU厂家后答复目前版本的ONU设备，无法处理携带超过8 种以上编解码及相关事件SDP参数的INVITE消息。 若通过升级ONU版本解决，则涉及ONU版本开发及上万个ONU设 备的版本升级，周期长，工作量大，故由终端侧ONU解决难度较 大。
公司VoLTE建设经验交流
1
目录
VOLTE 网络建设
VOLTE 核心网测试与优化情况
VOLTE 无线网测试与优化情况
2
网络改造进展情况
一、已完成改造主设备 1、已完成EMSC、HSS、EPC、无线网、LDRA(低级路由代理节点）、PCC(策略控制计费)、IP承载网改造。 2、已完成IMS设备的主节点改造。（容灾节点少部分未完成） 二、主设备改造遗留问题 1、HSS：爱立信HSS与UT未连接，影响手机侧操作的补充业务，爱立信目前还在开发补丁，预计11月底研发完成，计划 12月底前解决。 2、EMSC：爱立信EMSC目前不支持呼叫保持中的4G-2G的切换（MID-CALL），预计2015年12月补丁研发成功，计划 2016年1月底解决。 3、IMS：CSCF预计年底实现容灾。 三、业务平台改造计划
典型案例2： VOLTE用户呼转到IMS固话用户概率性失败问题
原因分析 分别查询2个MGCF上与编解码相关的数据配置：由于GSM用户入
域呼叫VOLTE用户的时候，匹配到的局向为默认局向“NULL”，
所以通过查表，MGCF1上匹配G.711编解码的打包时长为5ms， 而MGCF2上该数据配置为20ms。故当呼转业务经过MGCF2成功，
1、智能网、来电提醒：已完成改造。
2、彩铃、彩印、LBS：预计12月底完成。
3
目录
VOLTE 网络建设
VOLTE 核心网测试与优化情况
VOLTE 无线网测试与优化情况
4
网络改造进展情况-测试进展
省际漫游测试
目前已经完成全部第一批8个省第二批10个省的测试。陆续收到第三第四批省 的测试卡，并开始测试，第三四批已测试完成8个省份。
典型案例3：VoLTE改造后来电提醒业务触发通知音错误问题
原因分析 故障情况下，可以看到ESTABLISHED消息是在关口局向MGCF返回ACM消息后触发的，所以关口局修改了带内 放音指示，主叫侧用户无法听到来电提醒放音。如图所示：
随后，我们又跟踪了Volte用户拨打Volte用户不可及、无应答和遇忙呼转的信令消息，发现信令均由MGCF发送 至关口局迂回，返回MGCF后再发送给主叫用户，信令经由关口局迂回后，放音指示被改变为：no-indication (0) 不指示放音。原因与2、3G一致。至此，可以断定问题的症结在于关口局修改了放音指示。 解决方案
在修改关口局P116参数，更改为10。具体指令：MOD MSFP: ID=P116, MODTYPE=P1, BIT=10, BITVAL=0, CONFIRM=Y;参数修改后可以看到关口局向MGCF返回ACM消息中已经不再修改放音指示，问题得到了解决。
典型案例4：MGW打包时长软参设置导致VoLTE与CS域通话语音质量问题
原因分析 被叫侧IMS网络针对主叫INVITE回复488时，呼叫中断，呼转失败。 对比呼转成功和呼转失败的INVITE消息：呼转失败的INVITE消息， 优选G.711A编解码，打包时长为5ms；呼转成功的INVITE消息， 优选G.711A编解码，打包时长为20ms。 进一步分析发现，当呼叫经由MGCF2入域的时候，打包时长为 20ms；当呼叫经由MGCF1入域的时候，打包时长为5ms。