volte的語(yǔ)音信令流程是什么，如果發(fā)生eSRVCC切換信令流程

簡(jiǎn)單的講就是呼叫-接通-通話（切換）-掛機(jī)；                          eSRVCC切換信令流程就是：呼叫-接通-通話（切換到GSM）-掛機(jī)-返回LTE。

eSRVCC方案對(duì)于SRVCC方案的改進(jìn)及標(biāo)準(zhǔn)

3GPP TR 23.856

Single Radio Voice Call Continuity (SRVCC) enhancements;

Stage 2

介紹了各種eSRVCC方案的備選方案。

介紹了業(yè)務(wù)流程。

3GPP TS 23.237 V12.0.0 (2012-06)

的5.2.2    Architecture when using ATCF enhancements

明確了本文的eSRVCC方案

介紹了業(yè)務(wù)流程。

3GPP TS 24.237 V11.4.0 (2012-09)

P Multimedia Subsystem (IMS) Service Continuity;

Stage 3

介紹了流程與信令擴(kuò)展的細(xì)節(jié)。

 思路：引入接入側(cè)媒體錨點(diǎn)，減少Remote Update的信令傳輸時(shí)間。

     eSRVCC可視為SRVCC的升級(jí)版本（實(shí)際上 SRVCC方案與eSRVCC方案 可以在一個(gè)運(yùn)營(yíng)商網(wǎng)絡(luò)中共存 ）。

   與SRVCC相比，新增ATCF/ATGW網(wǎng)元，SCC-AS功能有增強(qiáng)，HSS透明數(shù)據(jù)有新增。其它網(wǎng)元功能不變（比如MME、eMSC、UE)

信令面、媒體面在切換前后的路徑

    切換的信令面變化，參見(jiàn)：

    切換前后的信令均經(jīng)過(guò)了ATCF。

    媒體面的切換路徑參見(jiàn)：

   切換前后的媒體均經(jīng)過(guò)了ATGW。

   ATCF/ATGW:信令錨定點(diǎn)，媒體錨定點(diǎn)

   從信令面來(lái)說(shuō)，多了一個(gè)網(wǎng)元，多了一些信令傳遞。但由此帶來(lái)的時(shí)延不大。關(guān)鍵是IMS 遠(yuǎn)端update過(guò)程在大多數(shù)情況下可以不做。

   從媒體面來(lái)說(shuō)，多了一個(gè)網(wǎng)元。但由于切換前后的媒體均錨定到ATGW。對(duì)遠(yuǎn)端來(lái)說(shuō)看到的SDP是ATGW產(chǎn)生。

   當(dāng)ATGW SDP不變時(shí)，可以不需要Update remote end。切換時(shí)延將大大減少。

   ATCF可與P-CSCF或SBC合設(shè)。

   大部分呼叫是不需要update remote end的。但如果切換后，媒體類(lèi)型（如audio、video）發(fā)生變化（比如2G CS域只支持audio了），或ATGW無(wú)法完成Transcoding，或ATCF發(fā)現(xiàn)用戶有多路呼叫，則需更新遠(yuǎn)端媒體。此時(shí)ATCF發(fā)起Invite(ATU-STI)給SCC-AS。SCC-AS會(huì)關(guān)聯(lián)到遠(yuǎn)端用戶，并更新遠(yuǎn)端媒體。同時(shí)bye掉前面建立的呼叫l(wèi)eg（也是這個(gè)ATCF發(fā)過(guò)來(lái)的)

     eSRVCC中，媒體的錨定在ATGW，信令的錨定由ATCF與SCC-AS共同完成（如上所述，呼叫、切換產(chǎn)生的新呼叫都會(huì)發(fā)到SCC-AS）。

    當(dāng)用戶有多路呼叫時(shí)，UE切換時(shí)只發(fā)起一路呼叫的切換，即MSC只會(huì)發(fā)起一路呼叫到ATCF。  SCC-AS發(fā)現(xiàn)用戶有多路呼叫時(shí)，會(huì)發(fā) Refer消息 給ATCF，再轉(zhuǎn)發(fā)給MSC，由MSC在CS域內(nèi)發(fā)起第二路呼叫。

