VoLTE的详细流程

开飞机的海森堡

UE连接到IMS网络（获取P-CSCF的IP地址）

两种方式：

• 通过DHCP：当UE成功附着到LTE网络后，可通过发送DHCP请求获取P-CSCF的IP地址，若响应是P-CSCF的域名，UE需要通过DNS获取其IP地址。（移动和固定终端均支撑）
• 通过附着过程：UE可以通过Attach请求或PDN连接请求中的PCO（Protocol Configuration Option，协议配置选项）这个IE来要求LTE核心网提供P-CSCF的IP地址。（仅移动终端支撑）
  

以b为例：
       UE首先发送Attach Request和PDN Connectivity Request（PDN连接请求消息通常与Attach请求消息一起发送）消息要求建立与IMS网络的默认承载，消息中的APN配置为IMS网络专用值——ims；同时，UE还通过消息中的SM-Container IE(P-CSCF IPv4 Address Request)来请求获取P-CSCF的IP地址。EPC在完成了鉴权和安全模式过程后，在Activate default EPS bearer context request消息中，通过SM-Container IE回复P-CSCF的IP地址，同时还会为UE分配一个IMS客户端的IP地址，专门用于其与IMS网络的通信。
PDN Connectivity Request:


Activate default EPS bearer context Request:

• UE建立与IMS网络的承载（包括信令承载和数据承载）
  
  • 信令承载
    
  
  

当UE获得P-CSCF的IP地址后，紧接着就可以发起新的PDN连接请求来要求LTE网络为其建立专门用于传输IMS SIP信令消息的默认EPS承载，为UE后续的IMS用户注册流程做准备。注：此处若UE是通过上述1中方法b来获取P-CSCF的IP地址，则在获取到IP地址后UE就与网络建立起了IMS信令承载，即默认EPS承载。此默认承载为Non-GBR（QCI=5），即不携带具体的QoS要求，只提供允许的上下行最大传输比特率，不给出确保的上下行速率。[backcolor=rgba(255, 246, 122, 0.8)]（信令传输与数据业务传输的区别）

默认EPS承载是静态建立的，即该承载在IMS用户的整个注册有效期内都是一直保持激活的状态，以便UE随时发起IMS会话流程，直到UE关机或IMS注册失效或用户取消注册才会去激活并释放相关资源。

SIP信令消息包必须经过各个CSCF节点来进行处理或转发，不能在两个UE之间经过P-GW直接进行传输。[backcolor=rgba(255, 246, 122, 0.8)]（信令传输与数据业务传输的区别）

• 数据承载
  

由于默认EPS承载是IMS信令承载，无法承载用户的语音数据包，因此还需要建立另一个专用EPS承载来专门负责。此专用承载基于GBR（QCI=1或2），会包含详细的QoS要求，如最大上下行速率和确保的上下行速率等。PS：若用户发起了视频通话流程，则还需要建立第三个专用的EPS承载来负责传输用户的视频流数据包。

另外，数据承载的建立也不需要UE再提供APN参数值，网络侧也不需要再单独给UE分配IP地址，[backcolor=rgba(255, 246, 122, 0.8)]共用信令承载的IP地址即可。

数据承载[backcolor=rgba(255, 246, 122, 0.8)]仅在用户的[backcolor=rgba(255, 246, 122, 0.8)]IMS[backcolor=rgba(255, 246, 122, 0.8)]会话过程中才会保持激活状态，一旦会话结束就会去激活并释放相关无线资源DRB。

数据流包不需要经过各个CSCF结点进行转发，直接通过两个UE之间的[backcolor=rgba(255, 246, 122, 0.8)]P-GW来进行传输，减少用户平面时延。（走UDP也是减少时延的一个做法）

注：与一般的会话过程不同，紧急通话功能下IMS信令消息和用户语音数据是共用一个默认承载的，由于QCI类型为Non-GBR，那么在此种情况下用户语音数据包的传输质量很差。

• IMS注册
  
  • IMS鉴权
    
  
  

与UE在LTE网络中的鉴权过程类似，IMS网络中的鉴权过程同样在用户的初始注册过程中完成，且同样是双向认证过程。不过，IMS网络侧可以随时发起重新鉴权过程（LTE网络侧并不会这样做），比如用户的上次注册有效期到期后、用户发起重新注册以及用户先IMS网络增加或删除其共有用户标识时。另外，IMS还支撑多种鉴权方式以满足不同类型用户以及不同接入方式的要求。

