可選擇的會(huì)話建立過程

11.10.1概述

本章到目前为止介绍的过程描述了IMS在移动环境中建立多媒体会话的通用机制。如前所述，与IETF的SIP流程相比，IMSSIP流程更加复杂并需要额外的信令，因为IMS需要无线链路的资源预留和媒体授权。

在制定3GPPRelease6和Release7规范时，IMS逐渐演化成开放的多媒体通信平台，其接入网不仅限于蜂窝接入网，也包括通常资源十分紧缺的网络。UE可以从固定网络附着到IMS上，也可以从基于WLAN（无线局域网）接入技术附着。

此外，某些服务不需要特定的资源预留过程，例如与语音对话相比，基于文本的聊天服务（见11.10.2）就需求完全不同的资源和QoS。

为了满足新接入技术和特定服务的需要，IMS引入了其他可选择的会话建立机制。本书撰稿时，有些机制还在详细定义过程中。

11.10.4节说明了如何在附着到IMS的终端和IMS外SIP终端之间建立会话。

本节所有的例子显示了两个UE之间直接的信令流程，没有描述其间的网络,这是因为所涉及的网络实体和路由过程与本章前面所述几乎一样。 ,

11.10.2 无需资源预留时建立IMS会话

在好几种情况下不必先预留资源就可以建立会话。

IMS消息会话（见第5章）是用户间基于文本的聊天会话。与多媒体服务相比，他们要求不同的实时性和带宽要求。例如，视频流要求实时传输所有的媒体数据包，接收方一边能为用户展示连续的帧流。通常文本消息需要先用键盘输入,再整体发送到对端，有1〜2s的延迟不会影响用户体验。

在3GPP版本6中，媒体过程能够重用已建立的PDP上下文。即使相关SIP对话已经结束，即对话已经发出了BYE/200（OK）,终端或终端上的应用也可以选择为IMS相关的媒体保留已经建立的PDP上下文，由UE来决定这样的PDP保持激活多长时间。如果随后要建立相同或类似的资源预留需求，UE可以重用已预先建立的PDP上下文。

理论上，有两种方式不需要资源预留就建立会话：

•执行通常的IETF会话建立；或者

•当发送初始INVITE请求时（见11.10.2.2节)，设置预置条件为"met"（匹配）。

预置条件的使用通常会延长信令流程（见图11-6^⊙）,并还会延长会话建立时间。正是因为这个原因，在不需要资源预留的时候，应该只使用正常的IETF会话建立。

图11-14  双方UE都支持预先预留资源时建立IMS会话

11.10.2.1 双方UE都支持预先预留资源时建立IMS会话

考察原来第9章的例子，假定Tobias想邀请Theresa加入聊天会话。在承载层，IMS使用了消息会话中继协议（MSRP,参见第5章）。Tobias UE上的聊天应用已经为MSRP会话预留了背景PDP上下文；因此，在主叫端资源已经就绪可用。在被叫端，假定Theresa通过固定终端连接到归属网络提供商的IMS,如通过PC和DSL（数字用户线）。由于是固定网络连接，那一端完全不需要任何资源预留。

Tobias UE需要发出INVITE请求，在消息正文的第一个SDP Offer提议中指示MSRP协议：

m=message3404msrp/tcp*

a=accept-types:message/cpimtext/plaintext/html

a=path:msrp://[5555::aaa:bbb:ccc:ddd]:3402/slll271;tcp

a=max-size:1311072

由于本地资源已经就绪可用，并假定远端资源也可用，Tobias UE不需要在发出的SDP Offer提议中设置预置条件。

Theresa端满足这个假设，其UE用180(振铃中)响应收到的INVITE请求。在Theresa接受了呼入聊天请求以后，发出200(OK)响应，其中包括SDP Answer应答。此后，两个UE就可以在承载层进行MSRP消息交换。

11.10.2.2 回落到完整IMS会话建立/满足设置预置条件

在上例中，Tobias UE假定Theresa端资源已经可用。我们假定Theresa已经从移动设备注册，并没有为MSRP媒体流预留PDP上下文。Tobias将如上例一样发出首个INVITE请求，但是由于被叫端需要预留资源,TheresaUE将拒绝INVITE请求而发回421(需要扩展)响应，指示主叫端需要支持预置条件。

SIP/2.0 421 Unsupported

Require:precondition