eSRVCC業(yè)務(wù)流程

一、用戶注冊(cè)流程：STN-SR，ATU-STI，C-MSISDN

     用戶在LTE側(cè)發(fā)起注冊(cè)，呼叫在LTE承載上，經(jīng)過(guò)PGW發(fā)到互聯(lián)網(wǎng)上IMS域：P-CSCF/A-SBC->ATCF->S-CSCF->SCC AS。

     注冊(cè)時(shí)，ATCF分配dynamic STN-SR，在注冊(cè)消息中發(fā)給SCC AS， SCC AS修改IMS-HSS中用戶數(shù)據(jù)，HSS將修改的數(shù)據(jù)下插到MME中，切換時(shí)帶給eMSC。

注：這個(gè)過(guò)程中：SCC AS、IMS-HSS、MME的操作與SRVCC方案一樣。

      區(qū)別只是SRVCC中，STN-SR是SCC AS產(chǎn)生。而eSRVCC中，STN-SR是由ATCF產(chǎn)生。

     原因是：SRVCC中，MSC直接發(fā)切換請(qǐng)求給SCC AS(帶STN-SR)，而eSRVCC中，MSC發(fā)切換請(qǐng)求給ATCF（帶STN-SR) 。

       對(duì)于SCC-AS來(lái)說(shuō)，由于同時(shí)作為ICS、SRVCC、eSRVCC方案的網(wǎng)元，當(dāng)收到呼叫時(shí)，需要識(shí)別當(dāng)前所承擔(dān)的網(wǎng)元角色。

       在SCC-AS收到S-CSCF發(fā)來(lái)的第三方注冊(cè)請(qǐng)求消息中，攜帶Feature-Caps頭部（由ATCF插入），如SCC-AS發(fā)現(xiàn)Feature-Caps中存在+g.3gpp.atcf參數(shù)，則認(rèn)為是eSRVCC用戶的注冊(cè)。

       對(duì)于eSRVCC用戶的注冊(cè)，SCC AS會(huì)把+g.3gpp.atcf信息更新到IMS HSS，并從IMS HSS下載到特定的用戶數(shù)據(jù)（非透明數(shù)據(jù)，見(jiàn)“IMS-HSS新增數(shù)據(jù)項(xiàng)”一節(jié)）。

       對(duì)于eSRVCC用戶的注冊(cè)，SCC AS在注冊(cè)成功后，向終端發(fā)送MESSAGE，MESSAGE的消息體中含有ATU-STI與C-MSISDN(從HSS下載得到，屬于簽約放號(hào)數(shù)據(jù))。ATU-STI由SCC AS自己產(chǎn)生，用來(lái)識(shí)別呼入請(qǐng)求是否是eSRVCC用戶發(fā)來(lái)的切換請(qǐng)求。

      ATCF在注冊(cè)消息的Feature-Caps頭部攜帶了多個(gè)信息：

      1, +g.3gpp.atcf填寫(xiě)STN-SR，用于向SCC AS、HSS、MSC Server更新用戶的SRVCC地址信息。

      2，+g.3gpp.atcf-mgmt= "<sip:actf.visited2.net>"用于SCC AS向ATCF發(fā)送message消息時(shí)的request URI。

        STN-SR實(shí)際上分兩種：STN-SR、vSTN-SR。見(jiàn)SRVCC方案。    

注：3GPP TS 24.237 V11.4.0 (2012-09)  

                Table A.3.3-1: SIP REGISTER request (UE to P-CSCF)

REGISTER sip:home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8

Max-Forwards: 70

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11

From: <sip:user1_public1@home1.net>;tag=2hiue

To: <sip:user1_public1@home1.net>

Contact: <sip:[5555::aaa:bbb:ccc:eee];comp=sigcomp>;+sip.instance="<urn:gsma:imei:90420156-025763-0>;+g.3gpp.icsi-ref="urn:urn-7%3gpp-service.ims.icsi.mmtel"

Call-ID: E05133BD26DD

Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net", nonce="", uri="sip:home1.net", response=""