IMS可选的鉴权算法：

• AKA（Authentication and Key Agreement，认证和密钥协商算法）
  

LTE网络使用的鉴权算法，是一种对称算法。



[backcolor=rgba(255, 246, 122, 0.8)]其算法原理是：HSS发送一组鉴权项链AV（Authentication Vectors，包括RAND、AUTN、XRES和KASME），MME随机选取一个AV并将其中的XRES和KASME保存在本地，再为KASME生成一个密钥索引KSIASME，最后同RAND和AUTN一起发送给UE；UE利用其USIM卡中的根密钥K以及其他鉴权信息计算出AUTN和RES，通过比对MME发送的AUTN是否与自身计算出的相同达到对MME身份合法性认证的目的；MME接受到包含RES的鉴权响应后，通过比对XRES和RES是否相同达到对UE身份合法性认证的目的。上述步骤即双向身份认证的鉴权过程。在此过程中，基于K可以生成KASME、完整性保护密钥IK以及加密密钥CK，基于这两个密钥可以在后续的安全模式建立过程中生成针对信令和用户数据的加密和完整性保护密钥，以实现对用户信令和业务数据的完整性和私密性这两重保障。

[backcolor=rgba(255, 246, 122, 0.8)]此鉴权算法仅适用于有USIM卡的终端用户

• 摘要算法（Digest with TLS/ without TLS）
  

基于用户名和密码方式的鉴权算法，且仅能实现网络侧对终端的单向认证。[backcolor=rgba(255, 246, 122, 0.8)]其算法原理为：终端将用户名（username）、密码（password）、网络侧发回的401鉴权挑战响应消息中的挑战值（nonce）、SIP/HTTP方法（method）以及所请求SIP URI值经过哈希算法（HASH或Digest摘要算法，参考协议RFC2617）生成一个统一的鉴权响应值（response），再将此值发给网络侧进行比较；在网络侧也会使用此用户的username、保存的密码以及本地的对应参数经过同一个算法计算生成一个结果，将该结果与终端发来的response值进行比较，若相同则鉴权成功。由于发送的是一个HASH值，避免了用户密码信息泄露或被拦截而带来的安全风险。

[backcolor=rgba(255, 246, 122, 0.8)]此鉴权算法仅适用于没有USIM卡的固定终端用户

• GIBA（GPRS-IMS Bundled authentication，GPRS-IMS绑定算法）
  

GPRS-IMS绑定鉴权实际上就是IMS鉴权复用或信任用户附着到LTE网络的鉴权结果，即不需要在默认的LTE网络注册流程结束后再进行一次额外的IMS鉴权过程，因此也被称为早期IMS鉴权。此算法通过检查核对用户在附着过程中被分配的IP地址来完成，该IP地址必须被要求保存在HSS中以便此处IMS网络进行核对。

UE可以选择上述任意一种支撑的鉴权算法，通过初始注册请求消息（第一次Attach Request）中填写的头信息域值告诉网络侧其选择的鉴权类型。当IMS网络接收到UE发出的初始注册请求消息后，会回复401鉴权挑战响应消息，此消息中包含了网络侧计算好的相关鉴权参数（nonce）和选定的鉴权算法，进而触发后续鉴权认证过程。

[backcolor=rgba(255, 246, 122, 0.8)]此鉴权算法仅适用于有USIM卡的终端用户

• IMS注册
  

注册前，UE必须通过P-CSCF发现流程获得P-CSCF的IP地址，并且IMS默认EPS承载已经建立成功。另外，UE还需要通过Attach请求消息中的voice_domain_pref这个IE来告诉IMS网络自己支撑何种语音业务功能。

IMS注册的目的是将用户的私有标识（IMPI）和用户想要注册的公有标识（IMPU）进行绑定。每个用户只有一个IMPI，但可以有多个IMPU，每个IMPU对应有相应的服务配置。[backcolor=rgba(255, 246, 122, 0.8)]（即用户想要获得什么样的服务就绑定相应的IMPU）

