srvcc_srvcc. qci_csfb(21)

所有用户注册时（CS域 ICS用户，可能通过eMSC注册），注册信息必须经过P-CSCF->ATCF->I-CSCF。因为注册时，这些网元并不知道用户是否是合格的eSRVCC用户，甚至不知道是否是IMS用户。P-CSCF，ATCF会在用户注册时，将自己加到path路径上。 这一点是没有异议的。

有一种控制呼叫是否锚定到ATCF的方法是由S-CSCF在注册时判断用户是否支持SRVCC功能（ S-CSCF在用户注册时，可以从Cx接口的签约数据中得到用户是否有SRVCC能力（目前的Cx标准 29228-b50 中没有这个信息））

如支持，S-CSCF修改path头(使其中不含ATCF，用于被叫侧S-CSCF找下一跳）与产生service-route头(其中不需要含ATCF地址）（这里也要求S-CSCF能知道 path头中哪个URI是表示ATCF的，ATCF在注册消息的Feature-Caps中会带上自己的atc-path，另一种办法是让S-CSCF上配置ATCF域名），Service-route头在注册响应里原路返回发给P-CSCF,ATCF 等，UE把这个头反向复制到到新产生呼叫的route头中。

P-CSCF在收到呼叫消息时，删除信令中的service-route头（终端发来的，不可靠），按本身存储的service-route头再复制一份route头（当然会从中删除自己），这个呼叫消息会发给S-CSCF（不可能发给ATCF）

如用户没有SRVCC能力，通过这种方法就可以控制呼叫消息不经过ATCF。

这样：只有SRVCC的呼叫会经过ATCF。而普通IMS用户呼叫不会经过ATCF。

缓存8秒的过程

虽然锚定到ATGW的媒体端口、IP、编解码在切换前后没有变化，但信令路径发生了改变。所以ATCF需要发切换请求给SCC AS(因为原呼叫路径会自动释放)。

原IMS呼叫路径包括了UE的IMS应用、SBC、P-CSCF、SCC-AS 都会因为session timer功能或刷新注册时间到却没收到刷新注册消息，而释放呼叫。（SCC-AS在释放呼叫或收到 ATCF侧发来的bye消息时，只释放这一边的leg ，远端leg 要保留）

原IMS路径上的leg 释放，与 MSC发呼叫给ATCF ：这两个操作的时间顺序不确定。为了防止用户在session timer即将到期时发起切换，标准要求SCC-AS在收到释放近端leg的请求时，保留leg 8秒钟。

SCC-AS收到ATCF发来的新invite时，如原leg还在，SCC-AS会释放它。

在手机信号变弱时，或原呼叫的session timer到期时，UE或CSCF会发bye，但此时对于SRVCC用户会发起切换。

所以：要求ATCF、CSCF、SCC-AS 对于SRVCC用户的呼叫，在释放消息到时会缓存8秒。或只由SCC-AS来做，因为CSCF上没有用户信息，当CSCF主动发bye给SCC AS时，SCC AS

缓存8秒即可。

CSCF的sesison time到期时，向上，向下都发bye。向下发给ATCF，ATCF也要缓存8秒，以防止这段时间内切换消息从MSC发来。

如果CSCF不做这种缓存的话，就要求 SCC AS与ATCF 均要缓存8秒（如SCC有缓存，而ATCF不缓存的话，ATCF会在收到CSCF的bye时释放呼叫，后续当MSC发来切换请求时，就无法完成eSRVCC切换流程）。

eSRVCC是否兼容SRVCC

eSRVCC的流程变化关键点体现在ATCF、SCC AS。

如果要求网络中同时存在eSRVCC、SRVCC两种用户，比如对于高端用户提供eSRVCC流程，而eSRVCC流程要求ATCF的信令与媒体锚定，eSRVCC用户容量受ATCF与ATGW配置所限。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-32538-21.html