VoLTE经典学习笔记(主要流程详细解读)

作者：中国移动集团公司 张阳 （章末附作者介绍）

作者微信公众号：网优小谈（wireless_talk）

俗话说的好，一入豪门深似海，对于VoLTE这个新技术领域的学习认知也一样，相比传统的电信技术，它糅合了大量计算机互联网的理念，正可谓吸毒毁一生，学习VoLTE毁三代。但是任何复杂、先进的技术都是人类制定的，因此对于VoLTE的理解只要循序渐进，把握住总体脉络，以需求入手，应该也不是什么天方夜谭。本系列撰文拟从一个传统的无线优化工程师的思维入手，尝试逐步揭开VoLTE神秘的面纱。

1 重要网元和基础概念

如果单从电信网络的眼光去看，VoLTE不过是承载在目前4G网络中的一种数据业务而已，只不过对于这种数据业务的QOS管理、调度需要引入新的系统或者功能进行管控，这也就是我们常常说的IPmultimedia subsystem（IP多媒体子系统）或者IMS域的职责。对于无线网络优化工程师来讲，VoLTE时代的来临对于传统的网优工作存在不小的挑战，因为大量的优化工作会从无线层面上移到业务层面的优化，熟悉一些IMS域核心网络的知识变得不可缺少。这一篇简单得从一些IMS域的重要网元以及基础概念入手。

只能永远把艰辛的劳动看作是生命的必要；即使没有收获的指望，也心平气静地继续耕种。

—平凡的世界

IMS域核心网网元及接口

IMS域核心网的网元、接口众多，如果单纯从IMS子系统的角度来看，各个网元、功能实体以及接口是如下这样的

如果需要全部掌握了解，需要花费相当的功夫,所以理解这些网元不可能眉毛胡子一把抓，需要循序渐进。这里从IMS域内的协议流程需要涉及的网元入手，逐步进行摸索与理解。 这里主要有5个功能实体Proxy-CSCF、Interrogating-CSCF、Serving-CSCF和Breakout Gateway Control Function、MultimediaResource Function（其中MRF包含两个逻辑网元MultimediaResource Function Controller和Multimedia Resource FunctionProcessor）。 Proxy-CSCF

全称为Proxy-Call Session Control Function，只要是IMS域中涉及的会话流程，不可避免都要与P-CSCF、I-CSCF和S-CSCF这三个网元进行交互。P-CSCF比较好理解，类似一个代理服务器，主要负责接收服务请求并在IMS子网内部中转这些服务请求。如果需要中转到其他的域，则要通过本地出口节点（IBCF）这个网元去实现。P-CSCF不仅转发SIP注册消息，同时转发SIP消息到相应的SIP服务器（S-CSCF）。在转发SIP消息请求与反馈中，P-CSCF需要确保SIP消息中包含了当前UE所处接入网的信息。除此之外，P-CSCF还有一些功能，包括检测处理紧急呼叫请求、产生计费话单、对会话的安全性管控、执行SIP消息的压缩与解压缩、QoS管理、以及对于不同业务优先级的检测与处理。P-CSCF可以分别在拜访地网络以及归属地网络进行设置，当P-CSCF设置在拜访地网络，见下图

这两种设置方式的区别在于，P-CSCF设置在拜访地网络时，需要通过IBCF功能实体与不同域的S-CSCF进行互联，而当P-CSCF设置在归属地网络时，需要通过“发现”机制被UE来确定进行信息交互，详见3GPP 23.228 5.1.1.0。简单的来看，P-CSCF功能实体起到了电信域与IMS域沟通互联的作用，而IBCF则是不同IMS域之间的联络节点。

Interrogating-CSCF

I-CSCF是用户接入IMS子系统的节点，这里容易和IBCF的功能混淆，其实这两个功能实体有类似之处，只不过I-CSCF作为本域接入点，而IBCF往往作为跨域（跨IMS域或者与IMS域与其他IP多媒体网络）的出口或者访问节点，这两个功能上不同的逻辑节点往往可以合设为一个物理节点。除了二者对于所处IMS子系统的逻辑位置的不同，二者还是有很多相似之处。例如I-CSCF在UE注册过程先从HSS获取S-CSCF的地址，然后将该S-CSCF分配给该UE用来SIP注册，之后将SIP请求或者反馈路由到注册的S-CSCF。I-CSCF在某些场景下还起到了地址翻译的作用，当需要进行HSS位置查询时，I-CSCF需要提前将SIP请求里的SIP URI转换成电信URI的格式，如果当某些场合不需要对用户寻址的时候，I-CSCF又可能起到了将电信URI翻译成SIP URI的作用。另外当会话的目的地并不在IMS域内，I-CSCF又可以将请求转发出去，实际起到了IBCF的作用，或者直接回复接入失败。I-CSCF域IBCF皆具有产生计费话单的功能，这为漫游结算提供了支撑。

Serving-CSCF

S-CSCF是IMS子系统中极为重要的功能实体，主要负责会话控制服务。在IMS子系统中，可能存在多个S-CSCF逻辑网元，并且这些逻辑网元有各自不同的功能。S-CSCF可执行如下功能

1、通过从HSS获取的用户信息完成注册

