VoLTE端到端业务详解 | SIP协议

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

---

4.3.1 基础知识

首先我们来对传统的7号信令的结构做个简单的概述，7号信令网结构见图4-81。

在1980年“黄皮书”建议中，7号信令系统主要考虑了完成通话传送与接续控制有关的信息要求，所以只提出4个功能级的要求。但后来在发展ISDN和智能网时，不仅需要传送与电路之间接续有关的消息，还需要传送与电路接续无关的消息，例如，用于维护管理、面向ISDN用户之间的端到端的信息等。原来的MTP功能明显不足，于是在1984年的“红皮书”中增加SCCP，即在不改变MTP的前提下，通过增加SCCP来增加MTP的功能，满足面向连接和无连接端到端信息传递的要求。随着ISDN、智能网以及其他一些业务的发展，仅增加SCCP仍显不足，于是在1988年的“蓝皮书”协议中又增加了事务处理能力（TC）及其应用部分（TCAP）等一些内容，目的是增强信息传送的能力。

MTP协议层一般承载在64kbit/s或2Mbit/s的TDM链路上，包含三级，即MTP-1（信令数据链路功能）、MTP-2（信令链路功能）和MTP-3（信令网功能）。

MTP-1：信令数据链路功能定义了信令数据链路的物理、电气和功能特性，确定与数据链路的连接方法。

MTP-2：信令数据功能规定了把消息信号传送到数据链路的功能和程序，它包括信号单元分界、信号单元的定位、差错检测、差错校正、初始定位和处理机故障处理。

MTP-3：信令网功能规定了关于信令网操作及管理的功能和过程，定义了信令点之间传递消息的功能和程序。

TUP：电话用户部分（TUP）协议功能为基本通话过程中电路交换网络连接的建立、管理和释放提供了骨干通信功能，以便提供远程电信服务。

ISUP：综合业务数字网用户部分协议功能能完成电话用户部分（TUP）和数据用户部分（DUP）的功能，是在TUP功能上发展而来的。

详细的TUP协议规范请参考ITU-T Q.723，ISUP协议规范请参考ITU-T Q.763。

TUP、ISUP协议具体的内容在本次叙述中不再进行详细的描述，因为随着通信网络的IP化，电话业务新的上层应用协议（BICC协议）已经代替TUP/ISUP，下面针对BICC协议将进行简单介绍，TUP/ISUP是类似的。

BICC协议栈结构见图4-82。

可以看到，BICC协议依然可以承载在传统的TDM链路上，但实际网络中大多数是基于SCTP/IP上的。

以一次通话的完整BICC消息流程为例，让大家对BICC协议有个感官的认识，学习任何一个协议都需要较长时间的积累，你才能真正明白协议为什么要这么规定，才能明白协议是怎么为实现业务而服务的。

下面是一次主叫用户听“被叫是空号”的呼叫全流程，如图4-83所示。

第一条信令是IAM消息，这个消息的作用是主叫用户方告知被叫用户方，本次业务是哪个主叫用户呼叫哪个被叫用户且标注为是语音业务还是视频业务，具体的结构见图4-84和图4-85。

第二、三、四条的APM信令是为了给主、被叫用户所在网络之间交互媒体面相关信息用的，比如第三条的APM信令消息中携带的主叫用户所在网络的媒体地址是10.40.*.，端口号是58048，如图4-86所示。

第四条的APM信令中携带的被叫用户所在网络的媒体地址是10.40.**.，端口号是39620，如图4-87所示。

第五条信令是被叫用户所在网络告知主叫用户，您拨打的被叫号码是未分配的（如图4-88所示），即主叫用户会听到“空号”的录音通知，空号音的录音通知是从媒体地址10.40..+端口号39620传送给媒体地址10.40.*.**+端口号58048的，这样我们大致知道了当拨打一个号码是空号时，在信令里是怎么一个流程了。

随着互联网业务的发展，Internet标准和协议在风格上遵循其一贯坚持的简练、开放、兼容和可扩展等原则，SIP协议借鉴了Internet标准和协议的设计思想，充分注意到Internet开放而复杂的网络环境下的安全问题，同时也充分考虑了对传统公共电话网的各种业务，包括IN业务和ISDN业务的支持，SIP协议是一个在IP网络上进行多媒体通信的应用层控制协议，它被用来创建、修改和终结一个或多个参加者的会话进程，这些会话包括Internet多媒体会议、Internet电话、远程教育以及远程医疗等。

SIP有别于我们传统通信网络的7号信令，下面将介绍本书最重要的角色—SIP。

4.3.2 典型应用

Soft X 3000通过SIP/SIP-T与其他软交换系统互通，以及与其他SIP域设备（如SIP Phone，SIP Softphone等）互通，SIP在NGN中的典型应用如图4-89所示。

4.3.3 基本流程

