同学们在接触SRVCC一段时间后，一定会有几个百思不得其姐的问题，比如：

• 各种SRVCC如何区分？

• 为何会发生没完没了的SRVCC？

• 终端返回LTE时为何有时候会收到一堆BYE?

• SRVCC切换失败后返回LTE的流程是怎样的？

• “被叫不会发生bSRVCC”的说法对吗？

这些问题呐，总是才下眉头又上心头，让人吃不好饭睡不好觉~~~

现在我们一起来捋一捋这些问题的答案究竟是什么！

声明：本文原创发布于微信公众号《流鲨集结号》，转载请保留来源信息。

文中所有流程图，均使用流鲨软件制图，关于流鲨软件的信息请在微信公众号中获取。

友情提醒：流程图看不清楚的，记得点击图片看无码高清大图。

SRVCC是个什么鬼？

首先它是个语音业务的连续性方案，其次它是个切换技术，用来在Volte和23g-CS话音呼叫之间切换，弥补LTE部署早期由于覆盖不完善而带来的问题。

针对不同的场景，有以下几种SRVCC类型：

当终端和网络都支持vSRVCC以后，视频呼叫才可以支持SRVCC切换。

当终端和网络都支持rSRVCC以后，终端才能够在通话状态下由23g切换回LTE。

a/b/e三种SRVCC如何区分？

它们是针对发生在呼叫的不同阶段而定义的SRVCC切换，如下图所示：

有位同学提问：在专载建立前也没振铃呢，这时候发生SRVCC切换应该属于bSRVCC了吧？

NO，在专载建立前根本不会启动测量、不会发生B2、不会触发SRVCC。

到底是aSRVCC还是bSRVCC？

看了前面的流程图，似乎区分aSRVCC和bSRVCC很容易嘛！

其实不然，因为这是理论而已，我们来实践一下：”翠花，上流鲨！ “

这是一个比较偶然的案例，Ringing和SRVCC的触发时间非常接近，Ringing送回主叫的时间与eMSC返回SRVCC HO Response之前的时间重叠，两个事件的时间轴重合，使我们可以更清晰地观察这个时刻。

显然Ringing消息并不是同时送达所有网元的，SRVCC事件也不是同时告知所有网元的，它们分别触发，然后都沿着各自的路径顺次经过各个网元，如果网元以各自的视角（时钟）来看，eMSC认为是bSRVCC，ATCF/SBC认为是aSRVCC，SCC-AS认为是aSRVCC，意见相当的不统一吖！

如果不是因为被叫忙（第224帧），呼叫可能早已接通，那ATCF/SBC和SCC-AS既不会认为是aSRVCC也不会认为是bSRVCC，而是判断为eSRVCC了。

当事件发生时，并不是所有的网元都同时知晓，因为事件的传播需要时间，此时各网元在某种意义上似乎处在不同的时空中。

一种观点是，由SCC-AS来判定到底是那种SRVCC，SCC-AS会通过INFO来通知ATCF/SBC与eMSC自己的判定结果。但是也有实际例子证明，这个INFO的信息也并没有像规范所定义的那样清晰和靠谱。现网各网元对bSRVCC的支持需要升级，在未升级前就会把bSRVCC判断成aSRVCC，这也导致了基于实际案例进行分析会遭遇各种混乱。

做个总结：网元会根据自己掌握的信息做出判断，并执行自己当前版本所支持的转接类型，也许这种转接最后的结果会掉话（比如SCC-AS把b当成a）。至于到底是b还是a，取决于网元的具体实现逻辑，它能够处理就好，非要在全局做出一个严格的认定可能并没有现实的意义。

aSRVCC变成了bSRVCC的案例

SCC-AS已经收到180，按理可以确定是aSRVCC，但是SCC-AS的逻辑是，振铃必须在双方资源预留完成之后。因为有彩铃业务过程的存在，之后SCC-AS又收到Update，此时remote侧的资源还没有完成预留，如果此时发生SRVCC，SCC-AS会认为是bSRVCC。

除了彩铃，呼叫等待也会发生类似的情况，因为它们都是先update再180。

在本案例中， SCC-AS在主叫侧返回的183中携带了Feature-Caps信息，表明支持aSRVCC但不支持bSRVCC，因此发Cancel取消会话，携带原因为"No appropriate session for SRVCC/eSRVCC"。

SRVCC完成后，如何释放源侧资源？

-  当呼叫已经建立时，通过BYE释放源侧资源

-  当呼叫还未建立时，对被叫侧资源，SCCAS通过发Cancel释放（相当于SCCAS扮演了主叫）

-  当呼叫还未建立时，对主叫侧资源，SCCAS通过发404释放（相当于SCCAS扮演了被叫） 