2、当UE在注册阶段上报支持GRUU能力，S-CSCF负责为UE分配唯一的P-GRUU，同时在每次重新注册时分配唯一对应的T-GRUU，并将该UE的GRUU分配情况反馈UE（当注册信息改变的时候，例如T-GRUU改变的时候，S-CSCF也需要及时通知用户），这有点类似EPS中MME在每次UE附着时为UE分配的TMSI的流程。

3、在注册阶段，S-CSCF还应向P-CSCF和/或者UE提供基于公共用户标识的一些诸如用户优先级信息

4、对于注册后的会话流程进行管理，例如，在获知用户被禁止接入信息后，可以将会话流程拒绝掉。同时，S-CSCF可以具备代理服务器或者用户代理的一些功能，例如中转服务请求或者独立产生、终止SIP流程。

对于主叫会话发起的流程，S-CSCF首先通过呼叫用户的电话号码或者SIP URI获取呼叫用户所在网络的接入点地址，然后将SIP请求转发至该接入点。如果主叫用户和被叫用户均在同一运营商网络下，则将SIP请求转发至该网络下的I-CSCF网元。如果呼叫到PSTN网络或者CS域，则需要将SIP请求转发至BGCF网元。同时，S-CSCF需要确保主叫SIP请求和响应的内容符合IMS子网络通信服务定义。如果INVITE消息里面包含用户优先级设置或者相应的字符串，需要将这些信息同时转发转发。值得注意的一点，如果主叫请求来自于IMS内部的应用服务器，且该主叫请求所表征的用户并没有注册，那么S-CSCF需要先完成相应的注册流程，之后才会将来自应用服务器的这些请求进行相应的转发。 对于被叫会话的流程，S-CSCF需要将SIP请求与响应转发至P-CSCF，如果被叫用户位于PSTN或者电信网络的CS域，S-CSCF需要修改SIP请求信息，并通过BGCF网元将请求或者反馈进行转发。如同对主叫会话流程的管理，在转发SIP请求或者反馈的时候，需要确保SIP消息的格式满足IMS子网络通信服务定义。如果是跨IMS域的请求转发，S-CSCF需要将请求通过IBCF网元进行路由转发。

一如既往，S-CSCF也同样兼具产生计费话单功能。 Breakout Gateway Control Function

Breakout这个英文单词的释义为“突围；中断”，因此也就隐含了两层意思，就是离开IMS域，中转到其他的域，例如PSTN/CS域等。BGCF起到了对被叫用户的识别以及路由。如果

被叫用户是本网络的PSTN/CS域用户，BGCF将下一跳路由到本网MGCF，后续由MGCF进行与PSTN/CS域的交互。如果被叫用户是位于其他网络的PSTN/CS域用户，那么BGCF会首先将下一跳路由到其他网络的BGCF。如果被叫用户位于其他的IMS网络，BGCF会将消息路由到该IMS网络的I-CSCF（接入节点）。

Multimedia Resource Function

多媒体资源功能可以被分成多媒体资源功能控制单元（MRFC）和多媒体资源功能处理单元（MRFP）两个逻辑网元，如下图所示

电信网设计的基本架构思想是将控制面与业务面进行分离，例如在LTE核心网中，MME被设计用来进行信令层面的处理，而SGW/PGW则被设计用来对业务层面进行处理。IMS的核心网功能实现也存在类似的思想，就是IMS域的控制面（信令面）与业务面。对于信令的处理可以在以上介绍的网元中实现，如P-CSCF、I-CSCF、S-CSCF、BGCF等，对于媒体业务的处理主要位于应用服务器中（AS），MRF（含MRFC和MRFP）的主要功能是媒体流的处理以及提供相应的媒体资源，例如音频编码转换、媒体业务分析、多媒体放音等等。 标识

任何信令的交互首先涉及的是寻址或者基于用户、订阅业务的标识，例如电信网络中有IMSI、TMSI、P-TMSI、RNTI（RA-RNTI、P-RNTI、C-RNTI、SPS-RNTI）、GUTI等等常用的用户或者业务标识，在IMS域中同样存在类似的标识，主要有如下三种，Private User Identities、 Public UserIdentities, Globally Routable User Agent URI(GRUU)。 Private User Identities:

该标识最大的特点不是区分用户，而是标识用户不同的订阅业务。因此，对于每个用户而言，都可以包含一个或者几个这样的私有用户标识，该标识并不被用来进行SIP消息的路由寻址，而是被用来进行注册、鉴权、管理和统计。私有标识由归属地网络运营商进行分配，遵循Network Access Identifier（网络访问标识）的格式，如果没有ISIM应用，通常该私有标识会从IMSI标识中继承。通常，该私有标识的格式为用户名@域，如果从IMSI中继承，则变成了”@ims.mnc.mcc.3gppnetwork.org”。除此之外，私有用户标识不是动态标识，而是对于该用户订阅业务的永久性标识，并且在归属地网络中对于该订阅业务始终有效。在IMS域注册/去注册阶段，该私有标识需要被鉴权，HSS与S-CSCF需要存储该私有标识一边区分用户信息

Public User Identities