• IMPI属于网络层，[backcolor=rgba(255, 246, 122, 0.8)]是由归属网络分配给[backcolor=rgba(255, 246, 122, 0.8)]IMS[backcolor=rgba(255, 246, 122, 0.8)]用户的身份标识（由S-CSCF发送的401鉴权挑战响应消息携带），用于管理、注册、授权、计费，[backcolor=rgba(255, 246, 122, 0.8)]具有全球唯一性。类似于移动网络中的IMSI号码或固定网络中的物理号码。准确的说，IMPI标识的是用户和网络的签约，而不是用户。使用IMPI，网络可以通过鉴权来识别用户是否可以使用网络；
• IMPU更靠近业务层，用于标识业务签约关系，计费等，还表示用户身份以及用于路由，但它不能表示用户实际的位置信息（仅针对非传统固话）。
• 对于USIM卡，需要通过IMSI来推导出自己的IMPI和IMPU（默认），如下定义：
  

IMPI: IMSI@ims.mnc[MNC].mcc[MCC].3gppnetwork.org

IMPU: sip:IMSI@ims.mnc[MNC].mcc[MCC].3gppnetwork.org

[backcolor=rgba(255, 246, 122, 0.8)]PS[backcolor=rgba(255, 246, 122, 0.8)]：这两个用户标识可以理解为LTE网络中的IMSI和TMSI，即IMPI唯一标识有一个用户，用户使用其去在IMS网络中进行初始注册；注册完成后，IMPU作为一种“临时标识”负责用户和网络的通信。



IMS注册通常有三种类型：初始注册、重新注册（又称再注册或注册刷新）、取消注册（又称去注册）

b.1    初始注册



上述流程涉及的IMS网络实体有：

• 代理会话管理控制与路由功能实体（Proxy-CSCF，P-CSCF）
• 查询CSCF（Interrogating-CSCF，I-CSCF）：用户连接到归属IMS网络的第一个接口点，主要功能包括分配S-CSCF、路由功能、查询SLF实体地址解析功能来获取某个HSS的地址（IMS网络部署了多个HSS时）、通过查询HSS完成被叫用户S-CSCF的查找和定位、隐藏IMS网络的具体构成和特性。
• 服务CSCF（Serving-CSCF，S-CSCF）：IMS网络中的核心实体单元，IMS网络中会部署多个能力相同或不同的S-CSCF。主要功能包括[backcolor=rgba(255, 246, 122, 0.8)]IMS用户注册的处理、从HSS下载保存注册用户的业务订阅信息、IMS用户注册信息的清除、[backcolor=rgba(255, 246, 122, 0.8)]IMS用户的鉴权认证过程、[backcolor=rgba(255, 246, 122, 0.8)]IMS用户主叫或被叫会话处理、将被叫用户的MSISDN（电话号码，也称TEL URI）转换成SIP URI格式、根据用户业务过滤规则决定是否事先联系AS对会话请求进行呼叫转移等附加处理。
• 应用服务器（Application Server，AS）：[backcolor=rgba(255, 246, 122, 0.8)]提供多种多样的增值多媒体服务，如在线状态服务、会议电话以及紧急呼叫等。S-CSCF根据从HSS下载保存的业务或应用过滤规则将会话转移到相对应的AS，再有AS进行处理。AS也可以主动发起SIP会话请求，比如邀请某个用户加入会议电话或者向计费单元发送账目信息等。紧急呼叫、会议电话以及补充业务配置这类服务都属于AS的责任范围。
  

[backcolor=rgba(255, 246, 122, 0.8)]具体流程如下：

（1）UE->P-CSCF    SIP Register

注册请求消息头域中只允许出现用户的私有标识IMPI。

（2）P-CSCF<->DNS   DNS Query

通过SIP注册请求URI中的用户归属网络域名来查询DNS获得用户归属网络的SIP代理入口，即 I-CSCF 的 IP 地址，并将该注册请求转发给I-CCSCF。

（3）P-CSCF->I-CSCF   SIP Register

如果该运营商网络部署了多个HSS，则I-CSCF还需要先通过SLF（签约位置功能，与HSS同为IMS网络中的数据库）实体单元查询获得某个服务HSS的地址信息。

（4）I-CSCF<->HSS    UAR/UAA命令对

I-CSCF查询该HSS来获得不同的S-CSCF的服务能力和IP地址信息，再根据负载均衡原则选择一个合适的S-CSCF。这里向HSS进行查询的过程采用DIAMETER协议的UAR/UAA命令对来完成。

（5）I-CSCF->S-CSCF   SIP Register

从查询结果中选定一个S-CSCF，并转发SIP注册请求消息。

（6）S-CSCF<->HSS    MAR/MAA命令对

