教你个绝招，小白也能分析VoLTE！-流鲨集结号案例是比较常见的“RTP-RTCP-Timeout"类型，在这个案例中是因无线问题造成了单通，媒体面的不活跃计时器超

教你个绝招，小白也能分析VoLTE！-流鲨集结号
案例是比较常见的“RTP-RTCP-Timeout"类型，在这个案例中是因无线问题造成了单通，媒体面的不活跃计时器超时触发BYE结束了呼叫。
案例比较常见，但是我们的分析手段可不常见！
借助这个分析手段，大家都能分析VoLTE，咱接着往下看
采用这种分析手段的前提是：既有信监平台可以回溯导出码流、还有路测数据的配合。数据准备工作分两步，从现网部署的随便哪家的信监平台分别导出主被叫的信令回溯数据，保存为pcap格式，接着用路测软件打开路测数据导出为文本格式，导出内容包括路测的空口信令与捕获时终端记录的时戳。路测数据中还有其它信息，比如RSRP、SINR、GPS坐标等，将来可以在流鲨上陆续提供支持。
数据准备就绪，现在开始分析池敏，需要使用最新版本的流鲨（敬请期待：这个版本还未正式发布，新功能还在优化调试中，也欢迎各路英雄好汉踊跃提供配套的数据来支持开发和测试工作，在此谢过！），打开刚才准备的文件，在界面上分屏显示，如下图所示：左侧为主叫MO视角，右侧为被叫MT视角。
特别说明：路测捕获的空口信令已经调整了时间偏移值，和信监平台的导出做了对齐
第一屏：主叫侧发起呼叫，被叫侧的这一屏暂时略过

主叫发起SR，建立RRC连接，SR送至MME，发起UE上下文建立，进入安全模式，RRC重配，UE上下文建立完成，MME通知SGW变更承载（修改S1-U隧道），然后终于轮到终端发送INVITE了，INVITE送达SBC，触发PCC流程，SGW发送CBR开始创建专载，MME开始建立E-RAB，eNB开始空口RRC重配高义山。
这就是主叫侧在发送INVITE前后的详细过程。
第二屏：主叫侧翻页，被叫侧不翻页

主叫侧的专载建立完成，PCC走完，SBC开始转发INVITE进入IMS域，历经各AS执行业务触发（本流程略过IMS域内部过程，仅留下TelAS一个AS）之后黄长求 ，跟随图中蓝色箭头，我们从主叫视角切换到被叫视角。
被叫侧I-CSCF发起LIR/LIA过程获取被叫S-CSCF信息，接着转发INVITE到该S-CSCF，然后历经各AS执行业务触发和T-ADS被叫域选（AS和HSS交互UDR/UDA，HSS与MME交互 IDR/IDA，MME发起寻呼；这部分内容也在图中略过）之后，INVITE送达被叫侧SBC，再下行送至SGW，DDN通知MME（图中有缺失），被叫发起SR响应寻呼，建立RRC连接，开始建立UE上下文，进入安全模式，执行RRC重配，UE上下文建立完成后MBR通知SGW变更承载（修改S1-U隧道）。
第三屏：主叫侧不翻页，被叫侧翻页

被叫终端对INVITE回复183，送达SBC时触发PCC流程，SGW发CBR开始建专载，MME开始建E-RAB，eNB开始空口RRC重配。
第四屏：主叫侧不翻页，被叫侧翻页

被叫侧专载建立完成后，PCC流程继续，SBC转发183至I-CSCF黄启发，然后我们跟随图中蓝色箭头，回到主叫视角。
主叫侧S-CSCF收到183后按原路径返回（包括各AS）伍文忠。
第五屏：主叫侧翻页，被叫侧不翻页

主叫侧183触发了专载更新流程，读图可知，不再描述。更新完毕主叫终端回复PRACK，跟随图中蓝色箭头，PRACK送达被叫侧，被叫终端回复200OK(for prack)，我们再跟随图中绿色箭头回到主叫视角，主叫终端收到后发起UPDATE，跟随蓝色箭头再看被叫视角，UPDATE送达被叫终端。自驾游保险
至此主被叫双方完成了资源预留（专载建立和更新）。
第六屏：主叫侧翻页，被叫侧翻页

被叫回复200OK for update，接着回铃180 Ringing并开始振铃，主叫侧收到180回铃后本地放音（本流程中的被叫未开通彩信业务），被叫在振铃~4秒后摘机，发送200OK for invite给主叫，这三个被叫发给主叫的消息（200OK for prack / 180Ringing / 200OK for invite) 都在本图中绿色箭头标出。
注意：被叫侧在本屏的最下面出现了UE上下文释放，释放原因为”用户不活跃”，释放消息与上一条消息的间隔为10秒。
第七屏：主叫侧不翻页，被叫侧翻页