公共用户标识在IMS子系统内被用来进行用户间的通信。公共用户标识可以被任何用户使用，这就好比名片一样，是一种通用的载体格式。公共用户标识遵循SIP URI或者Tel URI的格式，例如，当遵循SIP URI格式时，应表示为”sip:username@domain；如果遵循电信URI格式，则应表示为”tel:+,详见IETF RFC 3966。一个用户可以包含一个或者多个公共用户标识，换言之，仅仅获得公共用户标识无法与用户进行映射。对于ISIM应用，至少需要安全的存储一个公共用户标识，但并不要求存贮该用户其他的公共用户标识。对于拥有同一化名的一组公共用户标识的操作，有点类似“一荣俱荣”，也就是需要对组内的公共用户标识进行同样的操作，这样的公共用户标识组需要分别被存储在HSS、AS（应用服务器）、S-CSCF

该标头域中不含该公共用户标识，则认为该标识注册被禁止。另外，UE需要变更前期的临时安全协商机制固化为新建立的安全协商机制.

当收到200 ok响应后，UE需要向S-CSCF订阅注册事件包。该消息中所含的参数意义如下：

Sip Message =SUBSCRIBE sip:+8618421195023@sh.ims.mnc000.mcc460.3gppnetwork.org SIP/2.0，说明需要订阅的公共用户标识的SIP URI

f：需要包含公共用户标识，这里+8618421195023其实就是电话号码 t:内容与f一致

o:事件标头域，应设置为需要订阅的“reg”事件包

重新注册

UE需要在适当的时候发起重选注册流程，例如以周期形式刷新已有的注册信息或者响应UE注册信息的变动。另外，当承载IMS会话的IP-CAN发生了变化，UE也需要发起重新注册流程。UE重新注册流程与上述UE注册流程类似。UE需要与网络侧依据上次注册时间同步更新周期注册的定时器，只不过该定时器比网络侧的定时器略小。

1、UE需要在网络侧的周期注册定时器超时前发起重新注册流程。UE将注册信息发送给P-CSCF，其中需要含公共用户标识、私有用户标识、归属地域名、UE的IP地址、能力信息、IMEI标识、是否支持GRUU的标识。

2、当收到注册请求后，P-CSCF并不用之前缓存的归属地网络接入点信息，而是重新通过归属地网络名称去发现归属地的接入点信息（I-CSCF）。P-CSCF会将注册请求转发给I-CSCF。

后续注册流程与前述一致。

注册取消

注册取消可以有两个层面来发起，一个是UE层面，另外一个是网络层面。UE层面的注册取消流程与注册发起流程是一致的，只不过注册消息里面的超时时间设置为0秒，值得注意的注册流程里的超时时间设置为600000秒。

区别于注册流程的有以下几个步骤需要注意：

1、在注册请求流程中将超时（expiration)值设置为0。

4、当I-CSCF发送S-CSCF寻址请求后，HSS根据该用户公共标识的注册状态，将S-CSCF名称发送给I-CSCF。

6、S-CSCF收到注册取消信令后，会将该消息转发服务控制平台，服务控制平台会将该公共用户标识订阅的相关服务信息清除。

7、根据运营商定制策略，S-CSCF会将含公共用户标识、私有用户标识、清除S-CSCF名称或者保留S-CSCF名称的Cx接口信令发送HSS。HSS根据收到的清除S-CSCF名称/保留S-CSCF名称来进行相应的S-CSCF名称保留，即使保留S-CSCF名称，后续HSS可以决定在任何时刻进行清除。

9、当S-CSCF发出200 ok响应信息给I-CSCF后，S-CSCF释放该公共用户标识所有相关的注册信息。 11、当P-CSCF发出200 ok响应信息给UE后，P-CSCF释放该公共用户标识相关的注册信息，而如果存在关于IMS信令链接状态的订阅通知，P-CSCF需要取消该订阅通知。

网络层面发起的注册取消。

有些特殊情况下，例如终端没电了，或者UE移出了服务区，网络侧需要发起对用户的注册取消流程。网络侧发起注册取消流程主要是为了在这些场景下对用户后续提供稳定有保障的服务。网络侧发起的注册流程取消仅仅针对IMS子系统内，与接入网状态无关。即IMS域注册取消后，LTE网络并不一定去附着。一般，IMS子系统发起注册取消流程有如下的原因： 网络维护：解决用户重新注册带来的网络节点相关数据缺失；

网络业务：当用户漫游到其他网络而并没有在源网络进行注册取消； 应用服务：由服务能力受限导致的注册取消；

订阅管理：当用户欠费、恶意欺诈、取消订阅等等导致的网络发起的IMS注册取消。另外对于用户变更服务，也可能导致网络侧发起IMS注册取消。

诸如以上的原因，网络侧发起的注册取消可以通过两个流程触发，一个是注册超时，另外一个则是强制流程。

对于注册超时而言，P-CSCF与S-CSCF各自维护一个定时器，这两个定时器需要时间足够接近，并且彼此之间不做同步。因此，当S-CSCF定时器超时后，P-CSCF的定时器也认为超时，这样P-CSCF可以直接将UE注册取消，而不需要等待S-CSCF注册取消的指令。详见23.228.

注册取消流程可以由HSS、S-CSCF或者第三方网元（第三方网元通过HSS）发起，下图说明了由HSS（含通过HSS流程发起的第三方）发起的情况