向HSS要求[backcolor=rgba(255, 246, 122, 0.8)]计算并下载该用户的相关鉴权参数和使用的鉴权算法。

（7）S-CSCF->I-CSCF->P-CSCF->UE    401鉴权挑战响应

其中对于鉴权向量的处理类似LTE网络鉴权过程，参考AKA算法中的描述。

（8）UE->P-CSCF->I-CSCF->S-CSCF   SIP Register

UE完成了对S-CSCF身份合法性的验证后，随即发起第二次注册请求，不同于第一次注册消息，此消息中包含UE根据指定鉴权算法和相关鉴权参数计算得出的鉴权响应值（response），S-CSCF通过验证此值完成对UE身份合法性的认证。若双向认证过程中任一方向验证失败了，此次IMS注册过程也将马上中止。

（9）S-CSCF<->HSS   SAR/SAA命令对

鉴权通过后，S-CSCF采用DIAMETER协议SAR/SAA命令对向HSS要求并[backcolor=rgba(255, 246, 122, 0.8)]下载保存该用户的相关业务订阅信息和授权信息，包括默认的公有用户标识IMPU。[backcolor=rgba(255, 246, 122, 0.8)]此步骤即确定了用户IMPI和IMPU的绑定。

（10）S-CSCF->I-CSCF->P-CSCF->UE   200OK

S-CSCF向UE发送200OK注册响应消息，告知鉴权通过，允许注册。

（11）UE->P-CSCF->I-CSCF->S-CSCF    SUBSCRIBE

UE向S-CSCF发送注册事件订阅请求消息。

（12）S-CSCF->I-CSCF->P-CSCF->UE   200OK

（13）S-CSCF->AS   Register

S-CSCF还会向AS注册用户的相关信息。

（14）AS->S-CSCF   200OK

[backcolor=rgba(255, 246, 122, 0.8)]注：
注册过程中，HSS还会判断是否允许该用户漫游；
注册完成后，UE和P-CSCF之间就建立了一个加密的IP安全传输通道，保障了后续通信过程的安全性。（这个通道的建立是可选的）；
注册完成后，P-CSCF、I-CSCF以及HSS均会保存该用户对应的S-CSCF信息（包括其IP地址），以便后续会话业务的快捷处理。
b.2    重新注册

在初始注册成功后，UE会收到一个重要的超时值（Expires），代表该次注册的有效期，单位为秒s。



上图展示了一条注册响应消息的内部结构，可以看到其中Expires=7200，即代表本次注册有效期为7200s=2h。

在每次注册有效期期满前，UE都必须重新发起注册流程以维持他的公共用户标识IMPU的有效性，否则S-CSCF将删除用户的注册信息，即用户将不能继续接受IMS网络提供的各项业务了。重新发起的注册流程与初始注册流程一致。

虽然有效期Expires可以在UE和P-CSCF之间可以经过双方协商来得到，比如UE会在其发送的注册请求消息SIP Register中写入自己希望的有效期值，但是最终Expires的值仍以最终S-CSCF回复的注册响应消息200OK

前文提过IMS网络可以随时对UE发起鉴权，这种机制就是通过缩短Expires来实现的。具体实施方式是：S-CSCF通过发送SIP通知消息Notify来告知Expires的改变，对于此消息中包含的修改后的Expires，UE必须马上保存并立即启用。这样一来，Expires一旦到期，UE将马上发起重新注册，由于IMS网络中的注册流程与鉴权过程是严格耦合的，也即实现了IMS网络随时发起鉴权的功能。当然，网络侧也可以通过Notify消息来延长注册的有效期。

b.3    取消注册

当用户关机或不希翼被打扰时，UE会触发取消注册过程。具体实施方式是，UE再发送一次SIP Register消息给S-CSCF，只是这条消息中Expires被设为0，这即表示UE想要告诉S-CSCF我想要取消本次注册，那么S-CSCF也将删除该用户的相关临时注册信息（包括所有IMPU），然后回复一条SIP 200OK消息告知UE取消注册成功。另外，200OK消息的Date头域中还可以告知UE本次注册取消的具体日期时间。紧接着，S-CSCF还会通过一条Notify消息给P-CSCF来取消登记本次注册状态事件（Unregistered Event）。