点开被叫侧的UE上下文释放消息可以看到释放原因为"user-inactivity"。
eNB为了及时回收不使用的资源，设置了不活跃监测计时器刘银娥 ，对于数据业务而言，按缺省值10秒计时，10秒不使用网络资源就会被回收，从而释放UE上下文。对于VoLTE语音业务托尼厄德曼 ，则另外设置了一个单独的不活跃监测计时器，设置一个更长的时间（比如20秒、甚至60秒），以避免发生在长期振铃时专载被释放的情况。
现在我们来看被叫侧的时戳：

释放发生时刻距离上一条上行消息(MR)是12.3秒，距离上一次走默载发送200OK的距离超过了24秒。MR消息是路测软件记录的，可以推测eNB并没有收到，由此可以解释eNB发起UE上下文释放的原因，并且确认该计时器是20秒的设置值，MR前后还有收到下行寻呼(不是寻呼被叫UE)农夫三国，所以被叫侧UE遭遇到的问题应该是上行失步。
我们再看主叫侧发生的情况，主叫侧的AAR消息中可以看到RTP和RTCP已经双向放通，但是200OK for invite消息出现了下行重发（仅一次），之后约20秒也发生了“用户不活跃”导致的UE上下文释放。
从被叫视角分析齐月宾，被叫侧SBC重发了200OK一次丁芯，之后又经过4秒发生上行失步，如果主叫侧终端没有收到这个重发的200OK欲望塔，被叫侧SBC还有时间继续重发（有1s和2s的两次重发机会）水嶋宏，戴帆根据没有继续重发的现象可以推断，主叫侧实际上收到了第二个200OK for invite消息，并且回复了ACK接通消息给被叫（可以推测在流程图中缺失了这个重要的消息，它的时戳是14:12:35.590）。
被叫侧上行失步导致用户不活跃的上下文释放
发生时刻：14:12:38.279 -14:12:58.279
主叫侧有无线质差导致下行重发，之后发生用户不活跃的上下文释放
发生时刻：14:12:35.590 -14:12:55.590
第八屏：主叫侧翻页，被叫侧翻页

读图可以看到，主叫侧终端在UE上下文释放之后天草筱 ，就失去了和网络的联系，直到14:13:12（第十屏）才重新接入，持续大约37秒河南医政网。
被叫侧UE上发了BYE携带了RTP-RTCP-Timeout的原因，时戳为14:13:02.689，此时距离专载建立34秒，距离回铃33秒，距离摘机约30秒，距离收到那个失踪的ACK接通大致有27秒。
第九屏：主叫侧不翻页，被叫侧翻页

由于主叫终端失联37秒，期间无法应答被叫的BYE，所以BYE经过了多次重发(0.5s，1s郑宸，2s张伊明，4s），在距离第一个BYE 8秒后报错408（请求超时）。
第十屏：主叫侧翻页，被叫侧不翻页

由于主叫终端失联37秒，期间无法应答被叫的BYE，所以BYE经过了多次重发(0.5s，1s，2s，4s），在距离第一个BYE 8秒后报错408（请求超时）金古武侠赋。
第十一屏：主叫侧翻页刘郁芳，被叫侧翻页

被叫侧开始拆除专载。
主叫侧经过37秒的失联井出有治，终于重新建立了RRC连接，主叫终端迫切地与网络建立连接，目的只有一个(SR: mo-Data)，早点儿跟被叫说一声BYE！
第十二屏：主叫侧翻页，被叫侧不翻页

但是为时已晚，被叫早已经离他而去，只在主叫侧SBC处留下了一句话：481 Call/Transaction Does Not Exist！
主叫黯然结束了这段“有缘无份、甚至连一句BYE也没说成”的感情，拆链而去。

完整呼叫流程的最后一屏
第十三屏：主叫侧翻页，被叫侧不翻页

主叫删除专载、释放UE上下文，结束。
需要下载本案例PDF文件的朋友们，请在朋友圈分享本文，然后在公众号后台输入20180421即可收到网盘下载链接
觉得这招有用的同学们可以留言了
本号的精品资源很多，根据今天的心情随机放几个：
VoLTE呼叫时延分析
VoLTE分析神器下载链接
VoLTE错误码与实例集锦
最接近实战的VoLTE学习资料：码流标注
欢迎同学们、朋友们、各路英雄好汉们超级剑修，能够继续提供：那些你在工作中遇到的奇葩码流，如果有路测日志的文本导出则更喵~

全文详见：https://p66p.cn/38248.html

TOP