資源預留

11.6.1概述

Tobias和Theresa之间的媒体会话是通过SIP和SDP信令来协商的。在我们的例子中，两个UE都使用专用的信令PDP上下文来传输SIP信令，它们不得不建立一个或多个媒体PDP上下文来传输媒体流。

建立媒体PDP上下文的过程称为“资源预留”，两个UE完全独立地执行该过程。

建立媒体PDP上下文会花费一些时间甚至会失败：例如当无线链路上没有足够资源时。这意味着在资源被成功预留之前，根本无法保证能够建立起所协商的媒体会话。

因此，Theresa UE不应将会话请求(INVITE)到达的信息通知给她，也就是说，在确认本地和主叫用户侧的资源预留都已成功之后，它才开始振铃。

为了做到这一点，双方UE在SDP提议/应答的协商过程中交换预置条件(precondition)。这些预置条件主要用于指示：

•  当TobiasUE侧的资源预留成功后，它要向TheresaUE发送一个SIPUPDATE请求；

•  TheresaUE在收到来自对端的SIPUPDATE请求，而且自己也成功地完成资源预留之后，才开始振铃。

此外，预置条件还指示了当某个特定的媒体流无法成功预留时应该如何处理。

图11-6概要展示了会话建立过程中SIP、SDP提议/应答、资源预留、预置条件、SIPPRACK以及SIPUPDATE方法之间的关系。

图11-6   会话建立过程中的SIP.SDP提议/应答和预置条件