Security-Client: ipsec-3gpp; alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=1234; port-s=5678

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 1 REGISTER

Supported: path, gruu

Content-Length: 0

                Table A.3.3-3: SIP REGISTER request (ATCF towards S-CSCF)

REGISTER sip:home1.net SIP/2.0

Feature-Caps: *;+g.3gpp.atcf="<tel:+1-237-888-9999>"; +g.3gpp.atcf-mgmt= "<sip:atcf.visited2.net>";+g.3gpp.atcf-path="<sip:termsdgfdfwe@atcf.visited2.net>";+g.3gpp.mid-call;+g.3gpp.srvcc-alerting

Path:     <sip:termsdgfdfwe@atcf.visited2.net>,<sip:aga2gfgf@pcscf1.visited2.net:5070;ob>

Route: <sip:icscf.home1.net;lr>

P-Visited-Network-ID:

P-Charging-Vector:

Via: SIP/2.0/UDP atcf.visited2.net:5060;branch=z9hG4bKnas5889; SIP/2.0/UDP pcscf1.visited2.net:5060;branch=z9hG4bKnas56565, SIP/2.0/UDP [5555::aaa:bbb:ccc:eee];comp=sigcomp;branch=z9hG4bKnasiuen8;rport=5060;received=5555::aaa:bbb:ccc:eee

Max-Forwards: 68

P-Access-Network-Info:

二、用戶呼叫流程：正常的IMS呼叫，但必須控制錨定媒體到ATGW

        所有IMS呼叫都錨定到ATCF，ATCF需要知道用戶是否支持SRVCC功能(這樣才能控制SRVCC用戶的呼叫媒體錨定到ATGW，并才能在呼叫、切換時(shí)進(jìn)行特定處理)，

        ATCF在注冊(cè)結(jié)束后，會(huì)從SCC-AS得到一個(gè)message消息：攜帶C-MSISDN、ATU-STI及用戶是否支持SRVCC功能標(biāo)記（即切換到CS域的功能）

    　SCC-AS如何知道用戶是否支持SRVCC:UE在LTE中附著時(shí)，會(huì)指示自己是否支持SRVCC，MME將這種標(biāo)記存入HSS。SCC-AS在用戶注冊(cè)時(shí)會(huì)從HSS下載用戶數(shù)據(jù)，其中含SRVCC能力。

        所有IMS用戶的IMS注冊(cè)都被SBC發(fā)給Visited域的ATCF，ATCF把自己加到Path上，發(fā)給S-CSCF。

       后來(lái)這些用戶（含SRVCC用戶與非SRVCC，或分為：固定用戶、Volte用戶）的呼叫都經(jīng)過(guò)了ATCF。ATCF根據(jù)在注冊(cè)后得到的用戶SRVCC能力來(lái) 控制SRVCC用戶的呼叫媒體錨定到ATGW（這是呼叫流程中最重要的工作），而非SRVCC用戶則不需要錨定媒體。