当然，网络侧也能主动发起取消注册流程，如用户报告手机丢失或用户欠费或网络侧有设备需要紧急维护等事件发生时，具体实施方式是，S-CSCF发送一条Notify消息给P-CSCF和UE告知本次注册状态事件由于某种原因被取消登记了（Event:unregistered）。



b.4 紧急注册

在发起IMS/VoLTE紧急呼叫之前，UE必须先完成紧急呼叫业务IMS注册流程。

首先，UE必须知道LTE/IMS网络是否支撑IMS紧急呼叫业务；其次，UE侧也必须配置好相关参数并已激活支撑IMS紧急呼叫会话业务功能。

[backcolor=rgba(255, 246, 122, 0.8)]具体流程如下：

（1）附着接受Attach Accept消息中的IE EMC_BS：


（2）SIB1中的系统信息单元：“ims-EmergencySupport-r9 true”
（3）SIB2中的系统信息单元：“ac-BarringForEmergency-FALSE”
若以上两个参数中有一个值为假/0，UE均认为网络不完全支撑IMS紧急呼叫会话业务，此时若用户仍然拨打紧急呼叫号码（如110），这个紧急呼叫会话业务就会被网络侧重定向到传统2/3G电路域网络，即CSFB。

另外，一旦紧急呼叫注册成功，用户和IMS网络侧均不能主动发起取消注册流程，必须等到本次注册的有效期超时后自动取消。

• IMS会话
  

用户在IMS网络注册成功后，在注册有效期之内，用户可随时发起主叫或接收被叫IMS/VoLTE会话过程，包括视频和语音会话过程以及紧急呼叫业务会话过程。

另外，在VoLTE通话过程中，也是可以激活DRX（Discontinuous Reception，不连续接收）功能来减少终端电池的消耗，因为语音分组每隔20ms从上层来一次，而LTE的TTI很小，为1ms。

IMS会话分为不带预置条件和带预置条件的会话流程：

预置条件即专用LTE无线承载资源，前文先容的IMS数据承载的成功建立过程也称资源预留过程，此专用承载是在会话过程中动态建立专门用于传输用户语音数据包的（也就是前面数据承载那块说的建立会话前建立的一条专用DRB）。

• 不带预置条件会话流程
  

不带预置（Pre-condition）条件就是说在SIP会话振铃消息（180 Ringing）发送之前不能确保该LTE专用承载是否建立成功，因此[backcolor=rgba(255, 246, 122, 0.8)]IMS[backcolor=rgba(255, 246, 122, 0.8)]会话可能会失败。虽然可能会失败，但后续会话流程还是照常进行，比如紧接着的媒体协商过程（UE和IMS网络[backcolor=rgba(255, 246, 122, 0.8)]（此处应该是主叫和被叫双方进行协商）之间商定出双方都认可和支撑的用户数据流编码格式，包括语音视频流编码速率和算法等，通过[backcolor=rgba(255, 246, 122, 0.8)]SDP协议来完成）。

因此，不带预置条件的IMS会话流程即只有媒体协商过程，没有资源预留过程，其会话流程步骤为：

（1）MO UE_A->P-CSCF    INVITE

MO UE_A构建INVITE消息，该消息还包含消息体部分，即SDP Offer来描述MO UE所支撑或希望的用于本次会话的媒体格式，并将该INVITE消息发送给它的P-CSCF。

（2）P-CSCF->S-CSCF    INVITE

P-CSCF收到UE_A发送的INVITE消息后，会对该消息路由部分做出更新并直接将该消息转发给相应的S-CSCF，这是因为在IMS用户注册完成后，P-CSCF就已经知道并保存了该UE所对应的S-CSCF信息，包括IP地址等。

（3）S-CSCF->I-CSCF(MT)     INVITE

MO UE_A的S-CSCF收到INVITE消息后，首先根据业务初始过滤规则对具体的INVITE请求进行评估分析和相应处理，如判断该用户当前是否被禁止呼出业务（barred），是否需要将INVITE消息转发给AS做进一步处理。S-CSCF提取被叫用户SIP URI中的域名向DNS查询该MT UE_B的归属网络I-CSCF的IP地址。若INVITE消息中包含的是MT用户的电话号码（即TEL URI）而不是SIP URI，则主叫S-CSCF就会先进行E.164地址转换（具体参考RFC2916协议）来获得MT用户的归属域名，然后再通过DNS查询I-CSCF的IP地址。当MO用户S-CSCF获得MT用户的I-CSCF的IP地址后，就可以将该INVITE消息转发给该I-CSCF。

