媒体控制

11.7.1概述

由于UE通常是通过无线链路附着到IMS的，带宽资源稀少，因此需要谨慎处理。在11.5节介绍了双方交换对于会话中使用的媒体和编解码方案的倾向意见,直到一致同意媒体流的某个特定组合，并且每个媒体流使用同一种编解码方案。

由于媒体流的路由不经过任何CSCF,因此IMS网络需要对资源的预留进行授权。这样，任何时候当P-CSCF收到对话中第一个发往UE的SIP消息时（见3.11.1节），它会要求PDF（策略决策功能）生成一个媒体授权令牌（见图11-8）。这个令牌被加入到INVITE请求中并发往TheresaUE。TobiasUE也会在183（会话进行中）响应中得到它的本地令牌。

在SDP提议/应答过程中，本地P-CSCF能够告诉UE将特定的媒体流聚合成一组填入一个媒体PDP上下文中，或者为某些媒体流保留单独的媒体PDP上下文——这通过SDP媒体行分组机制实现。

除此之外，网络运营商可能希望限制每个UE可以使用的媒体类型和编解码方案。为了实现这个目的，P-CSCF和S-CSCF检查INVITE请求中的SDP信息。如果某个CSCF认为不允许使用某个媒体类型或编解码方案，它就会给TobiasUE发一个拒绝消息。在本例中，我们假设不会发生这种情况。不过，媒体策略的通用过程会在11.7.6节中介绍。

图11-8   媒体授权信息的传输

SDP提议/应答过程完成之后，各UE就可以开始为商定的媒体预留资源了。在GPRS中，当使用一个专用的信令PDP上下文时，预留资源意味着每个UE现在可以为媒体建立一个或多个次PDP上下文。在每个建立媒体PDP上下文的请求中，UE把从P-CSCF处得到的媒体授权令牌包含进来。

GGSN接到一个新的PDP上下文请求，首先把令牌返回给生成它的PDF。它还在给PDF的消息中包含所请求的会话参数。PDF和策略实施点（PEP）对资源预留请求进行检查。接下来，GGSN和UE之间建立起所请求的媒体PDP上下文。

未来其他类型的接入网络也会定义类似的过程，这里只是使用GPRS作为一个例子。

11.7.2媒体授权

当Theresa的P-CSCF收到INVITE请求后，会请求PDF生成媒体授权令牌。P-CSCF会在INVITE请求中添加一个P-Media-Authorization消息头，包含所收到的令牌，并将请求发往TheresaUE。

INVITE sip:[5555:5:6:7:8]:1006SIP/2.0

P-Media-Authorization:example-auth-token2

TheresaUE将使用这个令牌来建立媒体PDP上下文，或者建立双方UE商定的多个媒体流的PDP上下文。

随后，Tobias的P-CSCF将收到183（会话进行中）响应，它也会向它的PDF申请一个媒体授权令牌。它将该令牌包含在P-Media-Authorization消息头中，并发给TobiasUE。

SIP/2.0 183 Session in Progress

P-Media-Authorization:example-auth-tokenl

由于每个UE的资源预留和授权都是本地事件，这两个令牌是不同的。

每个UE对于由一个INVITE请求而生成的所有媒体会话，只会收到一个令牌。不论UE建立多少个PDP上下文，在请求资源时总是使用这同一个令牌。因此，UE完全不需要了解令牌的内容和编码，它只需要在SIP消息中收到令牌，然后把它放在PDP上下文激活请求（ACTIVEPDPCONTEXTREQUEST）中。

11.7.3媒体行的分组

关于QoS资源授权的一节（3.9.1.1节）已经包含了一个媒体行分组的例子。本章的例子中我们假设两端的分组是不同的。

11.7.4单一预留流

在PRACK请求里的第二个SDP提议中，Theresa的P-CSCF会向她的UE发送如下与媒体行分组有关的信息：

v=0

0=-13579241357924INIP65555::1:2:3:4

s=-

c=IN IP6 5555::1:2:3:4

t=907165275 0

a=group:SRF 1

m=audio 3458 RTP/AVP 97 98

a=mid:l

a=rtpmap:97 AMR-WB

a=rtpamp:97 telephone-event

m=video 3400 RTP/AVP 99

a=mid:l

a=rtpamap:99H.261

m=video 0 RTP/AVP 98

SDP头部的a行定义了一个单一预留流(SRF)组，号码为“1”：即本组中所有的媒体流都进入到同一个PDP上下文中。

两个媒体行(一个音频和一个视频)都跟随了一个a行，指示了媒体流标识(MID),两处都设置为上述定义的分组号码“1”。这意味着P-CSCF指示TheresaUE将两个媒体流都分组到一个PDP上下文中。

11.7.5 分离的流

芬兰的P-CSCF要求分离的媒体流，因此它将如下与媒体行分组有关的信息添加到SDP应答中，该应答包含在对PRACK请求的200(OK)响应中发往Tobias UE。

v=0

o=-13579241357924INIP65555::5:6:7:8

s=-

c=INIP65555::5:6:7:8

t=907165275 0

a=group:SRF 1

a=group:SRF 2

m=audio 4011 RTP/AVP 97 98

a=mid:l

a=rtpmap:97 AMR-WB

a=rtpmap:97 telephone-event

m=video 4012 RTP/AVP 99

a=mid:2

a=rtpmap:99H.261

m=video0RTP/AVP 98

a=group行生成两个单独的SRF组，号码分别是“1”和“2”。由于音频流指示SRF组为“1”，视频流指示SRF组为“2”，Tobias UE必需为每个媒体流预留单独的媒体PDP上下文(见图ll-9)。

图11-9   例子情景中的媒体流和传输

11.7.6   媒体策略

P-CSCF和S-CSCF可以拒绝SDP提议的特定媒体类型或编解码方案。这可能是由于运营商的策略。一个可能的原因是运营商不允许使用任何未知的媒体类型或未知的编解码方案，因为网络可能无法对这些媒体计费。

如果CSCF发现SDP提议中包含了不支持的媒体类型或编解码方案，它就会使用488（此处不接受）响应来拒绝该请求，并在响应正文中指出所支持的媒体类型。

本例的场景中，假设上述情况都不会发生。图11-10展示了一种最差的情况,路由中每个CSCF都不支持特定的媒体元素，实际中这样的极端情况不太可能发生。

图11-10  媒体策略中的最差情况

11.7.7相关标准

与11.7节有关的规范有：

.  RFC3313Private Session Initiation Protocol(SIP) Extensions for MediaAuthorization.

.  RFC3388Grouping of Media Lines in theSession Description Protocol(SDP).

.  RFC3524Mapping of Media Streams to Resource Reservation Flows.