三、eSRVCC切換流程:STN-SR，ATU-STI，C-MSISDN

    對(duì)于接受注冊(cè)和VoLTE呼叫的ATCF來(lái)說(shuō)，需要讓MSC把切換請(qǐng)求發(fā)給自己。這樣才是完全的“錨定”功能。

     MME控制切換到CS域、PS域的方法與SRVCC一樣。

     eMSC在切換時(shí)，發(fā)invite給ATCF（其中帶STN-SR，C-MSISDN)給ATCF。由于STN-SR是ATCF自己分配的，它會(huì)知道這是一個(gè)切換請(qǐng)求，并根據(jù)C-MSISDN關(guān)聯(lián)到IMS用戶和現(xiàn)有呼叫。

    對(duì)eMSC來(lái)說(shuō)，這個(gè)操作與SRVCC方案中一樣。 區(qū)別只是：SRVCC中，呼叫是完全錨定到SCC-AS，由eMSC直接把切換invite發(fā)給SCC-AS。而eSRVCC中錨定由ATCF與SCC-AS共同完成，eMSC必須把切換invite發(fā)給ATCF。

      STN-SR是給MSC在切換請(qǐng)求時(shí)使用的，由ATCF在注冊(cè)時(shí)產(chǎn)生。 一般是標(biāo)識(shí)ATCF的全局PUI，或稱(chēng)為PSI，因?yàn)槭墙oMSC用的，一般是Tel URI格式。 

     當(dāng)原IMS呼叫有幾路時(shí)，ATCF收到MSC發(fā)來(lái)的呼叫中，必須選擇關(guān)聯(lián)其中一路：先選擇Active的呼叫，再選擇。。。這之中有個(gè)邏輯判斷（由ATCF自己做）

     而ATCF發(fā)invite(被叫是ATU-STI，主叫是用戶PUI)給SCC-AS。 SCC-AS返回SSI給ATCF和MSC。（SSI用于 mid-call 切換 中關(guān)聯(lián)呼叫所用）

     ATU-STI是給ATCF在切換請(qǐng)求時(shí)使用的，由SCC AS在注冊(cè)時(shí)產(chǎn)生。

     SCC AS在注冊(cè)時(shí)產(chǎn)生ATU-STI。它用Message通知ATCF:UE的C-MSISDN，以及分配的ATU-STI，還有UE的SRVCC 能力

     ATCF使用C-MSISDN來(lái)關(guān)聯(lián)會(huì)話(MSC發(fā)來(lái)切換請(qǐng)求時(shí))，使用ATU-STI替換與SCC AS之間的信令路徑(在發(fā)起切換呼叫到SCC-AS時(shí)）。原信令leg會(huì)被ATCF或SCC-AS釋放。

      C-MSISDN是很重要的，因?yàn)镮MS用戶PUI與CS域號(hào)碼可能是不一樣的。ATCF收到MSC發(fā)來(lái)切換請(qǐng)求（帶C-MSISDN，它表示了主叫的身份）時(shí)，再關(guān)聯(lián)到現(xiàn)存的幾個(gè)IMS呼叫中的一個(gè)。  

      ATU-STI是全局PSI。像STN-SR一樣，都是一個(gè)全局PSI，所以要關(guān)聯(lián)到某個(gè)用戶的某一路舊呼叫的話，要根據(jù)新呼叫中帶的PAI(用于關(guān)聯(lián)到用戶）、Target-Dialog（像replace一樣，含有舊呼叫的dialog ID)

     用戶原來(lái)有多路呼叫時(shí)，決定替換哪一路由ATCF決定，其原呼叫的dialog id 置入Target-Dialog參數(shù)中。

      當(dāng)切換請(qǐng)求invite被eMSC發(fā)給ATCF，ATCF置被叫號(hào)碼為ATU-STI（主叫號(hào)碼為用戶PUI），且攜帶Target-Dialog參數(shù)(其中含原LTE呼叫的SIP 會(huì)話ID），這個(gè)invite發(fā)給SCC AS。

      SCC AS會(huì)執(zhí)行替換呼叫的操作(不切換遠(yuǎn)端媒體)與釋放原呼叫的local leg：SCC AS使用Target-Dialog參數(shù)來(lái)尋找到原呼叫的數(shù)據(jù)區(qū)。在invite的200 響應(yīng)中，SCC AS攜帶Feature-Caps：*；+g.3gpp.srvcc

      如切換請(qǐng)求(根據(jù)被叫是否是ATU-STI決定）的invite中沒(méi)有攜帶Target-Dialog參數(shù)時(shí)（而不完全靠被叫是ATI或STN-SR來(lái)判斷是否執(zhí)行SRVCC），SCC AS執(zhí)行SRVCC方案，即從用戶的多路選叫中選中一路來(lái)update remote end.（SRVCC方案中，決定替換哪一路的決策由SCC AS來(lái)做）。

       而對(duì)SCC-AS來(lái)說(shuō)，在收到ATCF發(fā)來(lái)用于切換的invite時(shí)，根據(jù)Target-dialog中的dialog id來(lái)關(guān)聯(lián)到用戶現(xiàn)存的4路呼叫中的一路。在這個(gè)呼叫關(guān)聯(lián)完成后（呼叫關(guān)聯(lián)的工作包括：向主叫用戶即ATCF發(fā)送200OK，即完成新呼叫的創(chuàng)建，另外還要釋放掉舊呼叫的leg。  因?yàn)槭荁2BUA網(wǎng)元，所以不用通知到遠(yuǎn)端IMS用戶，除非需要更新遠(yuǎn)端媒體)。

      SCC-AS還要從剩下3路呼叫中選擇一路呼叫來(lái)發(fā)起refer給ATCF->MSC，命令UE發(fā)起另一路呼叫的創(chuàng)建。依次選擇幾路呼叫的順序也有一個(gè)邏輯判斷（由SCC-AS自己做）

    LTE側(cè)的IMS呼叫的振鈴態(tài)切換的判斷：當(dāng)用戶invite的contact中含有g(shù).3gpp.srvcc-alerting feature tag時(shí)，它表示終端與ATCF 是否支持振鈴態(tài)eSRVCC。SCC-AS可以根據(jù)這來(lái)判斷是否做振鈴態(tài)切換。

      在振鈴態(tài)或媒體為inactive狀態(tài)（即多路呼叫）的會(huì)話切換中,給ATCF發(fā)info消息,其包含Info-Package:g.3gpp.state-and-event-info和Content-Type:application/vnd.3gpp.state-and-event-info+xmls,及相關(guān)的XML描述。

       在呼叫消息中支持對(duì)Contact:<sip:msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn:urn-7%3gpp-service.ims.icsi.mmtel"、Target-Dialog、Recv-Info、P-Asserted-Service:urn:urn-7:3gpp-service.ims.icsi.mmtel信息的處理,用于切換與判斷是否支持振鈴態(tài)和mid-call的切換。在響應(yīng)消息中攜帶feature-caps頭部。

     這是為了作振鈴態(tài)切換。

      所有的切換請(qǐng)求、響應(yīng)（18x,200)中都會(huì)帶feature-caps:srvcc。用于標(biāo)識(shí)eSRVCC切換呼叫。eSRVCC流程中出現(xiàn)了各種feature-code，攜帶各種關(guān)鍵參數(shù)。

     ATCF沒(méi)有錨定媒體