在这里不对注册取消流程细节做详细的说明，不过需要提及值得注意的几个关键步骤。对于步骤3，S-CSCF在向P-CSCF发起注册取消流程的同时，需要内部同步该用户的注册信息。如果收到HSS关于注册取消的原因，可将原因一并转发。一般由于UE不在服务区的原因，P-CSCF在向UE发出注册取消流程后，不一定能收到UE的响应，这时，PCSCF可以不必等待该200 ok响应，直接向S-CSCF发起响应流程。

下图说明的是由S-CSCF（或第三方网元通过S-CSCF）、服务控制平台发起的注册取消流程。

于HSS发起的注册取消流程唯一不同的是，S-CSCF在接收到P-CSCF注册取消流程完成响应之后，才通过Cx接口向HSS发送注册信息清空流程。

3 主叫信令流程

登高，坡顶自有青云；倘若正有一朵白云闪耀，那就望云爬坡吧！

注册的目的是信息登记，并为后续的主被叫提前进行了相应的寻址。例如，主叫流程中信令所经历的网元路径就是在注册阶段被分配好的，并在该UE注册期间保持不变。

IMS域的的主叫信令流程总览如下：

1、首先UE向P-CSCF发出SIP INVITE请求，包含初始SDP消息，该初始SDP消息包含一个多媒体会话的一个或多个媒体流。

UE需要在INVITE消息了嵌入Accept:application/sdp,application/3gpp-ims+xml，这里主要指明了MIME(MultipurposeInternet Mail Extensions)的业务格式类型（例如XML、HTML或者还是WMV等业务媒体格式），以便被服务器进行正确的解码处理，这一点在计算机应用中很普遍，如果没有注明正确的类型，后果很难评估；

P-Early-Media: supported，支持该消息意味着支持主叫早放，例如，当收到180振铃指示，UE按授权进行相应的媒体播放；

P-Preferred-Identity: sip:+8613454444994@zj.ims.mnc000.mcc460.3gppnetwork.org,这里提供了用户的公共标识，与后续从S-CSCF传来的P-Asserted-Identity保持一致；

P-Preferred-Service:urn:urn-7:3gpp-service.ims.icsi.mmtel, IMS Communication Service Identifier(ICSI),IMS通信服务标识符在UE与网络侧标记着应用。UE通过该标识符分发SIP消息到正确的应用，而网络侧通过该标识选择正确的应用服务器；

a: *;+g.3gpp.icsi-ref=\媒体类型标签，标识着终端可支持的软件应用，同时也表征着终端的能力(例如该终端是个电话或者是PDA)；

在初始SIP请求中包含的SDP消息应严格符合RFC 4566中定义的SDP协议格式，包含不同域的排列顺序、以及域中内容的格式要求。

例如，从以上信令截图就可以解读如下信息：

该SDP协议版本为0，采取IPv6协议进行传输，会话类型是VOIP业务，这是一个单播业务，RTP包的带宽，会话活跃授时是不受限的，媒体类型为音频，传输端口为50010，传输协议RTP/AVP，同时还指明20ms产生一个音频包。音频采用动态编码格式，并且该媒体格式是收发式的。

当P-CSCF收到INVITE消息时候，需要反馈100（Trying）消息，意味着该消息P-CSCF已经收到，后续信令还在继续前送；

2、P-CSCF通过用户注册信息进行下一跳S-CSCF的转接。同时，P-CSCF根据用户注册信息或者存在INVITE消息里的用户优先级信息进行相应的优先级处理，并更新后的INVITE消息转发S-CSCF；

3、S-CSCF需要校验服务类型，如果请求中含有GRUU，需要确保GRUU与公共用户标识属于同一服务类型，同时基于用户的订阅的多媒体类型对用户SDP消息进行鉴权；

4、S-CSCF将INVITE消息转发到被叫的S-CSCF，如果INVITE消息里含有用户优先级信息，应一并转发；

5、S-CSCF接收反馈，其中包含了目的网络媒体流的能力；

6、S-CSCF将Offer Response消息转发到P-CSCF；

7、P-CSCF确保为此次会话提供的资源情况；

8、P-CSCF将Offer Response消息转发到终端；

183会话进程响应用来传递会话进程的信息，183消息里面的消息原因、标头域、消息实体可被用来传递关于会话进程更多的细节。

9、UE确认接收Offer Response消息，并将响应确认消息发送P-CSCF；

10、资源预留阶段，取决于IP接入网的策略，该资源预留既可以由UE发起也可以由接入网络发起，如果由UE发起，则在步骤8完成之后，如果由IP接入网发起，则在步骤7完成之后就可以触发；

11、P-CSCF将响应确认消息转发S-CSCF;

12、S-CSCF转发响应确认消息到被叫端网络；

13-15、被叫向主叫进行响应确认应答（这里真是来来回回的确认，不像电信网最多三次握手确认）

16-18、一旦资源预留完成，主叫UE发送资源预留消息并经P-CSCF中转至被叫端；

19-21、当被叫端资源预留成功后，反馈主叫端资源预留成功

22-24，被叫侧产生振铃，通过一系列网元转发主叫侧；

25、主叫UE通知用户被叫振铃；

26、当被叫接续后，被叫侧产生SIP-200最终响应；