（4）I-CSCF<->HSS     LIR/LIA命令对

MT UE_B的I-CSCF收到该INVITE消息后，首先向HSS查询MT用户的S-CSCF的IP地址，该查询过程是通过DIAMETER协议中的LIR/LIA（Location Information Request位置信息请求/Location Information Answer位置信息回复）命令对来完成的。

（5）I-CSCF->S-CSCF->P-CSCF    INVITE (IMS Register User)

[backcolor=rgba(255, 246, 122, 0.8)]若HSS查询到该[backcolor=rgba(255, 246, 122, 0.8)]MT[backcolor=rgba(255, 246, 122, 0.8)] UE_B是[backcolor=rgba(255, 246, 122, 0.8)]IMS[backcolor=rgba(255, 246, 122, 0.8)]注册用户，则HSS会通知I-CSCF该用户的S-CSCF的IP地址，然后I-CSCF转发INVITE消息给该S-CSCF，S-CSCF再转发给MT用户对应的P-CSCF（MT用户在注册完成后，S-CSCF就知道并保存了该用户对应的P-CSCF的相关信息，包括IP地址）；

HSS->I-CSCF(MT)->S-CSCF(MO)->BGCF/MGCF     INVITE(Not IMS Register User)

[backcolor=rgba(255, 246, 122, 0.8)]若HSS查询不到该[backcolor=rgba(255, 246, 122, 0.8)]MT[backcolor=rgba(255, 246, 122, 0.8)]用户的[backcolor=rgba(255, 246, 122, 0.8)]IMS[backcolor=rgba(255, 246, 122, 0.8)]注册信息，则会通知I-CSCF，I-CSCF就会通知MO用户的S-CSCF，S-CSCF将该INVITE消息转发给网关互通功能实体单元BGCF/MGCF来进行相应处理，BGCF/MGCF会通过SGW/MGW分别完成SIP信令和语音媒体格式编码格式的转换，并进一步与2G/3G CS域-MSC或固网-PSTN通信，以完成该主叫IMS用户与非IMS注册用户（2G/3G CS 移动用户或4G CSFB移动用户或PSTN固网用户）的后续语音呼叫信令流程。

（6）P-CSCF(MT)->MT UE_B    INVITE

MT用户的P-CSCF将该INVITE消息转发给UE_B。所有的CSCF（MT用户的I-CSCF除外，[backcolor=rgba(255, 246, 122, 0.8)]这是因为MT用户的S-CSCF已经知道并保存了MO用户的P-CSCF的[backcolor=rgba(255, 246, 122, 0.8)]IP[backcolor=rgba(255, 246, 122, 0.8)]地址，后续MT UE和MO UE之间的通信也就无需再经过I-CSCF了）在转发INVITE消息时，都会先把消息Via头域中的IP地址换成自己的IP地址再转发，这是为了让被叫UE发送SIP状态响应消息以相同的路由返回给主叫UE。

（7）MT UE_B->P-CSCF(MT)->S-CSCF(MT)->S-CSCF(MO)->P-CSCF->MO UE_A     SIP 180 Ringing

MT UE_B发出振铃音来提醒被叫用户，同时发送SIP 180 Ringing消息给MO UE_A。注：此时主被叫双方的专用IMS语音数据承载可能还未建立成功，因此即使发送了180 Ringing消息，也可能导致会话失败。

（8）MT UE_B->P-CSCF(MT)->S-CSCF(MT)->S-CSCF(MO)->P-CSCF->MO UE_A     SIP 200 OK

MT UE_B根据自己的能力从MO UE_A发送的INVITE消息中的SDP Offer中选择一个它支撑的媒体格式并将其包含在自己的200OK状态响应消息中（SDP Answer）并转发给MO UE_A。注：若MT UE_B选择多个而不是一个媒体格式，就由MO UE_A来最终选定一个双方都支撑的媒体格式；若MT UE_B不支撑某个媒体类型，它就会在SDP Answer中该媒体类型所对应的行（如媒体类型为video，对应行数为m行）中设置端口号为0，以此来告诉MO UE_A，而不能直接删除该行。

（9）MO UE_A->P-CSCF(MO)->S-CSCF(MO)->S-CSCF(MT)->P-CSCF(MO)->MT UE_B    ACK