1.注册流程

用户每次开机时都需要向服务器注册，当SIP客户端的地址发生改变时也需要重新注册。注册信息必须定期刷新。

下面以SIP Phone向Soft X 3000注册的流程为例，说明SIP用户的注册流程，如图4-90所示。

在下面的实例中，我们有以下约定：

· Soft X 3000的IP地址为191.169.150.30；

· SIP Phone的IP地址为191.169.150.251；

· SIP Phone向Soft X 3000请求登记。

（1）事件1：SIP Phone向Soft X 3000发起注册请求，汇报其已经开机或重启动。下面是登记请求消息编码的示例。

第1行：请求起始行，登记请求消息，表示终端向IP地址为191.169.150.30的Soft X 3000发起登记。SIP版本号为2.0。

第2行：From字段，指明该登记请求消息是由Soft X 3000（IP地址：191.169.150.30）控制的SIP Phone发起的。

第3行：To字段，指明登记请求接收方的地址。此时，登记请求的接收方为IP地址为191.169.150.30的Soft X 3000。

第4行：Call-ID字段。该字段唯一标识一个特定的邀请，全局唯一。Call-ID为“1-reg@191.169.150.251”，191.169.150.251为发起登记请求的SIP Phone的IP地址，1-reg为本地标识。

第5行：Cseq字段，此时用于将登记请求和其触发的响应相关联。

第6行：Contact字段，在登记请求中的Contact字段指明用户可达位置，表示SIP Phone当前的IP地址为“191.169.150.251”，电话号码为“6540012”。

第7行：表示该登记生存期为100s。

第8行：表明此请求消息的消息体的长度为空，即此消息不带会话描述。

第9行：表示原因短语、会话描述或应答消息中携带的状态应答内容的首选语言为英语。

第10行：表示发送该消息的UA实体支持sip-cc、sip-cc-01以及timer扩展协议。timer表示终端支持session-timer扩展协议。

第11行：发起请求的用户终端的信息。此时为SIP Phone的型号和版本。

第12行：Via字段。该字段用于指示该请求历经的路径。“SIP/2.0/UDP”表示发送的协议，协议名为“SIP”，协议版本为2.0，传输层为UDP；“191.169.150.251”表示该请求消息发送方SIP终端IP地址为191.169.150.251。

（2）事件2：Soft X 3000返回401 Unauthorized（无权）响应，表明Soft X 3000端要求对用户进行认证，并且通过WWW-Authenticate字段携带Soft X 3000支持的认证方式Digest和Soft X 3000域名“test.com”，产生本次认证的Nonce，并且通过该响应消息将这些参数返回给终端从而发起对用户的认证过程。

（3）事件3：SIP Phone重新向Soft X 3000发起注册请求，携带Authorization字段，包括认证方式Digest、SIP Phone的用户标识（此时为电话号码）、Soft X 3000的域名、Nonce、URI和Response（SIP Phone收到401 Unauthorized响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的响应）字段。下面是登记请求消息编码的示例。

（4）事件4：Soft X 3000收到SIP Phone的注册请求，首先检查Nonce的正确性，如果和在401 Unauthorized响应中产生的Nonce相同，则通过；否则，直接返回失败。然后，Soft X 3000会根据Nonce、用户名、密码（服务器端可以根据本地用户信息获取用户的密码）、URI等采用和终端相同的算法生成响应消息，并且对此响应和请求消息中的响应进行比较，如果二者一致，则用户认证成功，否则认证失败。此时，Soft X 3000返回200 OK响应消息，表明终端认证成功。

2.呼叫流程

在同一Soft X 3000控制下的两个SIP用户之间的成功呼叫，呼叫流程应用实例如图4-91所示。

在下面的实例中，我们有以下约定：

· Soft X 3000的IP地址为191.169.200.61；

· SIP PhoneA的IP地址为191.169.150.101；

· SIP PhoneB的IP地址为191.169.150.100；

· SIP PhoneA为主叫，SIP PhoneB为被叫，主叫先挂机；

· SIP PhoneA的电话号码为1000，SIP PhoneB的电话号码为1001。

（1）事件1：SIP PhoneA发Invite请求到Soft X 3000，请求Soft X 3000邀请SIP PhoneB加入会话。SIP PhoneA还通过Invite消息的会话描述，将自身的IP地址：191.169.150.101、端口号：8766、静荷类型、静荷类型对应的编码等信息传送给Soft X 3000。

（2）事件2：Soft X 3000给SIP PhoneA回100 Trying表示已经接收到请求消息，正在对其进行处理。

（3）事件3：Soft X 3000给SIP PhoneA发407 Proxy Authentication Required响应，表明Soft X 3000端要求对用户进行认证，并且通过Proxy-Authenticate字段携带Soft X 3000支持的认证方式Digest和Soft X 3000域名“test.com”，产生本次认证的Nonce，并且通过该响应消息将这些参数返回给终端，从而发起对用户的认证过程。

