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

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

eSRVCC方案對于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的信令傳輸時間。

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

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

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

    切換的信令面變化，參見：

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

    媒體面的切換路徑參見：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      ATCF在注冊消息的Feature-Caps頭部攜帶了多個信息：

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

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

        STN-SR實(shí)際上分兩種：STN-SR、vSTN-SR。見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，并才能在呼叫、切換時進(jìn)行特定處理)，

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

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

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

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

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

    對于接受注冊和VoLTE呼叫的ATCF來說，需要讓MSC把切換請求發(fā)給自己。這樣才是完全的“錨定”功能。

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

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

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

      STN-SR是給MSC在切換請求時使用的，由ATCF在注冊時產(chǎn)生。 一般是標(biāo)識ATCF的全局PUI，或稱為PSI，因為是給MSC用的，一般是Tel URI格式。 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       在呼叫消息中支持對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)切換。

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

     ATCF沒有錨定媒體

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

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

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

MSISDN ：可能包括幾個號碼，即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請求"MSISDN"時，需要在"User Identity"中填寫PUI，在"User-Name"中填寫PVI(從SIP注冊消息的Authorization中獲取) .

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

       所有VoLTE用戶中并非所有用戶都是eSRVCC用戶。或者部分用戶是SRVCC用戶、另一部分用戶是eSRVCC用戶。因為eSRVCC用戶的語音質(zhì)量更好，可能視為高端用戶。這里的想法是：如何區(qū)分SRVCC用戶、eSRVCC用戶或非SRVCC用戶。

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

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

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

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

      P-CSCF在收到呼叫消息時，刪除信令中的service-route頭（終端發(fā)來的，不可靠），按本身存儲的service-route頭再復(fù)制一份route頭（當(dāng)然會從中刪除自己），這個呼叫消息會發(fā)給S-CSCF（不可能發(fā)給ATCF）

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

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

緩存8秒的過程   

       雖然錨定到ATGW的媒體端口、IP、編解碼在切換前后沒有變化，但信令路徑發(fā)生了改變。所以ATCF需要發(fā)切換請求給SCC AS(因為原呼叫路徑會自動釋放)。

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

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

       SCC-AS收到ATCF發(fā)來的新invite時，如原leg還在，SCC-AS會釋放它。

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

      所以：要求ATCF、CSCF、SCC-AS 對于SRVCC用戶的呼叫，在釋放消息到時會緩存8秒。 或只由SCC-AS來做，因為CSCF上沒有用戶信息，當(dāng)CSCF主動發(fā)bye給SCC AS時，SCC AS緩存8秒即可。

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

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

eSRVCC是否兼容SRVCC

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

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

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

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

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

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

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

      兩種看法：

1，ATCF部署后，網(wǎng)絡(luò)中只有eSRVCC用戶，沒有SRVCC用戶（因為eSRVCC與SRVCC對終端的要求是一樣的，只是網(wǎng)絡(luò)側(cè)能力不同）。則SCC AS只要發(fā)現(xiàn)用戶注冊、呼叫帶了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)在高速列車上進(jìn)行切換時，時延還是太長。

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