MO UE_A收到200OK后，同样会发送ACK消息给MT UE_B，来告诉MT用户，我已经收到了你发来的200 OK消息。只有发送了ACK之后，MO才开始发送语音数据媒体流，被叫方才开始接收媒体流。即，被叫方至少收到一个ACK后，这次呼叫才算是真正地建立起来了。

为了最大可能地让这个ACK被收到，MT只要没有收到ACK，就重复发送200 OK，直到收到ACK为止，而MO只要收到200 OK就认为被叫方没收到ACK，必须进行确认，然后就发送一个ACK确认这个200 OK。

（10）MO UE_A<->MT UE_B    RTP

MO UE_A和MT UE_B分别通过自己的P-GW建立直接的RTP连接来传输用户语音数据包，这些RTP数据包不需要像SIP信令一样通过各自的S-CSCF和P-CSCF进行转发，有效降低了用户平面的时延。[backcolor=rgba(255, 246, 122, 0.8)]与LTE网络类似，[backcolor=rgba(255, 246, 122, 0.8)]IMS[backcolor=rgba(255, 246, 122, 0.8)]网络同样遵循控制和承载分离的软交换思路。

注：会话的任何一方都可以随时结束会话，但在某些特定情况如实时计费功能实体发现该预付费用户账户中的钱用完或者某一方UE的无线承载丢失时，IMS网络都可以主动结束会话。不带预置条件的会话流程下，可能会丢失MT发送的180 Ringing消息，这种情况会导致MO侧（书中此处写的是MT侧，但是180 Ringing消息是在MT侧振铃后发出的，接收到这条消息的MO侧才会振铃

）没有振铃声，但是可以正常接通的异常情况。

• 带预置条件会话流程（更常见）
  

建立专门传输用户语音数据的EPS承载的过程称为资源预留，也称预置条件。对于主被叫UE而言，建立专用LTE无线承载的实行过程是相互独立的，所需时间也是不确定的，甚至很长，还可能会建立失败，这意味着在资源被成功预留之前，根本无法保证所协商的媒体会话是否可以建立起来。因此，[backcolor=rgba(255, 246, 122, 0.8)]预置条件的作用主要是保证在确认主被叫双方的资源预留都已成功之前，被叫方不应该振铃，以最大限度减少被叫方振铃但接听电话又失败的情况。即：相比不带预置条件的会话，主被叫双方的呼叫正式建立之前（MT振铃前），必须确保双方的资源成功预留（专用EPS承载成功建立）。

因为需要两次媒体资源协商过程，所以会话建立时间会延长。另外，需要主被叫UE都支撑并激活Pre-condition功能，这样两次媒体协商和资源预留工程才能完成。

（1）带预置条件流程与不带预置条件流程的区别

两种流程都用到了SDP offer/answer的媒体资源协商机制，但是不同的是带预置条件的流程在通话前协商了两次，分别是INVITE->183 Session Progress和Update->200 OK（此过程在协商的同时还能预留网络资源），而不带预置条件的流程则只协商了一次（INVITE->200 OK）。

（2）预置条件中的相关SDP参数

• 当前状态：current-status="a=curr: "。
• 希望状态：desired-status="a=des: "。
• 确认状态：confirm-status="a=conf: "。
• 预置条件处理类型：precondition-type="qos|token"。
• 强度标志：strength-tag=("mandatory"|"optional"|"none"|"failure"|"unknown")。
• 状态类型：status-type=("e2e"|"local"|"remote")。
• 方向标志：direction-tag=("none"|"send"|"recv"|"sendrecv")。
  

方向标志表示特定属性可以使用的方向，是SDP媒体流属性描述中的方向表述，包括发送"send"和接收"recv"。

在请求消息中，"send"表示请求方（Offer）发到应答方（Answer），在响应消息中则相反；另外，"e2e"（End to end）表示端到端通信，两个终端之间无中间服务器，"local"和"remote"分别表示Offer和Answer的接入网络[backcolor=rgba(255, 246, 122, 0.8)]（[backcolor=rgba(255, 246, 122, 0.8)]注：[backcolor=rgba(255, 246, 122, 0.8)]一次会话中，MO侧即为Offer请求方，[backcolor=rgba(255, 246, 122, 0.8)]MT[backcolor=rgba(255, 246, 122, 0.8)]侧就为Answer应答方，这也就确认了后续[backcolor=rgba(255, 246, 122, 0.8)]SIP[backcolor=rgba(255, 246, 122, 0.8)]消息中的本地和远端，而不是看这条消息是哪一方发的就认定哪一方为本地，注意区分）。

