Precondition资源预留

Precondition资源预留

 

在移动通信网络，UE之间传输媒体流基于PDP上下文，建立媒体PDP上下文的过程称为资源预留。

 

媒体PDP上下文建立会花费一些时间甚至失败，这意味着在资源被成功预留之前，无法保证协商的媒体会话是否可以建立起来。因此终端不应该在双方资源预留成功之前有任何通知指示产生，比如振铃提示、回铃提示等。

资源预留功能在SIP信令上体现为两个阶段，第一个阶段的所有媒体协商仅仅是为了双方进行资源预留准备（比如媒体协商如果承载在183响应中，终端不能将183做为回铃指示，因为资源预留还没有建立成功）。在资源预留建立成功之后，使用Update信令来表明资源预留建立完成，进入第二个阶段，之后的18X信令就可以像普通SIP流程一样，做为放回铃音的指示信息。

1.UE_A发起的invite请求：

• 针对资源预留功能，SIP信令上新增precondition扩展标识，指示支持资源预留功能。《中国电信IMS网络SIP协议总体技术要求》不建议初始Invite携带Require:precondition头域，主要考虑资源预留功能不能为现有业务或网络带来增值，而且还增加了信令交互的复杂性。

• 同时针对SDP属性也进行扩展，增加了“qos”一种前提类型。

a=curr:qoslocal none
a=curr:qosremote none
表示目前（curr），无论是主叫方（local）还是被叫方（remote）都还没有（none）任何资源预留。

a=des:qosmandatory local sendrecv
表示主叫用户（local）要求（des）在发送和接收两个方向（sendrecv）都要提供资源预留，并且不能成功预留资源，会话将不会建立（mandatory）

a=des:qosnone remote sendrecv
表示要示（des）被叫用户（remote）也需要提供双向（sendrecv）的资源预留，但还不确定被叫用户是否真的需要进行预留（none）。

2. UE_B回应183
UE_B在收到Invite请求后，得知主叫方支持资源预留功能，同时他也支持资源预留功能，则提供183响应，在SDP中包含UE_B支持的所有编码，并针对“qos”描述进行补充。

注意：
对端和本地的概念已经改变，因为从UE_B的角度来看，自己已经是本地，而UE_A是远端。

a=curr:qoslocal none
a=curr:qosremote none
表示目前（curr），无论是主叫方（local）还是被叫方（remote）都还没有（none）任何资源预留。

a=des:qosmandatory local sendrecv
表示强制要求自己在收发两个方向都进行资源预留，之后才允许进行会话。

a=des:qosnone remote sendrecv
表示从对方得知，对方也强制要求收发双向的资源预留。

a=conf:qosremote sendrecv
告知UE_A，如果它的双向资源预留完成后，必须发送确认（conf）信息。这里确认信息在SIP消息中体验为发送UPDATE信令。

3.UE_A发送PRACK请求，其中媒体仅包含他已确认的唯一编码。

在SDP的“qos”描述中，双方都已经表示需要进行资源预留，并且当前都还没有资源预留完成。这里UE_A不再包含a=conf:qosremote sendrecv，因为他知道对方在等待他资源预留完成后的确认消息。

4.UE_B给PRACK请求进行回应，其中“qos”描述没有任何变化。

5.UE_A建立媒体PDP上下文，当资源预留成功后，UE_A发送UPDATE请求给远端进行确认。

其中a=curr:qoslocal sendrecv表明UE_A当前（curr）双向的资源预留建立成功。

6.UE_B给UPDATE请求进行回应

5、6、7、8、9）在UE_B得知双方的资源预留都已经建立成功后，UE_B开始振铃，同时给UE_A发送180，UE_A在了解双方的资源预留建立成功后，收到180则给当前用户回铃提示。后续流程同普通SIP软交换流程相同，不再详细描述。