|
为IP网络中QoS保障机制之一的资源预留(RSVP)协议，对于统一的IMS系统能否支持多种前提类型(目前只有QoS一种)还有待于进一步验证。
IP多媒体子系统(IMS)是提供实时和非实时的IP多媒体业务的通用体系结构，由于不限定下层接入技术等特点，它在固定、移动网络融合的过程中受到广泛关注。为了保证移动域IMS的服务质量(QoS)，RFC3312定义了在SIP会话建立过程中进行QoS资源预留的机制，本文就IMS会话中资源预留的实现过程进行了具体分析。
媒体协商和前提
媒体协商和对前提的处理是IMS中两个密切相关的概念。在IMS中，两个UE之间是通过媒体协商就会话中使用的媒体组合以及使用哪种编码方式达成一致。为了两个UE之间能相互协商，人们使用了SDP提供／应答机制，该机制允许UE推迟SIP会话建立的完成，直到双方都成功完成资源预留。这里对所有连接到IMS的UE都强制要求支持SIP和SDP的扩展。
在一般情况下，SIP仅交换一次提供／应答之后就开始建立媒体连接了。但在IMS中，由于双方的UE都必须准备接收所选择的任何编码类型，所以如果在第一次SDP应答中对任何媒体包提供一种以上的编码方案，那么就会产生第二次提供／应答的交互，为每种媒体流选择唯一的编码方案。否则需要在空中接口上按照较高带宽的编码方案预留资源，对于无线资源将是一种浪费。
IMS中的资源预留与SDP前提／应答机制
建立媒体PDP上下文的过程称为资源预留。对于双方的UE而言，建立PDP上下文的执行过程是相互独立的。这意味着在资源被成功预留之前，根本无法保证所协商的媒体会话是否可以建立起来。因此，在确认本地和主叫侧的资源预留都已成功之前，被叫侧不应振铃。
为了做到这一点，双方的UE在SDP提供／应答的协商过程中彼此交换前提(precondition)。这些前提主要用于指示：当主叫UE处的资源预留成功后，要把一个SIPUPDATE请求发往被叫UE；被叫UE在未收到来自对方的SIPUPDATE请求同时自己也未成功地完成资源预留之前不应振铃。此外，前提还指示当某个特定的媒体流无法成功进行资源预留时应该如何处理。
IMS会话建立中的QoS资源预留实例
QoS资源预留的完成过程如下：
第一次SDP提供／应答交互
主叫UE在发往被叫UE的第一个INVITE请求中提供了媒体类型，并用前提特定的指示对消息进行了扩展。被叫用户在支持前提机制的情况下对收到的第一个SDP提供给出了一个183(会话进行中)答复，答复中包含了自身的前提。
第二次SDP提供／应答的交互(开始资源预留)
第二次SDP提供包含在主叫终端发送的PRACK请求中，用来声明最终选择的媒体类型和编码方案。在明确了双方媒体流QoS要求以及媒体流编码方案的前提下，主叫UE开始进行资源预留。这里要注意的是，当遇到商定的媒体和编码的QoS要求不同的情况时，主叫UE需要对预留的资源进行变更。第二次SDP应答包含在被叫UE已回送的200(ok)中，此时被叫UE已开始进行资源预留了。
资源预留成功完成
主被叫的UE都开始进行资源预留以后，任何一方的UE都可能比对方先完成资源预留。无论哪种情况，被叫终端都必须在确定双方都完成资源预留的前提下才能向主叫发送振铃消息，即被叫方在完成资源预留的同时还要等待接收主叫方的确认消息。
主叫方一旦完成资源预留，就会发送一个SIPUPDATE请求给被叫方进行确认，请求中包含了第三次SDP提供，对预留资源的情况加以说明。
被叫方完成了资源预留后，又收到主叫方发来的UPDATE请求，此时被叫UE可以确定双方都已成功完成资源预留，因此被叫终端发出了包含第三次SDP应答信息的200(ok)响应。
由此可见，所有资源预留状态都已经达到了所要求的状态，对前提的协商已经完成。一旦双方都预留了资源，两个UE之间就可以进行媒体交换了。此时被叫方确认双方都已经预留了足够的资源收发音频流，于是立即开始振铃，同时对INVITE请求发出180(振铃)响应。
由于服务的多样性以及对网络资源的依赖程度决定了在网络中实现QoS保障的复杂性。固定和移动IMS在业务能力方面的差异、体系架构的差异、协议的差异等问题将成为IMS能否实现固定和移动网络融合的关键问题。因此，作为IP网络中QoS保障机制之一的资源预留(RSVP)协议，对于统一的IMS系统能否支持多种前提类型(目前只有QoS一种)还有待于进一步验证。
(t113)
 |
频道声明：本频道的文章除部分特别声明禁止转载的专稿外，可以自由转载.但请务必注明出出处和原始作者 文章版权归本频道与文章作者所有.对于被频道转载文章的个人和网站,我们表示深深的谢意。
| 原始作者:佚名 |
录入时间:2007-1-3 2:03:27 |
| 信息来源:不详 |
投稿信箱:itqoo@126.com |
|
|
 |
|
用户登录 
新用户注册 
网友评论：（只显示最新10条。评论内容只代表网友观点，与本站立场无关！） 