27、S-CSCF将SIP200最终响应沿已建立好的信令通道发送P-CSCF；

28、P-CSCF指示已鉴权的媒体面启动（即后续可以传送话音）；

29、P-CSCF将SIP200最终响应回送至主叫端；

30、UE开始进行媒体传送（话音）

31-33、UE对200 OK进行SIP ACK的反馈

200 ok是对INVITE的最终反馈，如果收到最终反馈后，UE还应该发送BYE消息将之前的对话终止，这里BYE结合后续的无线侧信令看，应该是一个主叫用户挂机释放指示。

4 被叫信令流程

唐代大诗人李白曾经道过行路难，\行路难！行路难！多歧路，今安在？\

在学习VoLTE这个新的承载话音技术上，面对的困难与茫然某种程度上并不亚于唐朝诗仙所面临的困惑，但是男子汉需要勇气和毅力去克服人生中存在的艰难，有时候，明知道不可能，却还要去尝试，这就是年青人该做的。我们都想在世界这个大海上乘风破浪，在海的另一边，有着我们所不知的广阔天地。在知识海洋的彼岸，也还有太多我们不知道的风景，我想亲眼去看一看，亲身去体会。

VoLTE的被叫信令流程相比主叫信令流程要复杂一点，一般通信系统的被叫信令流程相比主叫信令流程都要复杂一点，因为往往不知道用户的位置需要进行相应的寻呼寻址，基于IMS架构的VoLTE被叫寻呼流程也是一样的，往往不知道用户是处于何种状态，例如，漫游状态、归属地、非LTE网络（UMTS/GSM/PSTN）等等，虽然涉及到的内容略显复杂，但是整体信令脉络是大致相似的，涉及到的不同状态，无非就是新增一些网元以及专属信令流程而已。

纵观被叫终端分别在漫游地和归属地的信令流程，除了涉及到P-CSCF的位置不同外，没有什么太大的区别，我们以漫游地的信令流程入手进行解读。

1、主叫发送SIP INVITE请求，包含初始SDP，经理主叫流程以及中间流程，最终发送到被叫侧的S-CSCF； 2、被叫侧S-CSCF校验服务请求同时触发服务逻辑单元。这里基于用户订阅的多媒体服务情况，对请求的SDP进行鉴权；

3、S-CSCF根据之前UE注册时的信息，将INVITE请求转发到之前记忆的P-CSCF;

4、如果P-CSCF决定被叫是MPS会话（多媒体优先级会话），P-CSCF获取对话信息并且调用动态策略，将获取的用户信息发送PCRF网元。P-CSCF通过之前UE注册时记忆的UE地址，将INVITE转发至UE；

下述信令截图就是INVITE的消息内容，从这里我们可以看出一些信息：

(1)主叫与被叫遵从电信URI的格式，即用tel方式进行公共用户标识表征，可以看出主叫来电号码是18407404056，被叫电话号码是18407404056；

(2)Call-ID:amCanUH-KnuK3GPdcuGJySgOHl87SpbfCHKujkAGJj3YyIbH22AbyEDy-Rwrym9difa@zteims,Call-ID是为了对同一用户的会话进行标识，因此在对话中同一个用户的请求和响应中，Call-ID是唯一的，另外对于同一用户，该Call-ID也应该是全球唯一的标识符，同时一般Call-ID以一种随机加密的方式（RFC1750）出现，使用该随机加密方式可以保护会话不被非法截获，同时可以减少Call-ID的冲突，一般call-ID是由随机加密序列结合主机名称或者IP地址产生。值得注意的是，在单一多媒体会议中，对于用户发起的对同一实体邀请，可能每次分配的Call-ID都不尽相同。有趣的是，主叫的Call-ID与被叫接收的INVITE信息的Call-ID不一样，主叫Call-ID是终端发起的，因此与终端分配的IP地址有关，被叫Call-ID是被叫所处IMS域S-CSCF发起的，因此打上了被叫域S-CSCF的标签；

(3)Cseq: 1000 INVITE。Cseq对消息处理进行标识和排序。INVITE需要与对应的消息类型保持一致（INVITE）。对于对话外非注册消息的Cseq，可以是设置为任意值。在同一对话内，该值随着消息每传递一次进行+1的增量同步。其中一种设置方式可在初始设置时将其与时间（秒级）关联； (4) Record-Route: ,Record-Route是由P-CSCF插入的，目的是为了使后续的请求(Request)依然能通过该代理进行路由，在请求从主叫路由到被叫所经历的一些代理服务器中，Record-Route是可以被替换或者改写的； (5)

Contact: ;audio;video;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting;+g.3gpp.ps2cs-srvcc-orig-pre-alerting;+g.3gpp.icsi-ref=\l\

Contact里面包含一个SIP URI地址，<>里面包含的就是SIP URI地址以及相应的URI参数，<>之外的是包头参数，而不是URI参数。一般可以认为Contact与Via是对应出现的，Via告诉后续的响应消息（Response）将要发送的地址，而Contact则指示了后续的请求消息（Request）将要发送的地址。除了SIP URI地址这些信息之外，Contact里面还包含了一些支持主叫UE能够支持的特性以及能力；

(6) Via: SIP/2.0/UDP

