ims会话概述和标识

11.1概述

本章介绍了一个IMS会话的例子，该会话发生在Tobias和Theresa之间，二者都在各自的归属网络中注册，并且目前都在其他国家漫游(见9.1节）。

IMS(IP多媒体子系统）利用SIP(会话初始化协议）和SDP(会话描述协议）来确保Tobias和Theresa之间互相交谈，并且在手机屏幕上看到对方。为了在无线环境下实现上述功能，需要执行以下步骤：

•  TobiasUE需要创建一个INVITE请求，其中包含Theresa注册的公共用户标识，这样才能找到她——11.2.4节。

•  所有的SIP消息都必须经过两人的P-CSCF(代理呼叫会话控制功能）和S-CSCF(服务CSCF）——11.3节。

•  所有的SIP消息都要通过在UE和P-CSCF之间建立的IP安全(IPsec）安全联盟(AS）——11.3.3.1节。

•  所有的SIP消息都以压缩的形式在UE和P-CSCF之间传递——11.4节。

•  两个UE要对它们之间即将交换的媒体流达成一致。在本例中，它们将交换一个双向的音频流，以实现两人交谈；还有一个双向视频流，使得他们可以看到对方11.5节。

•  两个UE要采用协商一致的惟一的编解码方案，用于两人交换的每个媒体流——11.5节。

•  网络要对会话的媒体进行授权，使得用户可以预留相应的资源一11.7.2节。

•  两个UE都要预留资源(即它们要建立起必要的媒体PDP上下文，用于和网络之间传递媒体流）——11.6节。

•  首先两端要成功预留媒体会话所需的资源(即媒体PDP上下文），然后TheresaUE才能得到指示说弟弟正在呼叫她，这样可以确信媒体会话可以真正的建立起来——11.6.4节。

•  各网元要交换计费信息，使媒体会话能够正确计费一一1.8节。

•  S-CSCF可以为服务对象用户发起高级的服务——11.3.8节。

•  最后TheresaUE开始振铃，并且Theresa会接受这个会话。会话建立阶段到此结束。

Tobias和Theresa完成呼叫后，他们将挂机，其中一人的UE将向对方发出BYE请求(见11.9.1节)。举例会话的SIP消息序列如图11-1所示。

图11-1IMS会话建立呼叫流程

11.2主叫和被叫标识

11.2.1概述

10.12节介绍了在注册过程中IMS用户如何得知他能用哪些公共用户标识,以及其中哪些标识是已经注册过的。随后，用户——在例子中是Theresa和Tobias——将把这些标识用于各种目的。在每种IMS对话中——本例中为INVITE对话——有两个标识是必须的：

•  请求中需要给出已注册并已认证的主叫用户(Tobias）的公共用户标识，以便归属网络识别出该用户，并且判断其对于扩展服务的执行权限。该标识位于INVITE请求的P-Asserted-Identity头中。

•  请求中需要给出已注册并已认证的被叫用户(Theresa）的公共用户标识,以便找到该用户并为其提供服务。该标识位于INVITE请求的请求URI(统一资源标识）以及第一个响应的P-Asserted-Identity头中。

11.2.2 From和To消息头

Tobias UE 发给Theresa的INVITE请求中包含以下与他们俩的标识有关的消息头：

INVITEsip:Theresa@home2.huSIP/2.0

From:"YourBrother"<sip:tobi@brother.com>;tag=veli

To:“MybelovedSister"<sip:Theresa@sister.com>

P-Preferrsd-Identity:<sip:tobias@homel.fr>

Privacy:None

显然，From和To消息头可以设置为发送者所希望的任何值。本例中选择我们以上词汇是为了清晰地说明：在除REGISTER之外的任何请求消息中，这两个消息头的值都丝毫不会影响IMS路由和安全过程，它们可以随意设置。在这两个消息头中，协议本身惟一需要的信息就是tag参数。

Tobias的归属网络可以对To消息头中可设置的内容进行一定的限制。这种情况下，如果From和To消息头中的值不符合运营商的策略，归属网络只能拒绝该请求，因为SIP不允许对这些头中的内容进行任何变更。

11.2.3主叫用户的标识：P-Preferred-1dentity和P-AssertedTdentity

11.2.3.1主叫UE包含的P-Preferred-Identity消息头

上例中，Tobias包含了一个可选的P-Preferred-Identity消息头。如果使用了该消息头，它应该包含该用户的一个已注册的公共用户标识。10.12.5节显示了Tobias是如何获知他可以使用的所有的公共用户标识。通过他终端所订阅的注册状态信息，他还可以知道这些用户标识中哪些目前已经注册过了。

如果Tobias希望对他姐姐完全隐藏自己的标识，他必须将Privacy头的值设为“id"。该值迫使Theresa的P-CSCF从INVITE请求中删除P-Asserted-Identity头，这样Theresa只能将From头中的标识作为主叫标识。

11.2.3.2主叫方P-CSCF包含的P-Asserted-Identity消息头

TobiasUE发出的INVITE请求首先将到达P-CSCF=P-CSCF检查该请求是否来自于一个有效的IPsecSAo如果收到的请求没有受到保护(即没有基于SA）,P-CSCF将拒绝它。

之后，P-CSCF在INVITE请求中添加一个P-Asserted-Identity头；并且如果INVITE请求中包含P-Preferred-Identity,则它会被P-Asserted-Identity头取而代之。在IMS对话中，P-Asserted-Identity头是惟一的、肯定包含了该用户已注册并已认证的公共用户标识的标识。

如果有P-Preferred-Identity头，P-CSCF会检查该消息头中的URI是否是发送方用户的一个当前已注册的公共用户标识。P-CSCF可以检查所订阅的注册状态信息，得知该公共用户标识是否已经注册(见10.12.6节）。它还可以根据某个请求是通过哪个SA发过来的，从而判断该请求是否来自某个特定用户(见10.7节）。如果这两项检查全部通过，P-CSCF就会用P-Asserted-Identity头来替代P-Preferred-Identity头，但内容是相同的。

如果P-Preferred-Identity头中不包含已注册的公共用户标识，P-CSCF就会删除该消息头。在这种情况下，或者在根本不存在P-Prefbrred-Identity头的情况下，P-CSCF都会添加一个P-Asserted-Identity,其内容为该用户缺省的公共用户标识。10.12.4节将介绍如何认定用户的缺省公共用户标识。

INVITE sip:Theresa@home2.huSIP/2.0

From:"YourBrother"<sip:tobi@brother.com>;tag=veli

To:"MybelovedSister"<sip:Theresa@sister.com>

P-Asserted-Identity:<sip:tobias@homel.fr>

Privacy:None

11.2.3.3主叫方S-CSCF与P-Asserted-Identity消息头

接收到INVITE请求后，Tobias归属网络的S-CSCF将根据P-Asserted-Identity头中的信息把他识别出来。S-CSCF还会针对该消息头中的公共用户标识，而检查其认证和注册状态。正是由于这些检查，这个消息头成为整个对话中识别该用户的主要标识。应用服务器AS(见11.3.8节）也可以依据这个消息头作为标识识别甚至认证的依据。

Tobias的S-CSCF可以在P-Asserted-Identity头中增加一个附加的URI-本例中它在消息头中增加了Tobias的电话统一资源定位符(telURL）：

INVITE sip:Theresa@home2,huSIP/2.0

From:“YourBrother"<sip:tobi@brother.com>;tag=veli

To:“MybelovedSister"<sip:Theresa@sister.com>

P-Asserted-Identity:<sip:tobias@homel.fr>,<tel:+44123456789>

Privacy:None

在Tobias归属网络S-CSCF将请求转发到Theresa的归属网络之前，它还要检查该网络是否位于其信任域(见3.842节）之内。如果该S-CSCF与Theresa的归属网络不处于相同的信任域，只要Privacy头设置为“id”，那么S-CSCF会从请求中删除P-Asserted-Identity头。在本例中，我们假设两个网络具有信任关系，该消息头可以继续发送。

11.2.3.4被叫方一侧的P-Asserted-Identity消息头

Theresa的P-CSCF需要检查请求中的Privacy头。如果它的值没有设置为“id”,P-CSCF就可以将P-Asserted-Identity头转发给TheresaUE。

至此，TheresaUE最终收到了P-Asserted-Identity头。它可以利用该消息头中的信息来显示其主叫方的“真实名称”。

11.2.4被叫用户标识

11.2.4.1请求URI

让我们再看一下Tobias发出的INVITE消息。其第一行，也就是请求URL如下所示：

INVITEsip:theresa@home2.huSIP/2.0

请求URI被设置为该请求的最终目的地(即Theresa的SIPURI）。11.3节将解释SIP和IMS路由过程如何使用该URIo然而，该URI同时还用于在Theresa的归属网络中标识她为被叫用户。这意味着Theresa的S-CSCF会检查这个公共用户标识目前是否已经完成注册并通过认证。如果Theresa现在还没有注册这个公共用户标识，S-CSCF将会对INVITE请求返回一个404(未发现）响应，宣布呼叫失败，或者将INVITE请求前转到Theresa的语音邮箱，这取决于对未注册用户设置的过滤规则。

在我们的例子中，假设Theresa已经注册了TobiasUE请求URI中的公共用户标识。

11.2.4.2请求URI和P-Called-Party-ID消息头

当TheresaS-CSCF将请求转发给被叫侧的P-CSCF时，产生了另一个问题：作为Theresa的SIP注册服务器，S-CSCF会用Theresa已注册的联系地址来覆盖请求URL以便将请求路由到Theresa目前注册的UE上。这样，请求URI中的公共用户标识将会丢失。

但是，Theresa可能有多个公共用户标识，她希望知道这个呼叫是发往其中的哪一个。例如，她可能有一个与工作有关的用户标识，其他的则与其私人生活有关。可能她的UE对于不同的用户标识会响起不同的振铃。

在11.2.2节中我们己经知道，Theresa不能信任请求中的To消息头，因为主叫方可以将其设置为任意值——甚至是与请求URI中的公共用户标识完全不同的内容。

为了不丢失Tobias呼叫姐姐时所使用的公共用户标识，S-CSCF在使用巳注册的联系地址覆盖请求URI的同时，还在INVITE请求中增加P-Called-Party-ID头。这个P-Called-Party-ID头中包含了请求URI中的那个公共用户标识：

INVITEsip:[5555::5:6:7:8:]:1006S1P/2.0

P-Called-Party-ID:sip:theresa@home2.hu

11.2.4.3P-Asserted-Identity消息头

收到INVITE请求后，TheresaUE在对INVITE请求的第一个响应183(会话进行中）响应中包含P-Preferred-Identity头，其中会包含Theresa的公共用户标识中的某一个。

SIP/2.0183SessioninProcess

From:"YourBrother"<sip:tobi@brother.com>;tag=veli

To:"MybelovedSister"<sip:Theresa@sister.com>;tag=schwester

P-Preferred-Identity:<sip:theresa@home2.hu>

Privacy:None

Theresa的P-CSCF会执行与前文TobiasP-CSCF所作的相同检查(见11.2.3节），并将P-Preferred-Identity头更换为P-Asserted-Identity头。

SIP/2.0183SessioninProcess

From:"YourBrother"<sip:tobi@brother.com>;tag=veli

To:”MybelovedSister"<sip:Theresa@sister.com>;tag=schwester

P-Asserted-Identity:<sip:theresa@home2.hu>

Privacy:None

11.2.5相关标准

与11.2节有关的规范有：

• RFC3323  APrivacy Machanism for the Session Initiation Protocol(SIP).

• RFC3325  Private Extensions to theSession Initiation Protocol(SIP)for

                  Asserted Identity within Trusted Networks.

• RFC3455  Private Header(P-Header)Extensions to the Session Initiation

                  Protocol(SIP)for the 3rd-Generation Partnership Project(3GPP).