当UE转接后还能够使用Gm接口时，可能会收到这个SIP消息（否则得回到LTE以后才能收到，这也同时回答了这样的问题： “终端返回LTE时，为何有时候会收到一堆上次会话的SIP消息” ）。

SCC-AS通过计时器延迟对该SIP消息的发送，在计时器超时前允许UE取消SRVCC返回LTE继续刚才的会话。

eSRVCC失败后返回LTE的案例

这个案例是UE在执行eSRVCC过程中取消切换，又返回了LTE，发送re-INVITE恢复了之前在LTE的leg。

这里我们可以看到，在eSRVCC取消之后，BYE也用来释放在eMSC+ATCF转接时建立的leg。在此我们可以推断: 如果是a或bSRVCC切换被取消，主叫侧会通过404、被叫侧会通过Cancel来释放在eMSC+ATCF转接时建立的leg。原因请参见上一部分《SRVCC完成后，如何释放源侧资源》。

bSRVCC切换失败后返回LTE的案例

在呼叫建立阶段发生bSRVCC，之后切换失败返回LTE，UE发送UPDATE，携带原因（Reason: SIP ;cause=487 ;text="failure to transition to CS domain"） 。

为何会陷入没完没了的SRVCC？

这是一个非常典型的案例，很多同学们都遇到了在几十分钟内上百次的“前仆后继”的SRVCC失败，在查不清楚原因的时候，往往归咎于终端出毛病了（这也是很常见的背锅逻辑，核心怪无线、无线怪终端）。

分析困难的主要原因是，同学们没有条件看到整个流程的全貌，如果能把IMS+EPC的全流程再加上软采信令，呈现一个相对而言更完整的流程，就可以马上找到原因，原因很简单：频繁SRVCC都是B2触发，而专载的存在是进行测量的前提，因此问题都出在专载上。

在本案例中，BYE和SRVCC同时发起，会话管理要求释放专载，而SRVCC则要求切换期间锁定专载，因为移动管理优先于会话管理，因此S1_erab-release_response返回失败，原因是”radio Network: s1-inter-system-handover-triggered”，也就是说：SRVCC阻止了专载的释放。由于专载一直存在，所以测量一直继续，只要符合阈值就会触发SRVCC，早在BYE的时候呼叫已经释放，因此SRVCC 失败。只要无线质差不断地触发B2，就会陷入频繁SRVCC的境地，直到由于其它原因释放了专载。

流程冲突引发频繁SRVCC的其它案例

呼叫释放时的冲突（SRVCC的同时BYE），本案例陷入了频繁SRVCC （SIP: 404 Not Found）

呼叫释放时的冲突（SRVCC的同时BYE），本案例陷入了频繁SRVCC，S11的DBR返回错误S1-Bearer释放失败，失败原因是“Cause : Temporarily rejected due to handover procedure in progress (110)” 。

呼叫释放时的冲突（SRVCC的同时被叫Decline），本案例陷入了频繁SRVCC

呼叫释放时的冲突（SRVCC的同时主叫Cancel），本案例陷入了频繁SRVCC（SIP: 410 Gone）

一个特殊的bSRVCC成功案例

专家解说：EMSC并没有precondition的逻辑，在此例中，SCC AS代替EMSC去发呼叫流程的update消息，如果没有这个update，MGCF的Tqos定时器就会超时，呼叫就会释放。

被叫也会发生bSRVCC，但是不被支持

SCC-AS返回该呼叫不支持bSRVCC (“Handover fails because the call does not support bSRVCC”)。

注意：不是SCC-AS不支持bSRVCC，当SCC-AS不支持bSRVCC时，也不会识别出bSRVCC。

本案例是CS呼叫VOLTE、被叫侧发生bSRVCC的场景，SCC-AS直接拒绝了该切换。

规范对于被叫的bSRVCC并没有提供支持，所以发生时一定会失败。此外按照规范描述，还有一个一定会失败的场景，当主叫已经存在两个confirmed呼叫时(一个Active一个Inactive)，第三个呼叫不论是aSRVCC还是bSRVCC都会失败（直接释放掉）。

喜欢本文的同学们，请留下你的点赞 

有不同观点的同学们，请留下你的文字 

路过的同学们，请留下你的足迹

想业余时间上个补习班的同学们，来流鲨信令分析大学堂QQ群吧（54825631, 316429471, 193964716, 575651131）

最后别忘记，打开微信，关注我们的公众号：流鲨集结号

二维码请看签名或头像

邀请看到这里的同学们，都去帮忙投个票！

论坛内投票链接如下：http://www.mscbsc.com/bbs/thread-665370-1-1.html、

《不打酱油，积极参与，信令分析神器流鲨的使用情况调查》