[2409:8099:0:20::1]:5062;branch=z9hG4bK-*5*01eb3dceecc83856d94btaN0 Via里包含了期望响应消息发送的地址。Branch参数区分了该请求创建的交易。并且在客户端以及服务器端，除了Cancel以及Ack请求，Branch参数被唯一使用。Cancel消息里的Branch参数需要与被Cancel的请求里的Branch参数保持一致。Ack里的Branch参数应该与Invite里的Branch参数；

(7) Content-Disposition: session, 这里对用户端（含客户端和服务器）描述了消息实体的类型为session(会话)，如果这一栏丢失，则接收端置为默认设置，如果没有默认设置，则置为render(展示)类型；

(8) P-Called-Party-ID: , 这项报头内容只在被叫中出现，里面包含的信息就是被叫UE的公共用户标识。

(9)Supported: 100rel,precondition,timer。这里可选项100rel的出现可以判定SIP message来自于MGCF，也意味着主叫电话来自于交换域。

(10) Session-Expires: 3600;refresher=uac Min-SE: 90

这两条报头往往需要结合一起来看，Min-SE决定了session在代理服务器或者UE之间最小的更新间隔，意味着代理服务器在处理request时不允许恶意将其修改更低，而

Session-Expire则决定了更新的上限，在该值超时前如果没有收到周期的re-INVITE或者UPDATE消息，则会话认为结束。同时更新是由发起request的一方（uac）来启动；一般可以设置30分钟（1800秒），这是由于认为95%的会话在30小时内就结束了，不过随着新技术的实施，将该值适当拉大也可以接受（详见 RFC4028）。

(11) P-Asserted-Identity: ，该包头域应该与主叫UE发出的P-Preferred-Identity捆绑起来解读。这里涉及了一个trust domain的概念，如果在信任域之间发送，代理服务器收到了P-Preferred-Identity，如果同在可信域之内，该值作为服务器可参考值，可在被插入后续的P-Asserted-Identity包头域中，P-Preferred-Identity值。

Asserted Identity意味着该值已被证实，这个值对于接收端的UE来讲，意味着比From包头域的值更值得信任。Asserted的值出现是为了简化鉴权（防止恶意篡改，更改，重放主叫号码）来电号码而产生，这样在信任域内的不同SIP服务节点转发该值，无需再重新进行该值的修改。但是发送到信任域之外，需要将该值删除或者进行一些私有加密的处理。这两个包头域的取值设置可以是SIP,SIPs URI或者Tel格式，同时对于中间转发的服务器，最多可添加一个SIP或者SIPs URI和最多一个Tel URI；

(12)Feature-Caps: *;+g.3gpp.srvcc;+g.3gpp.mid-call;+g.3gpp.srvcc-alerting, Feature-Caps包头域说明了在SIP信令传送中途径的SIP实体所支持的特性和能力，与Contact包头域的URI里所支持的特性和能力形成对比的是，Contact包头域里的SIP URI表征的SIP实体支持的能力不允许出现在Feature-Caps里面。一个SIP消息中可以包含多个SIP实体所添加的Feature-Caps包头域，采取先到先添的原则，后一个添加得保证都在这些包头域的置顶位置。从这里我们可以解读到在信令消息转发途径的SIP实体会支持SRVCC，mid-call，甚至支持在alerting过程中的SRVCC切换流程；

(13) Accept-Contact:

*;+g.3gpp.icsi-ref=\该包头域是主叫端对被叫端UE所具备的能力偏好要求，在经过一系列的IMS网元后，服务器会参考该包头域所规定内容，依据偏好选择设置，对被叫端进行选择；

5、UE根据自身是否支持主叫端发起媒体流的子集情况，反馈Offer Response消息。SDP消息中表示多媒体对话中一个或者多个媒体信息。该反馈响应发送至P-CSCF

183阶段主要做的语音编解码协商，m=audio 50010 RTP/AVP 104 105，可以看出被叫UE支持的是104、105编码格式，含意如下 a=rtpmap:104 AMR-WB/16000/1

a=fmtp:104 mode-change-capability=2;max-red=0

a=rtpmap:105 telephone-event/16000/1

a=fmtp:105 0-15，这里采用的是AMR宽带语音编码方式，采样率为16000Hz，同时

telephone-event说明了一些支持DTMF信令的情况（双音多频，主要发送号码用的）；

6、P-CSCF对该对话的所需资源进行授权，值得注意的是，在第4步的时候，P-CSCF就可以根据PCRF反馈信息确认为主叫所进行的资源预留情况；

7、P-CSCF将Offer Response消息转发到S-CSCF;

8、S-CSCF将Offer Response消息转发到主叫所处IMS域；

9、主叫侧发送响应确认（Response Confirmation）。响应确认中可以包含SDP信息，这些SDP代表的媒体流信息可以与第8步中的包含的SDP信息保持一致，互或者也可以是其子集。如果SDP中定义了新的媒体，在第12步后P-CSCF（PCRF授权）重复第6步，进行重新的资源授权。主叫可以很灵活的在这一步添加新的媒体和在后续用Update方法添加，但每一次新媒体的添加都会导致P-CSCF（PCRF）重复第6步的资源授权；

10、S-CSCF将响应确认转发到拜访地的P-CSCF，其间可根据运营商配置策略经由I-CSCF路由送达；