其它技術(shù)點(diǎn)

IMS-HSS新增數(shù)據(jù)項(xiàng)

HSS的Sh接口透明數(shù)據(jù)中（29.328-b50)，有

MSISDN ：可能包括幾個(gè)號(hào)碼，即C-MSISDN,

Extended MSISDN 

Additional MSISDN (A-MSISDN) 

Private Identity 

T-ADS Information

            -    IMS-VOICE-OVER-PS-NOT-SUPPORTED (0)

            -    IMS-VOICE-OVER-PS-SUPPORTED (1)

            -    IMS-VOICE-OVER-PS-SUPPORT-UNKNOWN (2)

STN-SR

UE SRVCC Capability

            -    UE-SRVCC-CAPABILITY-NOT-SUPPORTED (0)

            -    UE-SRVCC-CAPABILITY-SUPPORTED (1)

CSRN

        在向IMS-HSS請(qǐng)求"MSISDN"時(shí)，需要在"User Identity"中填寫(xiě)PUI，在"User-Name"中填寫(xiě)PVI(從SIP注冊(cè)消息的Authorization中獲取) .

控制非SRVCC用戶呼叫不需經(jīng)過(guò)ATCF的方法

       所有VoLTE用戶中并非所有用戶都是eSRVCC用戶�；蛘卟糠钟脩羰荢RVCC用戶、另一部分用戶是eSRVCC用戶。因?yàn)閑SRVCC用戶的語(yǔ)音質(zhì)量更好，可能視為高端用戶。這里的想法是：如何區(qū)分SRVCC用戶、eSRVCC用戶或非SRVCC用戶。

       eSRVCC功能要求：eSRVCC用戶的媒體通過(guò)ATGW錨定，那么這些用戶的注冊(cè)、呼叫、切換信令是必須經(jīng)過(guò)ATCF的。但其它 非eSRCC用戶 是不需要讓呼叫經(jīng)過(guò)ATCF，仍經(jīng)過(guò)P-CSCF->I-CSCF->S-CSCF即可。

      所有用戶注冊(cè)時(shí)（CS域 ICS用戶，可能通過(guò)eMSC注冊(cè)），注冊(cè)信息必須經(jīng)過(guò)P-CSCF->ATCF->I-CSCF。因?yàn)樽��?cè)時(shí)，這些網(wǎng)元并不知道用戶是否是合格的eSRVCC用戶，甚至不知道是否是IMS用戶。P-CSCF，ATCF會(huì)在用戶注冊(cè)時(shí)，將自己加到path路徑上。  這一點(diǎn)是沒(méi)有異議的。

      有一種控制呼叫是否錨定到ATCF的方法是由S-CSCF在注冊(cè)時(shí)判斷用戶是否支持SRVCC功能（   S-CSCF在用戶注冊(cè)時(shí)，可以從Cx接口的簽約數(shù)據(jù)中得到用戶是否有SRVCC能力（目前的Cx標(biāo)準(zhǔn) 29228-b50 中沒(méi)有這個(gè)信息））

      如支持，S-CSCF修改path頭(使其中不含ATCF，用于被叫側(cè)S-CSCF找下一跳）與產(chǎn)生service-route頭(其中不需要含ATCF地址）（這里也要求S-CSCF能知道 path頭中哪個(gè)URI是表示ATCF的，ATCF在注冊(cè)消息的Feature-Caps中會(huì)帶上自己的atc-path，另一種辦法是讓S-CSCF上配置ATCF域名），Service-route頭在注冊(cè)響應(yīng)里原路返回發(fā)給P-CSCF,ATCF 等，UE把這個(gè)頭反向復(fù)制到到 新產(chǎn)生呼叫的route頭中。

      P-CSCF在收到呼叫消息時(shí)，刪除信令中的service-route頭（終端發(fā)來(lái)的，不可靠），按本身存儲(chǔ)的service-route頭再?gòu)?fù)制一份route頭（當(dāng)然會(huì)從中刪除自己），這個(gè)呼叫消息會(huì)發(fā)給S-CSCF（不可能發(fā)給ATCF）

      如用戶沒(méi)有SRVCC能力，通過(guò)這種方法就可以控制呼叫消息不經(jīng)過(guò)ATCF。

     這樣：只有SRVCC的呼叫會(huì)經(jīng)過(guò)ATCF。而普通IMS用戶呼叫不會(huì)經(jīng)過(guò)ATCF。

