本文深入解析了移动通信网络中UE间基于PDP上下文的媒体流传输资源预留流程，包括SIP信令上的precondition扩展标识及SDP属性扩展，如qos前提类型的使用。详细介绍了从Invite请求到资源预留成功的整个过程，强调了资源预留功能在SIP流程中的作用。
https://blog.youkuaiyun.com/liujianfeng1984/article/details/35346141
在移动通信网络，UE之间传输媒体流基于PDP上下文，建立媒体PDP上下文的过程称为资源预留。
媒体PDP上下文建立会花费一些时间甚至失败，这意味着在资源被成功预留之前，无法保证协商的媒体会话是否可以建立起来。因此终端不应该在双方资源预留成功之前有任何通知指示产生，比如振铃提示、回铃提示等。
资源预留功能在SIP信令上体现为两个阶段，第一个阶段的所有媒体协商仅仅是为了双方进行资源预留准备（比如媒体协商如果承载在183响应中，终端不能将183做为回铃指示，因为资源预留还没有建立成功）。在资源预留建立成功之后，使用Update信令来表明资源预留建立完成，进入第二个阶段，之后的18X信令就可以像普通SIP流程一样，做为放回铃音的指示信息。
-
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协议总体技术要求》。
扫一扫
849
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
