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

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

步骤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，如图5-37所示。

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

图5-36 漫游地信令流程

图5-37 INVITE消息内容

主叫与被叫遵从电信URI的格式，即用te1方式进行公共用户标识表征，可以看出主叫来电号码是18407404348（参考图5-37From：＜＞），被叫电话号码是18407404056（参考图5-37To：＜＞）。

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

Cseq：1000 INVITE。Cseq对消息处理进行标识和排序。INVITE需要与对应的消息类型保持一致。对于对话外非注册消息的Cseq，可以设置为任意值。在同一对话内，该值随着消息每传递一次进行+1的增量同步。其中一种设置方式可在初始设置时将其与时间（秒级）关联。

Record-Route：＜sip：DIAG 5005003a66＠[2409：8099：0：20：：1]：5062；1r＞，Record-Route是由P-CSCF插入的，目的是使后续的请求（Request）依然能通过该代理进行路由，在请求从主叫路由到被叫所经历的一系列代理服务器中，Record-Route是可以被替换或者改写的。

Contact：＜sip：+8618407404348＠[2409：8099：0：20：：1]：5062；zte-did=2-9-20481-567-12-662＞；audio；video；+g.3gpp.mid-ca11；

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

Via：SIP，Via里包含了期望响应消息发送的地址。Branch参数区分了该请求创建的交易。并且在客户端以及服务器端，除了Cance1以及Ack请求，Branch参数被唯一使用。Cance1消息里的Branch参数需要与被Cance1的请求里的Branch参数保持一致。Ack里的Branch参数应该与Invite里的Branch参数保持一致。

Supported：100re1，precondition，timer。这里可选项100re1的出现可以判定SIP message来自于MGCF，也意味着主叫电话来自于交换域Session-Expires：3600；refresher=uac Min-SE：90。

Session-Expires和Min-SE这两条报头往往需要结合一起来看，Min-SE决定了ses-sion在代理服务器或者UE之间最小的更新间隔，意味着代理服务器在处理request时不允许恶意将其修改更低，而Session-Expire则决定了更新的上限，在该值超时前如果没有收到周期的re-INVITE或者UPDATE消息，则会话认为结束。同时更新是由发起request的一方（uac）来启动；一般可以设置30 min（1800 s），这是由于认为95%的会话在30 h内就结束了，不过随着新技术的实施，将该值适当拉大也可以接受。

P-Asserted-Identity：＜te1：18407404348＞，该包头域应该与主叫UE发出的P-Pre-ferred-Identity捆绑起来解读。这里涉及了一个trust domain的概念，如果在信任域之间发送，代理服务器收到了P-Preferred-Identity，如果同在可信域之内，该值作为服务器可参考值，可在被插入后续的P-Asserted-Identity包头域中呈现P-Preferred-Identity值。As-serted Identity意味着该值已被证实，这个值对于接收端的UE来讲，意味着比From包头域的值更值得信任。Asserted的值出现是为了简化鉴权（防止恶意篡改，更改，重放主叫号码）来电号码而产生，这样在信任域内的不同SIP服务节点转发该值，无需再重新进行该值的修改。但是发送到信任域之外，需要将该值删除或者进行一些私有加密的处理。这两个包头域的取值设置可以是SIP、SIPs URI或者Te1格式，同时对于中间转发的服务器，最多可添加一个SIP或者SIPs URI和最多一个Te1 URI。

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

Accept-Contact：*；+g.3gpp.icsi-ref=＂urn%3Aurn-7%3A3gpp-service.ims.icsi.-mmte1＂；audio，该包头域是主叫端对被叫端UE所具备的能力偏好要求，在经过一系列的IMS网元后，服务器会参考该包头域所规定内容，依据偏好选择设置，对被叫端进行选择。

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

图5-38 UE反馈Offer Response消息

如图5-39所示，在UE向网络发出INVITE消息（IMS SIP INVITE）后，网络响应消息为183消息。

图5-39 SESSION PROGRESS 183阶段主要做的语音编解码协商

步骤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路由送达。(www.daowen.com)

步骤11：P-CSCF将响应确认发送被叫UE，如图5-40所示。

图5-40 P-CSCF将响应确认发送被叫UE

步骤12：UE对Response Confirmation进行应答（200 OK），如图5-41所示，如果可选的SDP信息被包含在Response Confirmation里，那应答中应该也包含SDP响应。如果SDP信息变化了，P-CSCF授权资源可以被使用。

图5-41 UE对Response Confirmation进行应答（200 OK）

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

步骤14～15：P-CSCF将确认应答消息通过S-CSCF转发到主叫节点。

步骤16～18：当主叫节点完成了资源预留，发送资源预留成功消息到S-CSCF，S-CSCF将该消息转发到被叫侧，如图5-42所示。

图5-42 主叫节点完成了资源预留，发送资源预留成功消息到S-CSCF

步骤19：被叫UE振铃。

步骤20～22：被叫UE反馈资源预留成功，如图5-43所示。

183阶段主要做的语音编解码协商，m=audio 50010 RTP／AVP 104105，可以看出被叫UE支持的是104、105编码格式，含意如下：

a=rtpmap：104 AMR-WB／16000／1

a=fmtp：104 mode-change-capabi1ity=2；max-red=0

a=rtpmap：105 te1ephone-event／16000／1

a=fmtp：1050-15，这里采用的是AMR宽带语音编码方式，采样率为16000Hz，同时te1ephone-event说明了一些支持DTMF信令的情况（双音多频，主要用于发送号码）。

步骤23～25：UE进行180持续振铃响应，如图5-44所示。

步骤26：当被叫UE接通电话，向P-CSCF发送200 OK的最终响应。

步骤27：P-CSCF启动为该会话预留的媒体流资源。

步骤28：被叫UE启动媒体流资源。

步骤29～30：P-CSCF转发200 OK最终响应，如图5-45所示。

图5-43 被叫UE反馈资源预留成功

图5-44 UE进行180持续振铃响应

图5-45 P-CSCF转发200 OK最终响应

其中，P-Access-Network-Info消息内容为3GPP-UTRAN-TDD，以及utran-ce11-id-3gpp=4600E38A7076903，说明主叫电话在TD-SCDMA上，但是现网TD-SCDMA并不与IMS互通，也不承载VoIP话音，同时检索主叫侧1og，发现主叫UE是在LTE网络上进行起呼的，至于为什么会导致这样，建议逐SIP节点进行定位确认。

步骤31～33：主叫侧对200 OK最终响应进行SIP ACK响应应答，该消息通过中间服务器转发到被叫侧，如图5-46所示。

图5-46 主叫侧对200 OK最终响应进行SIP ACK响应应答