（3）precondition的相关流程

• INVITE
  

MO->MT

MO发送INVITE消息中的SDP：

• a=curr:qos local none
  

本地qos资源当前还未预留（none）

• a=curr:qos remote none
  

远端qos资源现在也没预留

• a=des:qos mandatory local sendrecv
  

本地预期的qos资源是双向的资源预留（sendrecv），且[backcolor=rgba(255, 246, 122, 0.8)]强度是必需的（mandatory）

• a=des:qos optional remote sendrecv
  

远端预期的qos资源是双向的资源预留，但强度是可选的（optional），因为此时MO并不知道MT是否也需要资源预留，所以此处一般设置为optional或none（若MT为2G/3G CS用户就不需要，若为VoLTE用户则需要资源预留）

• a=inactive
  

本地资源预留完成之前，MO（本地）不能收发语音数据媒体流

• 183 Session Progress
  

MT->MO

MT回复183消息，指示MT侧资源预留和预期：

• a=curr:qos local none
• a=curr:qos remote none
• a=des:qos mandatory local sendrecv
• a=des:qos mandatory remote sendrecv
  

此处相比INVITE中已被修改为mandatory，即表明MT也必须要资源预留。

• a=conf:qos remote sendrecv
  

增加了conf行要求对方达到确认行中条件时发送确认消息（Confirmation）给自己

• a=inactive
  

远端（MT）在资源预留完成之前，MT也不能收发语音数据流。

• Update
  

MO->MT

当MO终端满足媒体协商条件以及专用EPS承载建立成功后[backcolor=rgba(255, 246, 122, 0.8)]（[backcolor=rgba(255, 246, 122, 0.8)]MT[backcolor=rgba(255, 246, 122, 0.8)]回复200 OK后），发送Update：

• a=curr:qos local sendrecv
  

本地（MO）已完成双向资源预留

• a=curr:qos remote none
• a=des:qos mandatory local sendrecv
• a=des:qos mandatory remote sendrecv
• a=sendrecv
  

由none变为sendrecv，表明MO已经准备好可以收发语音媒体数据流

• 200 OK
  

MT->MO

当MT终端也完成资源预留时[backcolor=rgba(255, 246, 122, 0.8)]（MO发送Update后），发送200 OK：

• a=curr:qos local sendrecv
• a=curr:qos remote sendrecv
  

远端（MT）已完成双向资源预留，同时发送振铃音通知被叫用户，并发送180 Ringing消息通知MO UE

• a=des:qos mandatory local sendrecv
• a=des:qos mandatory remote sendrecv
• a=sendrecv
  

由none变为sendrecv，表明MT已经准备好可以收发语音媒体数据流

至此，MO和MT两侧UE的预置条件被实现，即双方资源均预留成功，且资源预留的结果也与双方的希望值一致。这意味着，主被叫双方带QoS要求的EPS承载（数据承载）建立成功，可以双向收发语音媒体数据流了。

（4）Precondition的构造规则

• 生成一个offer
  

对于分段状态类型，必须生成两个当前状态行：一个"local"一个"remote"；

对于每个分段：UE必须添加一个或两个希望状态行；

对于某个特定的分段：事务状态表中两个方向的标志相同，UE必须添加一个带"sendrecv"标志的希望状态行，若不同，则必须生成两个希望行，一个"send"一个"recv"。

• 生成一个answer
  

对于希望强度："none"<"optional"<"mandatory"，某个应当方[backcolor=rgba(255, 246, 122, 0.8)]可以提升级别，但是不能降低接收到的级别。

（5）Precondition异常处理

• 预置条件不满足
  

当Answer的UE不能或不想满足Offer中的预置条件时，应发送580响应消息来拒绝请求：Server-Error=580 Precondition Failure

• 拒绝一个媒体流
  

前文提及过，当Answer方想拒绝或不支撑某个媒体流时，它只能把相应的端口设置为0，而不能删除对应行。

• 未知的预置条件类型
  

若MT侧在Offer中收到一个强度标志为"mandatory"的预置条件，但是又不能识别它时，此时UE必须在SDP消息体中拒绝此Offer，把"failure"改为"unknown"：

m=audio 20000 RTP/AVP 0

a=des:foo unknown e2e send