11、P-CSCF将响应确认发送被叫UE；

12、UE对Response Confirmation进行应答（200ok）。如果可选的SDP信息被包含在Response Confirmation里，那应答中应该也包含SDP响应。如果SDP信息变化了，P-CSCF授权资源可以被使用；

13、根据运营商IP网络策略，这里需要进行IP资源预留。IP资源预留可以在第6步之后由IP接入网发起，或者可以在这里由UE发起；

14-15、P-CSCF将确认应答消息通过S-CSCF转发到主叫节点；

16-18、当主叫节点完成了资源预留，发送资源预留成功消息到S-CSCF，S-CSCF将该消息转发到被叫侧；

19、被叫UE振铃

20-22、被叫UE反馈资源预留成功；

23-25，UE进行180持续振铃响应；

26、当被叫UE接通电话，向P-CSCF发送200 ok的最终响应 27、P-CSCF启动为该会话预留的媒体流资源；

28、被叫UE启动媒体流资源；

29-30，P-CSCF转发200 ok最终响应；

31-33、主叫侧对200-ok最终响应进行SIP ACK响应应答，该消息通过中间服务器转发到被叫侧；

注：这里被叫UE侧的log截取有一些奇怪的现象，有可能是网络侧的一些设置问题，虽然不影响该次电话的接通，但是仍然值得进行后续的研究；

问题1:

P-Access-Network-Info:

3GPP-UTRAN-TDD;utran-cell-id-3gpp=46000E38A708F302;\amobile.com\-port=5068\

Supported: 100rel,precondition,timer 这些现象说明主叫电话在TD-SCDMA上，但是现网TD-SCDMA并不与IMS互通，也不承载VoIP话音，同时检索主叫侧log，发现主叫UE是在LTE网络上进行起呼的，至于具体原因为什么会导致这样，建议逐SIP节点进行定位确认；

问题2:

SIP UPDATE信令消息中含有如下SDP内容

m=audio 20686 RTP/AVP 104 105 8 0 18 101，意味着到达被叫的UPDATE消息进行最终编解码协商时同时支持104，105，8，0，18，101，但是检索主叫侧UPDATE消息，只涵盖了104,105，也就是说其他编解码消息是网络侧附加上去的，至于具体原因是什么，只能通过IMS厂家进行辅助定位了。

还是以诗仙李白的名句作为本篇结束的注脚，长风破浪会有时，直挂云帆济沧海。

5 SRVCC

写此类技术文章甚为枯燥，经常在结束一天疲惫的工作后，不仅需要抗拒身心的慵懒，同时还要在台灯下查阅各种详细资料以求得专业文章描述尽量精准。写这些非专业人士看不懂的“天书”意义到底何在呢？有人说还不如利用时间炒股来的实在。诚然，在追名逐利的时代，耗费心血写些劳什子的技术八股文简直是拖时代的后腿，但是人总要活得有点情怀，经常看到文章教导我们说要不忘初心，初心到底是什么？初心其实就是你来到这个世界最本真的诉求，内心不过多受外界环境左右所渴求的梦想。笔者多年以来浑浑噩噩，近几年以来才渐渐的发现了自己的初心，写这些文章不是要改变世界，拯救产业，只不过回归了一把读书人恬

淡与执着。古人讲究修身、齐家、治国、平天下，这也许就是中国人最朴素的信仰，虽然后三者还没实现，但通过潜心治学修了把身，也算能做到谈笑有鸿儒，往来无白丁了吧。

VoLTE技术里面重要的一项流程就是SRVCC（eSRVCC可以看成SRVCC的增强，本文后续进行介绍）。目的类似于跨系统的互操作，为了在LTE覆盖受限的区域保证用户VoLTE通话的连续性，需要进行跨系统SRVCC（Single Radio Voice Call Continuity）。从接入网角度进行观察，SRVCC也同样经历测量、判决等相应步骤，因此可以认为是一种跨系统的切换，但是区别于传统的例如23G话音CS-CS域切换，SRVCC一般则属于PS-CS域的一种切换流程。互操作流程一般是网络优化技术中研究的热点、难点，SRVCC也不例外，对于LTE网络建设的初级阶段，不可避免会触发大量SRVCC流程。

熟悉SRVCC技术，不仅需要从流程入手，同样需要重视IMS网络架构原理，因为为了引入SRVCC，网络结构起了相应的变化，也新增加了跨系统的接口。

以下列出一些笔者觉得比较重要的概念

1、协议（23.216）规定SRVCC的触发条件应该与E-UTRAN与UTRAN/GERAN的PS切换流程保持一致，也就是说，当触发PS切换事件满足后，也应该能够触发SRVCC切换；

2、对于视频电话，LTE网络侧需要分别为视频以及话音建立两条独立的EPS承载；

3、对于漫游情形，拜访地网络需要根据用户归属地网络策略进行相应的跨系统/跨域转换；

4、在IMS网络中引入针对（v）SRVCC的网络锚点，SCC AS；

5、QCI=1只被作为话音承载；

6、多个媒体流复用有如下方式，可以多个媒体流的话音复用一个话音承载，而视频分别承载在相应的视频承载上；也可以多个媒体流复用在一个媒体承载上；

