VoLTE端到端业务详解 | 应用案例一

Posted 2022-08-18 COCOgsta

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

---

6.3.1 问题现象

某地用户反馈VoLTE被叫用户振铃几声后，来不及接听就断的问题。

6.3.2 问题分析

1.信令流程分析

呼叫流程一直到被叫振铃均正常，但在被叫彩铃中心为播放彩铃做准备，收到被叫的180消息转更新消息时，给主叫侧进行媒体协商后没有收到主叫UE的200 OK响应，导致主叫MMTel AS超时释放了本次呼叫。

如图6-29所示，主叫MMTel AS收到被叫彩铃平台Update消息并转发给主叫侧后，4秒内未收到主叫侧针对这个更新的200 OK消息，MMTel AS释放了本次呼叫。

图6-30所示为业务完整流程简要描述。

2.被叫UE响应网络侧200 OK和180消息的先后顺序问题分析

200 OK、180消息时差较小是由于被叫终端消息响应得较快，相差10ms左右，这两条消息经过SBC再转发到彩铃平台后就可能存在180先到、200 OK后到的问题，如图6-31所示。

3.彩铃中心先收180再收200 OK消息的问题分析

彩铃中心针对被叫振铃后播放彩铃的规范如图6-32所示。

彩铃平台是按照消息先后顺序一条一条处理的，哪个消息先到先处理哪个。

· 如果是先收到被叫的200 OK，后收到180时，彩铃平台转给主叫侧的200 OK（媒体属性为Sendrecv），如图6-33所示。

· 如果是先收到被叫的180后收到200 OK时，彩铃平台转给主叫侧的200 OK（媒体属性为Sendonly），如图6-34所示。

彩铃平台在同时、时间相差较小或乱序收到200 OK、180消息的情况下，会修改200 OK消息中的媒体属性，这种处理逻辑应该是存在问题的，但彩铃平台目前无法修改。

4.200 OK（媒体为Sendonly）消息传递到主叫SBC侧的分析

① SBC收到被叫侧的200 OK（媒体属性为Sendonly），如图6-35所示。

因为协商后媒体属性有修改，修改为Sendonly，因此SBC发起AAR消息进行资源修改，此时AAR消息只携带了三条流（1条RTP、2条RTCP），少了一条终端上行的RTP，如图6-36所示。

② 正常场景：SBC收到被叫侧的200 OK（媒体属性为Sendrecv）的分析。

在SBC收到彩铃的Update消息之前会对被叫的183进行响应，进而完成媒体的协商，主叫SBC发起Update消息与被叫进行媒体协商，携带的a行媒体属性为Sendrecv，如图6-37所示。

此时SBC发现媒体没有变化，在给PCRF的AAR消息中TFT不会做任何修改。

5.AAR消息（删除了上行RTP协议的TFT）传递到主叫EPC侧的分析

MME会发送这个删除TFT的Update消息给主叫UE，原因为PGW收到了PCRF侧的RAR消息，在RAR消息中，由于未携带RTP的上行TFT，只携带了RTP的下行TFT，所以PGW才会根据RAR消息的指示，将上行RTP的TFT删除，PGW收到的RAR消息如图6-38所示，在这里要特别说明一下，MME下发给UE的TFT是SBC发送给UE方向的RTP流，即从SBC发送到UE方向是允许的。

综上所述，PCRF仅仅是透传消息，因此应该是收到SBC侧的指示，才会发送这个RAR消息，未携带RTP的上行TFT。

6.彩铃中心发出200 OK（媒体为Sendonly）消息后主叫终端收到的消息分析

① 彩铃平台转给主叫侧的200 OK（媒体属性为Sendonly）

对于主叫用户终端来说，收到了SIP协议的200 OK和Update的消息，同时收到了Uu口的EPS Bearer Modify Req消息，发现网络有修改Packet Filter配置，这次修改将RTP对应的上行Packet Filter删掉了（如图6-39所示），最终导致Update消息中SDP（模式为Sendrecv）和Bearer的RTP UL Packet Filter（模式为Sendonly）匹配不成功，导致主叫用户发不出去200 OK消息。

② 正常场景：彩铃平台转给主叫侧的200 OK（媒体属性为Sendrecv）

网络侧没有给用户发送MODIFY_EPS_BEARER_CONTEXT_REQUEST，SDP和Bearer与此前的Packet Filter配置能够马上匹配成功（UL/DL RTP/RTCP的Packet Filter都在），200 OK消息立即返回给网络侧。

6.3.3 问题原因

MTK芯片VoLTE终端的主叫用户呼叫签约彩铃的被叫VoLTE用户，当被叫用户返回200 OK for Update和180两条消息出现乱序问题时，主叫用户终端会匹配Update消息中SDP的媒体属性模式（Sendrecv）和Bearer的RTP UL Packet Filter的媒体属性模式（Sendonly），导致主叫用户不给网络侧返回200 OK for Update消息，从而导致MMtel AS等待200 OK for Update消息的定时器超时而释放了呼叫。

6.3.4 解决方案

这个问题是典型的终端与网络的配合问题，要想解决这个问题，可以从以下几个方面入手。

① 完善主叫终端的处理机制，当网络侧删除了自己的上行TFT，同时收到了网络侧携带需要上行媒体的Update消息时，不进行媒体属性完全匹配动作，先返回200OK消息给SBC，后续SBC再通过Rx口的AAR消息来协助主叫用户完成媒体修改，即重新创建上行TFT。

② 完善网络侧的处理机制，当出现200 OK for Update和180乱序问题时，不进行媒体属性的修改，即媒体属性依然为Sendrecv，透传200 OK for Update消息。

③ 完善被叫终端的处理机制，确保200 OK for Update消息在先、180消息在后的顺序。

6.3.5 问题延伸

VoLTE业务未接通问题的原因有很多种，需要我们仔细分析信令流程，不但要分析SIP信令，还需要分析SIP消息里携带的SDP媒体相关信息，UE会在收到网络侧SIP信令消息时，去匹配SIP消息里携带的媒体属性和UE自己当前的媒体属性，如果不匹配，会不处理当前收到的网络侧SIP信令且不给网络侧返回任何响应消息，从而带来网络侧等待UE响应消息超时的问题。