（4）事件4：SIP PhoneA发送ACK消息给Soft X 3000，证实已经收到Soft X 3000对于Invite请求的最终响应。

（5）事件5：SIP PhoneA重新发送Invite请求到Soft X 3000，携带Proxy-Authorization字段，包括认证方式Digest、SIP Phone的用户标识（此时为电话号码）、Soft X 3000的域名、Nonce、URI和Response（SIP PhoneA收到407响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的响应）字段。

（6）事件6：Soft X 3000给SIP PhoneA回100 Trying表示已经接收到请求消息，正在对其进行处理。

（7）事件7：Soft X 3000向SIP PhoneB发送Invite消息，请求SIP PhoneB加入会话，并且通过该Invite请求消息携带SIP PhoneA的会话描述给SIP PhoneB。

（8）事件8：SIP PhoneB给Soft X 3000回100 Trying表示已经接收到请求消息，正在对其进行处理。

（9）事件9：SIP PhoneB振铃，并回180 Ringing响应通知Soft X 3000。

（10）事件10：Soft X 3000回180 Ringing响应给SIP PhoneA，SIP PhoneA听回铃音。

（11）事件11：SIP PhoneB给Soft X 3000回200 OK响应表示其发过来的Invite请求已经被成功接收、处理，并且通过该消息将自身的IP地址：191.169.150.101、端口号：8766、静荷类型、静荷类型对应的编码等信息传送给Soft X 3000。

（12）事件12：Soft X 3000给SIP PhoneA回200 OK响应表示其发过来的Invite请求已经被成功接收、处理，并且将SIP PhoneB的会话描述传送给SIP PhoneA。

（13）事件13：SIP PhoneA发送ACK消息给Soft X 3000，证实已经收到Soft X 3000对于Invite请求的最终响应。

（14）事件14：Soft X 3000发送ACK消息给SIP PhoneB，证实已经收到SIP PhoneB对于Invite请求的最终响应。

此时，主、被叫双方都知道了对方的会话描述，启动通话。

（15）事件15：SIP PhoneA挂机，发送BYE消息给Soft X 3000，请求结束本次会话。

（16）事件16：Soft X 3000给SIP PhoneA回487响应，表明请求终止。

（17）事件17：Soft X 3000收到SIP PhoneA发送来的BYE消息，知道A已挂机，为SIP PhoneB发送BYE请求，请求结束本次会话。

（18）事件18：SIP PhoneB挂机，给Soft X 3000反馈200 OK响应，表明已经成功结束会话。

4.3.4 关键特性

1.可靠性机制

（1）对于Invite/ACK请求、响应消息的可靠性机制

① 基于不可靠传送协议（如UDP）—请求消息的可靠性机制。

· 采用重发机制。

· 每次重发的间隔时间成指数增长，设其初始间隔时间为T1，则下一间隔时间为2×T1，依此类推……

· 当客户机收到中间响应、最终响应时，或当它总共重发了7次请求消息后，客户机停止重发请求消息。

② 基于不可靠传送协议（如UDP）—响应消息的可靠性机制。

· 采用重发机制。

· 若为中间响应，则在收到重发的请求消息后重发该响应；若为最终响应，则每次重发的间隔时间成指数增长，设其初始间隔时间为T1，则下一间隔时间为2×T1，依此类推……直至T2为止。

· 当服务器收到ACK请求时，或当它总共重发了7次响应消息后，服务器停止重发响应消息。

③ 基于可靠传送协议（如TCP）—请求消息的可靠性机制。

· 若客户机在规定的时间内未收到任何响应，则它放弃该请求消息。

④ 基于可靠传送协议（如TCP）—响应消息的可靠性机制。

· 采用重发机制。

· 若为中间响应，则在收到重发的请求消息后重发该响应；若为最终响应，则每次重发的间隔时间成指数增长，设其初始间隔时间为T1，则下一间隔时间为2×T1，依此类推……直至T2为止。

· 当服务器收到ACK请求时，或当它总共重发了7次响应消息后，服务器停止重发响应消息。

（2）对于其他请求、响应消息的可靠性机制

① 基于不可靠传送协议（如UDP）—请求消息的可靠性机制。

· 采用重发机制。

· 每次重发的间隔时间成指数增长，设其初始间隔时间为T1，则下一间隔时间为2×T1，依此类推……直至T2为止，此后重发请求消息的间隔时间均为T2，T1、T2的缺省值分别为500ms和4s。

· 客户机收到中间响应后，其重发请求消息的间隔时间为T2。

· 当客户机收到最终响应时，或当它总共重发了11次请求消息后，客户机停止重发请求消息。