緩存8秒的過(guò)程   

       雖然錨定到ATGW的媒體端口、IP、編解碼在切換前后沒(méi)有變化，但信令路徑發(fā)生了改變。所以ATCF需要發(fā)切換請(qǐng)求給SCC AS(因?yàn)樵�呼叫路徑�?huì)自動(dòng)釋放)。

       原IMS呼叫路徑包括了UE的IMS應(yīng)用、SBC、P-CSCF、SCC-AS 都會(huì)因?yàn)閟ession timer功能或刷新注冊(cè)時(shí)間到卻沒(méi)收到刷新注冊(cè)消息，而釋放呼叫。（SCC-AS在釋放呼叫或收到 ATCF側(cè)發(fā)來(lái)的bye消息時(shí)，只釋放這一邊的leg ，遠(yuǎn)端leg 要保留）

      原IMS路徑上的leg 釋放，與 MSC發(fā)呼叫給ATCF ：這兩個(gè)操作的時(shí)間順序不確定。為了防止用戶在session timer即將到期時(shí)發(fā)起切換，標(biāo)準(zhǔn)要求SCC-AS在收到釋放近端leg的請(qǐng)求時(shí)，保留leg 8秒鐘。

       SCC-AS收到ATCF發(fā)來(lái)的新invite時(shí)，如原leg還在，SCC-AS會(huì)釋放它。

      在手機(jī)信號(hào)變?nèi)鯐r(shí)，或原呼叫的session timer到期時(shí)，UE或CSCF會(huì)發(fā)bye，但此時(shí)對(duì)于SRVCC用戶會(huì)發(fā)起切換。

      所以：要求ATCF、CSCF、SCC-AS 對(duì)于SRVCC用戶的呼叫，在釋放消息到時(shí)會(huì)緩存8秒。 或只由SCC-AS來(lái)做，因?yàn)镃SCF上沒(méi)有用戶信息，當(dāng)CSCF主動(dòng)發(fā)bye給SCC AS時(shí)，SCC AS緩存8秒即可。

    　CSCF的sesison time到期時(shí)，向上，向下都發(fā)bye。向下發(fā)給ATCF，ATCF也要緩存8秒，以防止這段時(shí)間內(nèi)切換消息從MSC發(fā)來(lái)。

      如果CSCF不做這種緩存的話，就要求 SCC AS與ATCF 均要緩存8秒（如SCC有緩存，而ATCF不緩存的話，ATCF會(huì)在收到CSCF的bye時(shí)釋放呼叫，后續(xù)當(dāng)MSC發(fā)來(lái)切換請(qǐng)求時(shí)，就無(wú)法完成eSRVCC切換流程）。