7、协议表明SRVCC不仅从EUTRAN的PS域到CS域，同时也可以从UTRAN/GRRAN的CS域到EUTRAN的PS域，不过现网只进行了单向的转换，即PS-CS转换，在该篇笔记中我们将注意力聚焦在PS-CS切换上；

一旦上传测量报告触发异系统测量以及切换判决门限，MME会通过S1收到切换请求。如果MME含有关于该UE的STN-SR标识，MME会通过与MSC Server的Sv接口触发SRVCC

流程。MSC server会与IMS进行协商，同时与UTRAN/GERAN目标小区互动进行CS域切换资源准备。当MSC server完成资源准备后，会通过Sv接口向MME发送CS切换响应，同时也会包含必要的CS域切换信息，例如频点、邻区等信息。如果在触发SRVCC时，用户同时保持了PS的数据业务，在SRVCC的流程里，数据业务同样也要进行切换，即PS-PS切换， MME负责协调整个流程中的PS-PS切换响应以及SRVCC的PS-CS切换响应。

如上图所示，这里需要改造的是MSC Server，因为其主要功能不仅在于与MME进行互联，同时还存在于与IMS域协调执行SRVCC流程。对于支持SRVCC功能的UE，需要在LTE网络Attach或者TAU过程中上报的字段“MS Network Capability”中都要明确。MME会存储相应的UE能力信息。如果UE的所支持的能力有所改变，需要通过TAU流程上报改变后的能力信息。另外值得注意的是，关于终端支持的MSClassmark3,MS Classmark 2，支持的编码方式等字段是通过附着请求或者非周期的TAU进行更新的。在这里，为了SRVCC流程实现，需要对一些新增实体功能进行定义：

1、MSCServer增强

（1）处理来自MME关于话音的重定位准备流程请求，如果来自Sv接口附带有优先级标识（ARP），则进行一并处理；如果收到ICS（以IMS作为中央控制的业务逻辑）的标识（true），则将MSC Server作为ICS受控实体；

（2）协调CS切换以及会话迁移

（3） 无需等待UE触发LAU,即可处理MAP_Update_Location；这里也隐含着一层意思，对比CSFB流程，CSFB回落2G过程中，起呼之前是需要做LAU通知MSC server此时UE处于的位置，但是SRVCC属于切换流程，MSC Server通过资源准备，预先知道UE回落的小区，因此可以不需要UE触发就进行核心网侧位置区更新流程。

2、MME

（1）增加PS承载分离处理功能，即可以区分处理承载语音以及数据的两种PS承载；

（2）能够处理数据业务的PS-PS切换流程； （3）处理话音业务的SRVCC的切换流程，如果多个话音承载中包含一个紧急会话，那么MME只处理紧急会话的SRVCC流程；

（4）兼具协调并发PS切换以及SRVCC切换的能力

（5）MME需要具备传递优先级指示的能力。

3、E-UTRAN

LTE接入网功能在SRVCC流程中涉及空口的实体并不需要改变，但是需要有能力通知MME该切换流程为SRVCC。另外，E-UTRAN无法动态获取周边4G邻小区列表信息，因此，如果当一个VoLTE话音用户尝试切换一个没升级（及不支持VoIP）的目标小区时，将会被该目标小区拒绝。

以下结合SRVCC现网的一些实际测试log对主要信令流程进行解读（这里2G或者终端不支持DTM模式）：

1、以下log可以看出在执行SRVCC切换之前的最后一次测控消息，下发了需要测量的2G频点列表（已通过OMC预先进行配置），同时下发了异系统判决事件以及相应门限，这里下发的是B1事件的门限，可以估计是某厂家的设备；

最后一次测量上报结果说明测到了绝对频点号（arfcn）为70，网络色码010，基站色码100的GSM小区满足触发判决门限需要，上报基站等待后续切换判决；

2、根据UE的测量报告，eNodeB决定是否触发想GERAN的SRVCC切换

3、源eNodeB向源MME发送切换请求，其中包含目标ID，一般源至目标透传容器（原谅我没有能更好的中文翻译），SRVCC切换指示。一般源至目标透传容器中包含旧BSS到新BSS的消息，同时SRVCC切换指示表明只切换到目标小区的CS域，并不包含PS业务的切换；

4、MME中的承载分离功能根据与QCI1相关的话音承载以及SRVCC标识将话音承载从非话音的PS承载中分离出来，并启动PS-CS切换；

5、MME向MSC Server发送SRVCC PS-CS切换请求，其中可以包含鉴权过的IMSI、目标ID、STN-SR, C MSISDN, 一般源至目标透传容器，加密安全信息、Emergency Indication；

6、如果是MSC Pool组网，MSC Server会通过2G核心网内部流程发送切换准备请求至目标MSC,如果MSC Server收到了关于优先级的ARP，也封装在切换准备请求中发送到目标MSC；

7、目标MSC与目标BSS通过切换请求/应答进行资源分配。如果目标MSC指示了优先级，则BSS根据优先级进行相应无线资源分配，这里意味着优先级用户在VoLTE中享受什么样的服务，那么在SRVCC后到2G享受同样的服务；

8、目标MSC向MSC Server发送切换准备响应消息；

本文来源：https://www.bwwdw.com/article/njk3.html