当收到这个响应时，TobiasUE明白被叫端需要进行资源预留。因此，它构造另一个INVITE请求，其中包括

与首个INVITE中的SDP Offei提议相同的媒体和编解码方案

■指示本地链路已经满足了QoS相关预置条件("curr:qoslocalsendrecv"和"des:qos mandatory local sendrecv"),即在Tobias侧；

■指示TobiasUE不知道远端的预置条件的当前状态("curr:qoe remote none"),不知道Theresa UE将决定( "none")如何设置("des:qos none remote sendrecv")。

m=message3404msrp/tcp*

a=accept-types:message/cpimtext/plaintext/html

a=path:msrp://[5555::aaa:bbb:ccc:ddd]:3402/slll271;tcp

a=max-size:1311072

a=curr:qos local none

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

由于本地链路已经满足预置条件，削减了INVITE信令流的长度。Theresa UE不再需要从Tobias UE处确认是否满足了预置条件；因此Theresa发出的183(会话进行中）响应中，SDP Answer应答就没有出现“a=conf”行。这就意味着主叫端不会创建UPDATE请求。

会话只使用了一种媒体类型和一种编解码，因此，不需要太多SDP提议/应答的协商过程。

用于确认收到183(会话进行中）响应的PRACK请求及其200(OK）响应都没有携带SDP相关的信息。

本例还显示180(振铃中）响应不需要认(PRACK）。结果是会话建立过程比图11-15^☉的流程大大缩短了。

图11-15 建立完整IMS会话的反馈

11.10.3IMS会话建立时需要资源预留但不需要预置条件

在某些情况下，本章到目前为止所描述的会话建立过程代价太高、太复杂了。例如POC会话(见第6章)要使用更短的会话建立过程。而且，对于某些网络不提供SBLP(基于服务的本地策略，见3.9节)或不需要对相关媒体实施IMS特定计费时，使用更短的会话建立信令将大有益处。

为满足这些情况，定义了替代性的IMS会话建立过程，要求两端都预留资源，但是不需要使用预置条件机制。3GPP版本7将引入这些过程。

新机制的基础是SDP可以使媒体流处于“inactive”(非活动)状态。非活动状态意味着任何一端都不会发送或等待接收媒体，这等同于两端都使呼叫静音或都保持的情形。通常，SDP非活动标志只用于呼叫保持的情况，但此处背景略有不同。

本例中，假定Tobias再次呼叫Theresa,这次想邀请她加入语音对话。UE没有使用预置条件，而是在第一个SDP提议中将语音流设置为非活动状态。该SDP提议在首个INVITE请求中传输：

m=audio3458RTPAVP 96

a=rtpmap:96 AMR-WB

a=inactive

在Theresa端，我们假定支持这个过程，但是没有预留资源。当被叫UE接受了INVITE请求，它发回200(OK)响应，其中媒体流也设置为非活动状态。在发送/接收这个200(OK)响应之后，两边都开始预留资源。如果两边网络之一或双方都需要媒体授权(见3.9节)，Theresa的P-CSCF将在首个INVITE中包括媒体授权令牌，而Tobias的P-CSCF将在200(OK)响应中加入P-Media-Authorization消息头。

在TobiasUE预留相关资源以后，它在会话中构造一个二次INVITE(re-INVITE)请求，这个会话是由首个INVITE请求建立的。第二个INVITE请求包括第二次SDP提议，其中媒体设置为活动状态。这意味着主叫端已经就绪可以发送和接收相关的音频流：

m=audio 3458RTP/AVP 96

a=trpmap:96AMR-WB

a=active

网络将会通过第二个INVITE及其最终的200(0K)响应，交换计费相关的信息(见11.8节)，因为当发送这些消息时就可以关联承载层资源(PDP上下文)和信令层对话。

如果Theresa UE收到第二个INVITE请求时还没有完成资源预留，它返回一个180(振铃中)响应，但不向Theresa指示呼叫到来。该情形如图11-16所示。只有完成本地资源预留以后，UE才会向Theresa发出振铃，使她知道有呼叫到来。Theresa接受呼叫以后，其UE返回200(OK)响应，其中媒体流也指示为活动状态。

图11-16  IMS会话建立时需要资源预留但不需要预置条件，主叫端首先完成资源预留

图11-17显示了被叫端首先完成资源预留的情形。在这种情况下，被叫端等待主叫端发出二次INVITE(re-INVITE)请求。

这里的两个例子忽略了一些细节，实际上这些细节可能进一步扩展呼叫：

•  如果被叫端在第一个SDP应答中针对一个或几个媒体流发回一系列编解码方案清单，它将在183(会话进行中)响应中携带这个SDP应答，并要求主叫端发回PRACK,以便使主叫端最终决定选择哪个编解码方案(见11.5.3.5)。

•  如果TheresaUE需要使用预置条件，它将拒绝首个INVITE请求，要求主叫端实施预置条件扩展，如11.1022节所示。

•如果一端或两端资源保留失败，它会发出BYE请求，终止已建立的对话;

•由于会话建立过程使用媒体流未激活状态的用法仅限于需要资源预留的IMS终端，可能某些UE把初始INVITE请求中的非激活指示解释成其他含义。例如，如果被叫端UE不需要资源预留，就会向被叫用户发出振铃，而不管主叫端还没有完成资源预留。只有双方都支持并使用预置条件机制时，才能保证防止这种行为。

图11-17IMS会话建立时需要资源预留但不需要预置条件，被叫端首先完成资源预留

11.10.4在IMS与IMS外SIP终端之间建立会话

IMS不想成为封闭的系统，也需要与其他SIP voiP网络互连互通。在大多数“非IMS”网络中，不需要资源预留、媒体授权等机制，因此这些网络附着的UE也不支持。为了使这些机制在IMS内正常工作，保证在任何SIP UE之间进行无缝的呼叫连接，就需要互连互通过程。在这些过程的设计中，不要求非IMSUE支持IMS需要的SIP扩展。

图11-18 IMS附着的UE发起会话到非IMSUE

11.10.4.1由附着到IMS终端发起的会话

本例中假定Tobias企图发起到姐姐Theresa的呼叫，她姐姐正注册在IMS外的终端上。从Theresa的SIP地址，TobiasUE看不出她没有注册在IMS上，因此就构造了一个正常的INVITE请求,包括预置条件和所有IMS相关的扩展(见11.6.3节)：

INVITE sip:theresa@home2.hu SIP/2.0

Require:precondition

TheresaUE不支持预置条件机制。由于INVITE请求Require消息头中指示了预置条件扩展，TheresaUE拒绝这个INVITE请求，发回420（错误扩展）响应：

SIP/2.0 420 Bad Extension

Unsupported:precondition

当收到这个响应时，TobiasUE构造新的INVITE请求，这次避免使用预置条件。此时回落到11.10.2.1节描述的机制，即它发出新的初始INVITE请求，指示媒体集为非活跃状态：

m=audio3458RTP/AVP96

a=rtpmap:96AMR-WB

a=inactive

在示例的流程中，假定TheresaUE现在指示Theresa呼叫到来，发送180（振铃中）响应。由于Theresa UE不支持l00rel机制（见11.5.2节），它不能在临时响应中发送任何SDP。Theresa接受呼叫以后，其UE发回200（OK）响应，并将媒体流集设置为“非活跃”。尽管被叫UE准备好接收媒体，它也必须在SDP应答中设置非激活标签，由于它只允许对包含“非活跃”标签的SDP提议应答相同的“非活跃”。

m=audio3458RTP/AVP96

a=rtpmap:96AMR-WB

a=inactive

此后，TobiasUE开始预留资源——会话建立流程与11.10.2.1节描述的基本一样。

11.10.4.2由IMS外终端发起的会话

图11-19展示了由IMS外终端发起的会话的情况。此时，Tobias呼叫Theresa,Theresa附着在本地IMS网络中。由于TobiasUE假定远端已经请求了资源使媒体连接可用，它不会在SDP提议中填入任何特殊指示。这意味着它在发送、接收双向（sendrecv）语音流时都可用。由于sendrecv是媒体流的缺省标签，可以省略。

m=audio3458TRP/AVP96

a=rtpmap:96AMR-WB

图11-19  非IMSUE向附着到IMS的UE发起会话

然而，Theresa侧还是需要资源预留，因此当她的UE接受呼入INVITE请求时，会将媒体设置为非活动状态。

m=audio3458TRP/AVP96

a=rtpmap:96AMR-WB

a=inactive

由此开始的会话建立流程，与11.10.2.1节描述的完全一样。