eSRVCC是否兼容SRVCC

      eSRVCC的流程變化關(guān)鍵點(diǎn)體現(xiàn)在ATCF、SCC AS。

      如果要求網(wǎng)絡(luò)中同時(shí)存在eSRVCC、SRVCC兩種用戶，比如對(duì)于高端用戶提供eSRVCC流程，而eSRVCC流程要求ATCF的信令與媒體錨定，eSRVCC用戶容量受ATCF與ATGW配置所限。

　　ATCF、SCC AS通過(guò)注冊(cè)成功可以鑒定用戶是否是IMS用戶，那么如何識(shí)別三種用戶（普通IMS用戶、SRVCC用戶、eSRVCC用戶)呢？

      ATCF在注冊(cè)時(shí)不區(qū)分是否SRVCC或IMS用戶，由SCC AS從HSS得到用戶支持C-MSISDN與SRVCC能力的參數(shù)，則證明用戶支持SRVCC能力并經(jīng)過(guò)SRVCC業(yè)務(wù)簽約，SRVCC能力會(huì)在Message里下發(fā)給ATCF。

      這種方案支持eSRVCC用戶漫游到外地:1,visited網(wǎng)有ATCF，則走eSRVCC流程。  2，visited網(wǎng)沒(méi)有ATCF，由P-CSCF接入home域IMS，SCC AS走SRVCC流程（SCC AS通過(guò)注冊(cè)、呼叫消息中是否帶feature-code來(lái)判斷是否有ATCF接入）

       上述方案可以鑒別IMS用戶與SRVCC用戶(也含eSRVCC用戶）。

      如何鑒別SRVCC用戶與eSRVCC用戶呢?

      兩種看法：

1，ATCF部署后，網(wǎng)絡(luò)中只有eSRVCC用戶，沒(méi)有SRVCC用戶（因?yàn)閑SRVCC與SRVCC對(duì)終端的要求是一樣的，只是網(wǎng)絡(luò)側(cè)能力不同）。則SCC AS只要發(fā)現(xiàn)用戶注冊(cè)、呼叫帶了feature-code，則走eSRVCC流程。

2，ATCF部署后，網(wǎng)絡(luò)中eSRVCC用戶與SRVCC用戶并存。SCC AS在HSS的用戶透明數(shù)據(jù)中用特定業(yè)務(wù)屬性表示用戶是否是eSRVCC用戶。

eSRVCC的缺點(diǎn)

    eSRVCC也有人分析出不足之處：

    1，不能適應(yīng)高速移動(dòng)場(chǎng)景：當(dāng)在高速列車(chē)上進(jìn)行切換時(shí)，時(shí)延還是太長(zhǎng)。

    2，復(fù)雜性：SCC-AS新增功能，引入新的ATCF/ATGW網(wǎng)元。尤其是mid-call feature業(yè)務(wù)的復(fù)雜性。