Precondition资源预留

https://blog.csdn.net/liujianfeng1984/article/details/35346141

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

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

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

1. US_A发起Invite请求

INVITEsip:ue_b@ ims.com SIP/2.0

Supported:precondition，100rel

Require:precondition

Content-Type:application/sdp

v=0

o=a00008646 6672 IN IP4 1.1.1.1

s=SIPCall

c=INIP4 1.1.1.1

t=00

m=audio10054 RTP/AVP 8 0

a=rtpmap:8PCMA/8000

a=rtpmap:0PCMU/8000

a=curr:qoslocal none

a=curr:qosremote none

a=des:qosmandatory local sendrecv

a=des:qosnone remote sendrecv

针对资源预留功能，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”描述进行补充。

SIP/2.0183 Session Progress

Content-Type:application/sdp

v=0

o=a00008646 6672 IN IP4 2.2.2.2

s=SIPCall

c=INIP4 2.2.2.2

t=00

m=audio10054 RTP/AVP 8 0

a=rtpmap:8PCMA/8000

a=rtpmap:0PCMU/8000

a=curr:qoslocal none

a=curr:qosremote none

a=des:qosmandatory local sendrecv

a=des:qosmandatory remote sendrecv

a=conf:qosremote sendrecv

注意：

对端和本地的概念已经改变，因为从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请求，其中媒体仅包含他已确认的唯一编码。

PRACKsip:ue_b@ ims.com SIP/2.0

Supported:precondition，100rel

Require:precondition

Content-Type:application/sdp

v=0

o=a00008646 6672 IN IP4 1.1.1.1

s=SIPCall

c=INIP4 1.1.1.1

t=00

m=audio10054 RTP/AVP 0

a=rtpmap:0PCMU/8000

a=curr:qoslocal none

a=curr:qosremote none

a=des:qosmandatory local sendrecv

a=des:qosmandatory remote sendrecv

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

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

SIP/2.0200 OK

Content-Type:application/sdp

v=0

o=a00008646 6672 IN IP4 2.2.2.2

s=SIPCall

c=INIP4 2.2.2.2

t=00

m=audio10054 RTP/AVP 8 0

a=rtpmap:8PCMA/8000

a=rtpmap:0PCMU/8000

a=curr:qoslocal none

a=curr:qosremote none

a=des:qosmandatory local sendrecv

a=des:qosmandatory remote sendrecv

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

UPDATEsip:ue_b@ ims.com SIP/2.0

Supported:precondition，100rel

Require:precondition

Content-Type:application/sdp

v=0

o=a00008646 6672 IN IP4 1.1.1.1

s=SIPCall

c=INIP4 1.1.1.1

t=00

m=audio10054 RTP/AVP 0

a=rtpmap:0PCMU/8000

a=curr:qoslocal sendrecv

a=curr:qosremote none

a=des:qosmandatory local sendrecv

a=des:qosmandatory remote sendrecv

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

    UE_B给UPDATE请求进行回应

SIP/2.0200 OK

Content-Type:application/sdp

v=0

o=a00008646 6672 IN IP4 2.2.2.2

s=SIPCall

c=INIP4 2.2.2.2

t=00

m=audio10054 RTP/AVP 8 0

a=rtpmap:8PCMA/8000

a=rtpmap:0PCMU/8000

a=curr:qoslocal sendrecv

a=curr:qosremote sendrecv

a=des:qosmandatory local sendrecv

a=des:qosmandatory remote sendrecv

其中a=curr:qoslocal sendrecv表明当前UE_B的双向资源预留也已经建立成功。

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

备注：

当前实例讲解的资源预留的流程仅描述的在非早期媒体情况下，如果在早期媒体情况下处理资源预留，信令上会稍有一点不同，详见《中国电信IMS网络SIP协议总体技术要求》。