注：本文中的SRVCC都是指eSRVCC方案。
SRVCC相关的3GPP规范有：
- 3GPP TS 23.216 SRVCC
- 3GPP TS 23.856 “Single Radio Voice Call Continuity (SRVCC) enhancement; Stage2.”
- 3GPP TS 23.237 IMS Service Continuity Stage 2
- 3GPP TS 24.237 IMS Service Continuity Stage 3
详细的SRVCC流程和描述可搜索网络教程之类的：
Evolution of Single Radio Voice Call Continuity (SRVCC) | 4G 5G World
VoLTE信令系列--SRVCC/eSRVCC-腾讯云开发者社区-腾讯云
SRVCC PS-CS Access Transfer
下面总结了一些SRVCC相关的知识点：
1) UE是否支持SRVCC Capability的信息交互
如下图所示：
- 用户开机做位置更新时，UE的SRVCC Capability上报给HSS；
- 用户进行IMS Registration时，SBC根据收到的信息附上ATCF相关的信息（如STN-SR）发往S-CSCF和SCC AS，进行三方注册；
- SCC AS查询HSS，获取UE和用户是否支持SRVCC Capability；之后把更新的STN-SR发送给HSS和MME，把ATU-STI，C-MSISDN等信息发送给ATCF。
2) 注册时ATCF相关的Feature Capabilities
这是IMS REGISTER消息中的内容：
Feature Cap: g.3gpp.atcf="<tel:+399123456789>"
Feature Cap: g.3gpp.atcf-mgmt-uri="<sip:3157902161@sbc01.moon.com>"
Feature Cap: g.3gpp.atcf-path="<sip:3157902161@sbc01.moon.com;transport=udp;lr>"
Feature Cap: g.3gpp.srvcc-alerting
Feature Cap: g.3gpp.ps2cs-srvcc-orig-pre-alerting
Feature Cap: g.3gpp.mid-call
以下是3GPP TS 24.237中的描述：
- The value of the g.3gpp.atcf feature-capability indicator contains the STN-SR allocated by ATCF.
- g.3gpp.atcf-mgmt-uri feature-capability indicator for receiving SIP requests where the ATCF performs the UAS role, indicating the management URI of the ATCF for receiving SIP MESSAGE requests containing SRVCC related information and the g.3gpp.atcf-path feature-capability indicator.
- The value of the g.3gpp.atcf-path feature-capability indicator is the ATCF URI for terminating requests, identifying the registration path, so that SCC AS can provided the SRVCC related information related to the registration path.
- The "ATCF-Path-URI" attribute of the <SRVCC-info> element contains the ATCF URI for terminating calls of the registration path (or registration flow, if multiple registration mechanism is used).
>g.3gpp.atcf就是ATCF的STN-SR号，用于MGCF（即MSC Server）寻址到ATCF。
> g.3gpp.atcf-mgmt-uri是ATCF的管理URI，一个典型例子是用于三方注册后接收SCC AS发过来的SIP MESSAGE请求（含有SRVCC信息）：SCC AS把该URI放入MESSAGE的Request-URI中，如下图所示：
> g.3gpp.atcf-path用于接收终止于ATCF的请求，通常与g.3gpp.atcf-mgmt-uri的URI相同，但具体使用场景语焉不详。该URI在IMS REGISTER请求消息中发送给SCC AS后，SCC AS把它放置于上图MESSAGE消息中的“SRVCC-info”标签中的ATCF-Path-URI，返回给ATCF。
> g.3gpp.atcf和g.3gpp.atcf-mgmt-uri也会放置在IMS REGISTER请求消息的<Path>域中：
> g.3gpp.atcf和g.3gpp.atcf-mgmt-uri的用户部分是在每次Register时产生的唯一标识。
3) 媒体面media plane的转换和信令面Dialog的释放
如下图所示，SRVCC之后：
- 媒体面转换成UE到MSC/MGW，和MSC/MGW到ATGW的两段path，远端Media path不变。
- 原IMS呼叫路径（call leg）上的对话Dialog，经过了UE、SBC(P-CSCF)、S-CSCF和SCC AS，在session timer到期时，SCC AS会发起BYE请求进行释放；远端leg保留。
注：ATU-STI由SCC AS自己配置，用来识别呼入请求是否是SRVCC切换请求；C-MSISDN作为主叫号码出现在INVITE消息的PAI域 。
4) S-CSCF是否参与
S-CSCF在SRVCC的过程中会参与吗？
通常的方案是不参与：三方注册成功后，SCC AS发送SIP MESSAGE直接到ATCF（可能会经过I-CSCF)，跳过了S-CSCF，用户的C-MSISDN不会保存在S-CSCF中。之后ATCF在收到MGCF发过来的SRVCC请求后，直接用ATU-STI发起新的INVITE到SCC AS，也不经过S-CSCF。
另外一种方案是ATU-STI配置成一个公共业务标识PSI，ATCF用ATU-STI发起INVITE请求之后，被I-CSCF路由到一个S-CSCF，触发“sescase=term;regstate=unreg”的呼叫场景，参与到这个新call leg建立的SRVCC过程中。
5) SDP中Connection信息变化（即媒体media IP地址和port）
整个SRVCC过程中ATGW的媒体IP地址和Port号保持不变，只是access leg远端的RTP IP和Port由UE1的媒体IP地址，变成上图中MSC/MGW端的IP地址和Port号。
6) 其它
> MGCF发往ATCF的INVITE请求，和ATCF发往SCC AS的INVITE请求，两者的Call-ID可能相同。
> ATCF发往MGCF的响应中，所使用的<Contact>域信息，就是之前在PS leg建立时SCC AS发往ATCF的响应中使用的<Contact>域信息。
> 3GPP TS 24.292中有关Target Dialog的描述：
– if the SIP INVITE request contains a Target-Dialog header field containing dialog parameters that correspond to an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS the ICS UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog identified by the dialog parameters contained in the Target-Dialog header field;
– if the SIP INVITE request does not contain a Target-Dialog header field but there is an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS the SCC AS shall check if the dialog parameters for this request correspond to the dialog parameters received in a Target-Dialog header field received on an existing dialog (or a dialog in the process of being established) between the ICS UE and SCC AS and if so then the ICS UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog that the Target-Dialog header field was received on.
NOTE: The second case is to cover the possibility that requests can arrive out of the order that they were sent
