同學們在接觸SRVCC一段時間后，一定會有幾個百思不得其姐的問題，比如：
各種SRVCC如何區(qū)分？
為何會發(fā)生沒完沒了的SRVCC？
終端返回LTE時為何有時候會收到一堆BYE?
SRVCC切換失敗后返回LTE的流程是怎樣的？
“被叫不會發(fā)生bSRVCC”的說法對嗎？
這些問題吶，總是才下眉頭又上心頭，讓人吃不好飯睡不好覺~~~
現(xiàn)在我們一起來捋一捋這些問題的答案究竟是什么！
聲明：本文原創(chuàng)發(fā)布于微信公眾號《流鯊集結(jié)號》，轉(zhuǎn)載請保留來源信息。
文中所有流程圖，均使用流鯊軟件制圖，關(guān)于流鯊軟件的信息請在微信公眾號中獲取。
友情提醒：流程圖看不清楚的，記得點擊圖片看無碼高清大圖。
SRVCC是個什么鬼？
首先它是個語音業(yè)務的連續(xù)性方案，其次它是個切換技術(shù)，用來在Volte和23g-CS話音呼叫之間切換，彌補LTE部署早期由于覆蓋不完善而帶來的問題。
針對不同的場景，有以下幾種SRVCC類型：
Common Name | 3GPP Release | Description
|
Basic SRVCC | Rel 8 | Call Continuity from E-UTRAN to UTRAN/GRAN |
bSRVCC | Rel 10? | Packet switched to Circuit Switched call transfer during pre-alerting Phase |
aSRVCC | Rel 10 | Packet switched to Circuit Switched call transfer during Alerting Phase |
eSRVCC | Rel 10 | Enhanced SRVCC (Support for MSC Server assisted Mid Call Feature) |
vSRVCC | Rel 11 | Video SRVCC |
rSRVCC | Rel 11 | SRVCC from UTRAN/GRAN to E-UTRAN |
當終端和網(wǎng)絡都支持vSRVCC以后，視頻呼叫才可以支持SRVCC切換。
當終端和網(wǎng)絡都支持rSRVCC以后，終端才能夠在通話狀態(tài)下由23g切換回LTE。
a/b/e三種SRVCC如何區(qū)分？
它們是針對發(fā)生在呼叫的不同階段而定義的SRVCC切換，如下圖所示：
有位同學提問：在專載建立前也沒振鈴呢，這時候發(fā)生SRVCC切換應該屬于bSRVCC了吧？
NO，在專載建立前根本不會啟動測量、不會發(fā)生B2、不會觸發(fā)SRVCC。
到底是aSRVCC還是bSRVCC？
看了前面的流程圖，似乎區(qū)分aSRVCC和bSRVCC很容易嘛！
其實不然，因為這是理論而已，我們來實踐一下：”翠花，上流鯊！ “
這是一個比較偶然的案例，Ringing和SRVCC的觸發(fā)時間非常接近，Ringing送回主叫的時間與eMSC返回SRVCC HO Response之前的時間重疊，兩個事件的時間軸重合，使我們可以更清晰地觀察這個時刻。
顯然Ringing消息并不是同時送達所有網(wǎng)元的，SRVCC事件也不是同時告知所有網(wǎng)元的，它們分別觸發(fā)，然后都沿著各自的路徑順次經(jīng)過各個網(wǎng)元，如果網(wǎng)元以各自的視角（時鐘）來看，eMSC認為是bSRVCC，ATCF/SBC認為是aSRVCC，SCC-AS認為是aSRVCC，意見相當?shù)牟唤y(tǒng)一吖！
如果不是因為被叫忙（第224幀），呼叫可能早已接通，那ATCF/SBC和SCC-AS既不會認為是aSRVCC也不會認為是bSRVCC，而是判斷為eSRVCC了。
當事件發(fā)生時，并不是所有的網(wǎng)元都同時知曉，因為事件的傳播需要時間，此時各網(wǎng)元在某種意義上似乎處在不同的時空中。
一種觀點是，由SCC-AS來判定到底是那種SRVCC，SCC-AS會通過INFO來通知ATCF/SBC與eMSC自己的判定結(jié)果。但是也有實際例子證明，這個INFO的信息也并沒有像規(guī)范所定義的那樣清晰和靠譜�，F(xiàn)網(wǎng)各網(wǎng)元對bSRVCC的支持需要升級，在未升級前就會把bSRVCC判斷成aSRVCC，這也導致了基于實際案例進行分析會遭遇各種混亂。
做個總結(jié)：網(wǎng)元會根據(jù)自己掌握的信息做出判斷，并執(zhí)行自己當前版本所支持的轉(zhuǎn)接類型，也許這種轉(zhuǎn)接最后的結(jié)果會掉話（比如SCC-AS把b當成a）。至于到底是b還是a，取決于網(wǎng)元的具體實現(xiàn)邏輯，它能夠處理就好，非要在全局做出一個嚴格的認定可能并沒有現(xiàn)實的意義。
aSRVCC變成了bSRVCC的案例
SCC-AS已經(jīng)收到180，按理可以確定是aSRVCC，但是SCC-AS的邏輯是，振鈴必須在雙方資源預留完成之后。因為有彩鈴業(yè)務過程的存在，之后SCC-AS又收到Update，此時remote側(cè)的資源還沒有完成預留，如果此時發(fā)生SRVCC，SCC-AS會認為是bSRVCC。
除了彩鈴，呼叫等待也會發(fā)生類似的情況，因為它們都是先update再180。
在本案例中， SCC-AS在主叫側(cè)返回的183中攜帶了Feature-Caps信息，表明支持aSRVCC但不支持bSRVCC，因此發(fā)Cancel取消會話，攜帶原因為"No appropriate session for SRVCC/eSRVCC"。
SRVCC完成后，如何釋放源側(cè)資源？
- 當呼叫已經(jīng)建立時，通過BYE釋放源側(cè)資源
- 當呼叫還未建立時，對被叫側(cè)資源，SCCAS通過發(fā)Cancel釋放（相當于SCCAS扮演了主叫）
- 當呼叫還未建立時，對主叫側(cè)資源，SCCAS通過發(fā)404釋放（相當于SCCAS扮演了被叫）
當UE轉(zhuǎn)接后還能夠使用Gm接口時，可能會收到這個SIP消息（否則得回到LTE以后才能收到，這也同時回答了這樣的問題： “終端返回LTE時，為何有時候會收到一堆上次會話的SIP消息” ）。
SCC-AS通過計時器延遲對該SIP消息的發(fā)送，在計時器超時前允許UE取消SRVCC返回LTE繼續(xù)剛才的會話。
eSRVCC失敗后返回LTE的案例
這個案例是UE在執(zhí)行eSRVCC過程中取消切換，又返回了LTE，發(fā)送re-INVITE恢復了之前在LTE的leg。
這里我們可以看到，在eSRVCC取消之后，BYE也用來釋放在eMSC+ATCF轉(zhuǎn)接時建立的leg。在此我們可以推斷: 如果是a或bSRVCC切換被取消，主叫側(cè)會通過404、被叫側(cè)會通過Cancel來釋放在eMSC+ATCF轉(zhuǎn)接時建立的leg。原因請參見上一部分《SRVCC完成后，如何釋放源側(cè)資源》。
bSRVCC切換失敗后返回LTE的案例
在呼叫建立階段發(fā)生bSRVCC，之后切換失敗返回LTE，UE發(fā)送UPDATE，攜帶原因（Reason: SIP ;cause=487 ;text="failure to transition to CS domain"） 。
為何會陷入沒完沒了的SRVCC？
這是一個非常典型的案例，很多同學們都遇到了在幾十分鐘內(nèi)上百次的“前仆后繼”的SRVCC失敗，在查不清楚原因的時候，往往歸咎于終端出毛病了（這也是很常見的背鍋邏輯，核心怪無線、無線怪終端）。
分析困難的主要原因是，同學們沒有條件看到整個流程的全貌，如果能把IMS+EPC的全流程再加上軟采信令，呈現(xiàn)一個相對而言更完整的流程，就可以馬上找到原因，原因很簡單：頻繁SRVCC都是B2觸發(fā)，而專載的存在是進行測量的前提，因此問題都出在專載上。
在本案例中，BYE和SRVCC同時發(fā)起，會話管理要求釋放專載，而SRVCC則要求切換期間鎖定專載，因為移動管理優(yōu)先于會話管理，因此S1_erab-release_response返回失敗，原因是”radio Network: s1-inter-system-handover-triggered”，也就是說：SRVCC阻止了專載的釋放。由于專載一直存在，所以測量一直繼續(xù)，只要符合閾值就會觸發(fā)SRVCC，早在BYE的時候呼叫已經(jīng)釋放，因此SRVCC 失敗。只要無線質(zhì)差不斷地觸發(fā)B2，就會陷入頻繁SRVCC的境地，直到由于其它原因釋放了專載。
流程沖突引發(fā)頻繁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去發(fā)呼叫流程的update消息，如果沒有這個update，MGCF的Tqos定時器就會超時，呼叫就會釋放。
被叫也會發(fā)生bSRVCC，但是不被支持
SCC-AS返回該呼叫不支持bSRVCC (“Handover fails because the call does not support bSRVCC”)。
注意：不是SCC-AS不支持bSRVCC，當SCC-AS不支持bSRVCC時，也不會識別出bSRVCC。
本案例是CS呼叫VOLTE、被叫側(cè)發(fā)生bSRVCC的場景，SCC-AS直接拒絕了該切換。
規(guī)范對于被叫的bSRVCC并沒有提供支持，所以發(fā)生時一定會失敗。此外按照規(guī)范描述，還有一個一定會失敗的場景，當主叫已經(jīng)存在兩個confirmed呼叫時(一個Active一個Inactive)，第三個呼叫不論是aSRVCC還是bSRVCC都會失�。ㄖ苯俞尫诺簦�。
喜歡本文的同學們，請留下你的點贊 
有不同觀點的同學們，請留下你的文字 
路過的同學們，請留下你的足跡
想業(yè)余時間上個補習班的同學們，來流鯊信令分析大學堂QQ群吧（54825631, 316429471, 193964716, 575651131）
最后別忘記，打開微信，關(guān)注我們的公眾號：流鯊集結(jié)號
二維碼請看簽名或頭像
邀請看到這里的同學們，都去幫忙投個票！
論壇內(nèi)投票鏈接如下：http://gg1fic3.cn/bbs/thread-665370-1-1.html、
《不打醬油，積極參與，信令分析神器流鯊的使用情況調(diào)查》
[[i] 本帖最后由 kinghighland 于 2016-12-9 10:58 編輯 [/i]]
關(guān)注樓主