② 基于不可靠传送协议（如UDP）—响应消息的可靠性机制。

· 采用重发机制。

· 服务器收到重发的请求消息后重发该响应。

· 当服务器发送最终响应后，由于它不能确定客户机是否收到了该响应，因而该响应消息至少应被保存10×T2 s。

③ 基于可靠传送协议（如TCP）。

· 若客户机在规定的时间内未收到任何响应，则它放弃该请求消息。

2.消息特性

SIP在VoLTE业务分析中是很关键的一环，虽然SIP是文本格式的，我们也能看明白其基本含义，但它在业务流程中真正起到什么作用，还需要结合实际应用案例来进一步理解。

由于VoLTE业务牵涉IMS、PS、CS、终端等多个域，一般来说都会建立一套信令监测系统来辅助网络优化和故障处理，然而信令监测系统是外置的分析平台，总会存在缺少信令数据的问题，那我们就需要借助于SIP的各个头域来判断是信令平台丢失了信令还是业务本身就没有信令的问题。

（1）Max-Forwards头域的作用

比如分析到下面这条BYE消息时，怎么来确认它是SBC主动发送的还是用户发给SBC再转发给S-CSCF的。我们需要借助于Max-Forwards这个头域来判断，Max-Forwards=69（如图4-92所示）表示经过SBC时已经是第二跳了，因此说明这个BYE消息是UE发送给SBC的。

图4-93的消息表明，当SBC收到RX口ASR消息的时候提早释放本次通话，接着向S-CSCF发送BYE消息以便IMS业务控制域释放本次呼叫，我们可以看到BYE消息中Max-Foxwards=70，即表明这个BYE消息是SBC主动发出来的，不是转发用户发过来的。

（2）Cseq头域的作用

如果需要判断图4-94所示流程中用户在发送BYE消息之前主叫UE有没发过修改媒体的Invite或Update消息给网络侧，我们就需要结合这个字段来辅助分析。

我们需要把主叫用户发送给被叫用户的请求消息的Cseq头域一条条地列出来，从顺序号可以看出，主叫用户发送BYE消息之前是没有发过其他请求消息给网络侧的，如图4-95所示。

当看到图4-96所示的一次业务流程的各个消息中的Cseq头域时，我们会发现主叫侧修改过一次媒体信息。

Cseq头域序列：

（3）Route头域的作用

① 当I-CSCF接收到初始请求（非注册请求）时，如Route域中存在本I-CSCF的地址，且其中包括“orig”参数，则I-CSCF应启动主叫用户的查询及S-CSCF的选择；否则，启动被叫用户的查询及S-CSCF的选择。

② 当始发请求由业务平台发起时，业务平台面临如何选择用户（主叫用户或被叫用户）所在网络的问题。业务平台通过预配或通过Sh接口查询，可得到为用户（主叫或被叫）服务的CSCF地址。

当业务平台首先选择为主叫用户服务（相对于该业务平台发起的当前呼叫）的网络时，业务平台发往主叫用户所在的CSCF消息中应带有Route域，且其中带有“orig”参数。该用户所在的S-CSCF根据该用户或PSI的数据配置完成主叫侧业务的触发，随后由该S-CSCF完成向被叫网络（B用户所处的网络）寻址的过程。

当业务平台首先选择为被叫用户服务（相对于业务平台发起的当前呼叫）的网络时，业务平台发往被叫用户所在的CSCF消息中带有Route域，但无“orig”参数。

（4）Session-Expires、Min-SE头域的作用

Session-Expires、Min-SE头域都以秒为单位。

在收到200 OK（Invite）后，若refresher=UAC，则启动刷新、超时两个定时器，时长分别是Session-Expires/2和Session-Expires。若refresher=UAS，则启动超时定时器。

Session Timer协商过程主要涉及以下几个重要参数。

① 在Supported头域中携带timer值，表示网元支持Session Timer机制。

② Session-Expires头域：此头域用于传送会话刷新的时间间隔以及进行刷新协商，可以包括在Invite、Update及其2XX应答中。头域中最小时间间隔为90s。

头域由两部分组成：refresher参数和刷新时长Session-Expire。

其中，refresher参数表示更新的执行者，包括UAC和UAS两种取值，发送请求方称为UAC，接收请求方称为UAS。

· Session-Expire头域参数表示刷新时长。

· 请求中的Session-Expire头域：刷新时长表示UAC建议的刷新时长，刷新方可以不携带此头域，如果携带则表示指定了刷新方。

· 响应中的Session-Expire头域：刷新时长表示协商后的刷新时长。

③ Min-SE头域：此头域用于指示最小的会话刷新间隔。此值最小为90s。除422应答外，其他的应答中严禁包括此头域。该头域在请求消息中携带，表示UAC支持的最小刷新时长。UAS返回的响应中的实际刷新时长不能小于该头域值。