11.6.2 183(会话进行中）响应

在本章开头部分已经介绍，只有在双方用户无线链路上的资源预留全部成功之后，才将IMS会话建立的尝试告知Theresa(被叫方）。只有资源预留成功以后，TheresaUE才会对INVITE请求发出SIP180(振铃）响应。

而另一方面，TobiasUE希望早点得到被叫终端的响应，尤其是由于在IMS中必须先进行SDP提议/应答协商，然后才能开始资源预留。因此，在收到INVITE消息之后，Theresa UE将返回一个183(会话进行中）响应，指示会话建立过程已经启动，只是还没有告知被叫用户。

11.6.3预置条件是否必须满足

在发送第一个INVITE请求之前，主叫终端必须添加一个Require头，包含值"precondition"：

Require:sec-agree,precondition

这可以确保如果被叫终端根本不支持预置条件机制时，它可以拒绝这个INVITE请求。但是，这意味着如果Theresa的终端不支持关于预置条件的SDP扩展，那么Tobias和Theresa之间的会话就根本无法建立起来。这真的是IMS的本意么？

让我们假设Theresa的终端不支持预置条件机制，但仍然继续进行会话建立过程(见图11-7）,进一步假设Theresa侧成功地完成了资源预留。这样，她的终端就会立刻告知她接到了一个呼叫，并且开始向Tobias发送早期的媒体。

在这一瞬间，Tobias可能还根本没有开始在无线链路上进行资源预留，因为他还在等待Theresa端返回SDP应答。即使他在发出初始INVITE请求后立刻就开始进行资源预留，也无法确保在收到TheresaUE返回180(振铃）响应时，这一过程已经完成。

更糟糕的是，Theresa可能摘起电话(这将会导致她的终端发出一个200(0K）响应）并开始交谈，但Tobias还在进行资源预留的过程中。如果这时Tobias—侧的资源预留失败了，那么Theresa就会遭遇这样一个呼叫：信令平面上显示是成功的，但媒体平面上永远无法通过会话建立起连接。

因此，如果Theresa的终端不支持预置条件，但由于收到的INVITE请求中Require头对此有所要求，她就会返回一个420(无效的扩展）响应，包含一个Unsupported消息头。

SIP/2.0 420 Bad Extension

Unsupported:precondition

图11-7   没有预置条件时的SIP会话建立过程

当TobiasUE收到这个响应后，它就可以决定是再次发送一个不包含预置条件的INVITE请求，或者完全放弃到对端的呼叫。

在IMS版本5中，假设双方终端都支持预置条件机制；这样，实际上导致了IMS终端和非IMS终端之间根本无法建立呼叫，因为非IMS终端并不支持预置条件。版本6定义了交互过程，解决了上述情况中的问题。尽管如此，由于无线链路上要求资源预留过程，在IMS内部对预置条件机制的支持仍然是强制和必需的。

11.6.4 预置条件

[RFC3312]中引入了SDP预置条件机制，使UE能够推迟完成SIP会话的建立,直到一方或双方都成功完成了资源预留。对于所有连接到IMS的UE,这个SIP和SDP扩展都强制要求支持。

到目前为止，因特网工程任务小组(IETF)只定义了“qos”一种预置条件类型，但以后可能定义更多。“qos”标签意味着，设置该预置条件是由于m行指示的相关媒体流应具有某种特定的质量要求。服务质量(QoS)主要依赖于无线链路上预留的带宽，以及网络路由器处理数据包的优先级，这些数据包传输了大块的语音和视频数据。

11.6.4.1  第一个SDP提议的预置条件

在11.5节中已经介绍，通过SDP提议/应答机制,TobiasUE在发往TheresaUE的首个INVITE请求中提出了3个不同的媒体类型。为了说明预置条件机制，我们选取3个媒体之一作为例子，并用预置条件特定的指示对它进行如下的扩展(用粗体表示)：

m=audio3458RTP/AVP0 96 97 98

a=rtpmap:0 PCMU，

a=rtpmap:96 G726-32/8000

a=rtpmap:97 AMR-WB

a=rtpmap:98 telephone-event

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

SDP中每个m行的块都需要给出一组独立的预置条件。注意仅取m=audio行作为例子，实际的SDP中其他的两个m行中也都设置了预置条件。首先，我们来看一下倒数第二行：

a=des:qos mandatory local sendrecv

这一行指出了主叫用户端(local)要求(des)的服务质量(qos)预置条件。主叫用户需要在发送和接收两个方向(sendrecv)预留资源，因为音频流是双向的(即两个用户要相互交谈并听到对方讲话)。它还声明如果主叫用户不能成功预留资源，会话将不会建立(mandatory)。

最后一行：

a=des:qosnoneremotesendrecv

指出了被叫用户端(remote)要求(des)的服务质量(qos)预置条件。由于主叫和被叫用户终端彼此之间没有直接连接，因此主叫终端不知道对方终端以哪种方式附着到网络。有可能Theresa的终端是通过CS电话网络接入，因而并不需要进行任何资源预留，因此主叫侧只能要求如果对端需要预留资源的话，应该同时在收和发两个方向上进行预留(sendrecv)；但是主叫侧当前并不知道真的需要进行预留才能建立起媒体会话(none）。

现在为止，主叫终端只是表达了它对通信双方所期望(des)的预置条件，它还需要告知当前的资源预留状态。这是新加的两行的作用。

a=curr:qos local none

a=curr:qos remote none

这两行表示目前(curr)无论是主叫方(local）还是被叫方(remote)都还没有(none)实现任何与服务质量(qos)有关的预置条件。

a=des的行能够用于为本地和对方用户设置预置条件，而a=curr的行用于指示目前已经实现了那些预置条件。

11.6.4.2第一个SDP应答中的预置条件

我们已经知道，Theresa的终端也是通过无线链路附着到IMS上，并且也支持预置条件机制。因此，它会对所收到的SDP提议给出格式完好的答复，并包含它自己的预置条件。我们这次仍然只以第一个媒体类型为例来介绍这些预置条件。

m=audio4011RTP/AVP969798

a=rtpmap:96G726-32/8000

a=rtpmap:97AMR-WB

a=rtpmap:98telephone-event

a=curr:qoslocalnone

a=curr:qosremotenone

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote senrecv

a=conf:qos remote sendrecv

主要特别注意的是对端和本地的概念已经改变了，因为从Theresa的角度看，她的终端是本地的，而Tobias的终端是对端的。她的终端现在逐行给出它自己的预置条件。第5行：

a=curr:qos local none

表示她当前还没有在本地预留任何与QoS有关的资源。第6行:

a=curr:qos remoten one

表示它已经从对方(通过第一次提议)得知：对方现在还没有预留任何与QoS有关的资源。第7行：

a=des:qos mandatorylocal sendrecv

表示它强制要求自己在收发两个方向都预留资源，然后才可以开始音频会话。注意最初由主叫侧设置的值"none”已经变为“mandatory",因为Theresa的终端是通过无线链路附着的，因此在开始发送媒体之前必须在本地预留资源。第8行:

a=des:qos mandatory remote senrecv

表示它已经从对方(通过第一次提议）得知收发双方向的资源预留都是强制要求的。第9行：

a=conf:qosremotesendrecv

表示主叫终端(remote）在收发双向(sendrecv）都建立起资源预留(qos）后，应发送确认(conf）信息。这行是由被叫方新加到SDP中的。这次增加是必要的，因为被叫终端在双方资源预留都完成之前，不希望向被叫用户振铃或者开始媒体传输。

这个SDP应答通过183(会话进行中）响应发送给主叫终端。

11.6.4.3开始资源预留

接下来进行第二次SDP提议/应答交换，即Tobias的终端发送PRACK请求，声明最终选择的媒体类型和编解码方案。对于音频流，如下所示：

m=audio3458RTP/AVP9798

a=Ttpmap:97AMR-WB

a=rtpmap:98telephone-event

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

所接收到的m=conf一行没有再重复，因为终端已经知道：它需要在完成资源预留后发送一个确认。

当TobiasUE发出PRACK请求时，它可以开始进行资源预留，因为此时已经知道了各种媒体流的QoS要求以及这些媒体流要要用的编解码方案。

Tobias的终端也可能在发出第一个INVITE请求后就开始进行资源预留。当它发出PRACK请求后，惟一需要作的就是变更预留的资源(在GPRS情况下就是所建立的媒体PDP上下文的参数）。之所以需要进行变更是因为刚才的资源可能是按照最高QoS要求的媒体流和编解码方案进行预留的，但是商定的媒体和编码可能具有不同的QoS要求。

Theresa UE在发出183(会话进行中）响应后就可以开始进行资源预留，但这里我们假设它对PRACK请求返回了200(OK）响应后才开始预留。这个响应包含第二个SDP应答，对于音频流的部分如下所示：

m-audio 40HRTP/AVP 97 98

a=rtpmap:97AMR-WB

a==rtpmap:98telephone-event

a=curr:qoslocal none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

这里仍然不需要重复a=conf行。由于资源预留的状态没有改变，因此第二个应答中和预置条件有关的信息没有任何新的内容。

11.6.4.4成功的资源预留

现在，双方的UE都开始资源预留。在GPRS中，这意味着它们建立一个或多个媒体PDP上下文，作为次PDP上下文(见第13章）。Tobias UE和Theresa UE都可能先完成预留。不论哪种情况下，Theresa的终端都必须在得知双方都已完成资源预留之后，才可以向Theresa指示呼叫的到达(即振铃）。

我们假设被叫方首先完成资源预留：这种情况下，它只需等待，直到收到主叫侧的确认。该确认是应被叫方请求发出的，请求方法是在183(会话进行中）响应中将第一个SDP应答设置a=conf行。

一旦主叫方预留了所需的资源，它就会向被叫方发送一个SIP UPDATE请求表示确认，该请求作为INVITE请求所建立的对话中的一个后续请求。这个UPDATE请求中包含了第三个SDP提议，说明了主叫方预留了哪些资源。

m=audio3458RTP/AVP97 98

a=rtpmap:97AMR-WB

a=rtpmap:98telephone-event

a=curr:qoslocalsendrecv

a=curr:qosremotenone

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

此处惟一的不同点是第一个a=curr行从"none”变为“sendrecv”。这样，Tobias指出与音频流QoS有关的本地资源状态发生了变化。在收发两个方向，这些资源都已经成功预留。

由于Theresa的终端已经先完成了资源预留，因此它对UPDATE请求发出200(OK)响应之后，就立即可以开始振铃，因为它现在可以确认双方都已经预留了足够资源来收发音频流。当它开始振铃时，会同时对INVITE请求发出180(振铃)响应。

对UPDATE的200(OK)响应包含第三个SDP应答，其中与音频流有关的SDP信息如下：

m=audio 4011RTP/AVP 97 98

a=rtpmap:97AMR-WB

a=rtpmap:98telephone-event

a=curr:qos local sendrecv

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

从中可见，所有资源预留状态现在都已经达到了期望的状态，因此，对预置条件的协商已经成功完成。

我们再假设Theresa的资源预留所需要的时间长于Tobias：这种情况下，TheresaUE还在进行资源预留时就会收到UPDATE请求。虽然它并不会开始振铃,但它会返回一个200(OK)响应，其中与音频流有关的SDP信息如下：

m=audio4011RTP/AVP97 98

a=rtpmap:97AMR-WB

a=rtpmap:98telephone-event

a=curr:qos local none

a=curr:qos remote sendrecv

a=des:qos mandatory local sendrecv

a=des:qos mandatory remote sendrecv

这里惟一的差别在于本地资源预留状态仍然是“none”。当本地资源预留完成之后，TheresaUE就会开始振铃，同时发出一个180(振铃）响应，其中不再包含SDP部分。然而TobiasUE会认为这个180(振铃）响应标志着对端(即Theresa）已经成功完成了资源预留：因为这个原因，180(振铃）响应也必须进行可靠的传递，即要求TobiasUE用一个PRACK请求来应答(见11.5.2）。

一旦双方都预留了资源，两个UE之间就可以进行媒体交换了。

11.6.5相关标准

与11.6节有关的规范有：

•RFC3311  TheSession Initiation Protocol(SIP)UPDATE Method.

•RFC3312  Integration of Resource Management and Session Initiation Protocol.