会话的计费相关信息

11.8.1概述

GPRS接入网中，计费基础通常是PDP上下文中传输的数据量。网络运营商可以决定对于特定的PDP上下文采取不同的计费，例如一条MMS可能与“正常”的因特网流量采取不同的计费方式。运营商很可能希望对IMS相关的信令和媒体流量采取不同的计费方式，不同于基于传送数据量的计费。为此,IMS需要将GPRS特定的计费记录与IMS特定的计费信息关联起来。

TobiasUE与GGSN之间需要为媒体会话建立多个媒体PDP上下文。任何时候当这些PDP上下文中有数据(即媒体)传输时，GGSN就开始生成计费记录。这些计费记录是基于接入网络生成的GPRS计费ID(GCID)。

在10.11节中已经介绍，IMS计费ID(ICID)是在初始注册时由P-CSCF生成的。在会话中，P-CSCF还会生成一个附加的ICID,用于对由已建立媒体PDP上下文传输的媒体流进行计费。

GGSN将这些媒体PDP上下文的GCID通过Go接口发给P-CSCF,P-CSCF生成一个ICID并把它发往用户的归属网络。

这些过程在Tobias和Theresa双方都会发生。各自归属网络的计费实体将决定他们是如何计费的。

用户的S-CSCF会进一步在各自的归属网络中分配计费采集功能(CCF)和事件计费功能(ECF).的地址，这些功能单元会采集两个用户的计费记录。所有为会话生成计费记录的实体都需要这个信息。

11.8.2 为媒体会话交换 ICID

当Tobias的P-CSCF收到会话的INVITE请求时，它会生成一个新的ICID,并将其填入P-Charging-Vector消息头，该消息头将添加到INVITE请求中。

INVITEsip:theresa@home2.hu.SIP/2.0

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551025”

Tobias的S-CSCF会在P-Charging-Vector消息头中添加发起方的跨运营商标识（101）。101参数用作实现计费的目的、面向Theresa归属网络的Tobias归属网络的标识，它通常设置为用户的归属域。

INVITEsip:theresa@home2.hu SIP/2.0

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551025"

;orig-ioi=homel.fr

Theresa归属网络的S-CSCF把orig-ioi参数保存下来，并将其从P-Charging-Vector消息头中删除。

P-Charging-Vector消息头将随INVITE请求进一步转发，直到到达Theresa的P-CSCF处。在这里，该消息头将被删除。与计费有关的消息头永远不会发给UE。沿途与本次会话的计费相关的所有实体都会把ICID保存下来。

当收到对INVITE请求的第一个响应即183（会话进行中）响应时，Theresa的P-CSCF会将P-Charging-Vector头再次插入进来，包含的ICID值与INVITE请求中的相同。

SIP/2.0 183 Session in Progress

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551025"

TheresaS-CSCF将会在响应中添加终结方的IOI信息，再进一步转发：

SIP/2.0 183 Session in Progress

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551025"

;term-ioi=home2.hu

终结方的IOI信息也会在Tobias的S-CSCF处存储并从消息中删除，他的P-CSCF也会将P-Charging-Vector从响应中删除。

11.8.3 GCID和ICID间的关联

在资源预留成功之后，Tobias侧就可以建立起媒体PDP上下文。这时，如11.6节所述，Tobias UE会立刻向Theresa发出UPDATE请求。由于这是TobiasP-CSCF在媒体PDP上下文建立之后收到的第一个请求，因此它会在UPDATE请求中添加

P-Charging-Vector头，包含以下信息：

•为这个媒体会话创建的ICID。

•本会话所建立的每个媒体PDP上下文的计费参数：

■从GGSN处得到的GCID；

■相关GGSN的地址；

■标志(“pdp-sig”)，用于指示相关PDP上下文是否是信令PDP上下文(本例中不是信令PDP上下文)；

■媒体流中的流标识符；

■用于媒体授权的令牌(auth・token)(见11.7.2节)。

UP DATE请求如下所示：

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

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024”

;ggsn=[5555::4b4:3c3:2d2:lel];

;pdp-sig=nO;gcid=723084371

;auth-token=example-auth-token1

;flow-id=l

；ggsn=[5S55::4b4:3c3:2d2:lel]

;pdp-sig=no;gcid=723084372

;auth-token=example-auth-tokenl

;flow-id=2

在11.7.3节中我们了解到，Tobias建立了两个媒体PDP±下文，因此这里有两个计费参数列表。

Tobias的S-CSCF将保存P-Charging-Vector中的所有信息并将其从消息中删除，同时添加发起方和终结方的IOI参数，然后再将UPDATE请求发往Theresa的S.CSCF。

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

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024”

;orig-ioi=homel.fr

;term-ioi=home2.hu

同样地，Theresa的S-CSCF会删除这两个参数（orig-ioi和term-ioi）,然后再把UPDATE请求发往P-CSCF；而P-CSCF会删除这个消息头，然后再把请求发往TheresaUE。

在我们的例子中，Theresa UE在收到来自Tobias侧的UPDATE请求时，早已经完成了资源预留（见11.6.4.4节）。因此，Theresa的P-CSCF在对UPDATE请求的200（OK）响应中再次添加P-Charging-Vector头，这次包含了与已预留的媒体PDP上下文有关的所有信息。

SIP/2.0200 OK

P-Charging-Vector:icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"

;ggsn=[5555::802:53:58:6]

;pdp-sig=no

;gcid=306908949

;auth-token-example-auth-token2

;flow-id=2

由于Theresa只建立了一个媒体PDP上下文（见11.7.3节），她的P-CSCF仅包括一个计费参数列表。

现在，双方的S-CSCF都执行与以前同样的动作，即：

•Theresa的S-CSCF从P-Charging-Vector头中删除与PDP上下文有关的信息，并添加已保存的orig-ioi和term-ioi两个参数。

•Tobias的S-CSCF会删除orig-ioi和term-ioi两个参数。

•最后，Tobias的P-CSCF将删除P-Charging-Vector头，再把200（OK）响应发给UE。

11.8.4 计费功能地址的分配

CCF和ECF的地址会在S-CSCF的归属网络中分配。

每个S-CSCF都会在INVITE请求中加入P-Charging-Function-Address消息头,它将随INVUTE请求路由转发直到归属网络的边界。归属网络边界处的CSCF会删除这个消息头。

以Tobias的归属网络为例，这意味着他的S-CSCF：

• 在首次收到INVITE请求时，在其中添加P-Charging-Function-Address消息头，并把它发给所有位于归属网络的、Tobias用户配置的过滤规则所包含的AS（见11.3.8节）。由于该S-CSCF就是Tobias归属网络中最后一个实体，因此它在将消息发往Theresa归属网络之前，会把P-Charging-Function-Address消息头删除。

• 在收到183（会话进行中）响应时，再次添加P-Charging-Function-Address消息头，再次发给所有位于归属网络的、Tobias用户数据的过滤规则所包含的AS,并删除消息头，再把响应发往位于拜访网络中的P-CSCF。

Tobias拜访网络中的P-CSCF需要通过其他方式发现它本地的计费功能服务器的地址。

另一方面，Theresa的S-CSCF则会

• 如同上面所述，在收到INVITE请求时，在其中添加P-Charging-Function-Address消息头并把它发给AS。但是，这里S-CSCF把请求发给P-CSCF之前并不把消息头删除，因为Theresa的P-CSCF位于她的归属网络中。她使用了GPRS漫游而不是IMS漫游来接入她的归属网络的P-CSCF(见9.1节)，因此P-Charging-Function-Address消息头将由P-CSCF从INVITE请求中删除。

• 在收到183(会话进行中)响应时，再次添加P-Charging-Function-Address消息头，再次随响应消息进行发送。然而，这次该消息头由Theresa归属网络的I-CSCF删除，I-CSCF也会收到这个响应。

Tobias的S-CSCF在初始INVITE请求中添加的P-Charging-Function-Address消息头如下所示：

INVITE sip:theresa@home2.huSIP2.0

P-Charging-Function-Addresses:ccf=[5555::b99:c88:d77:e66]

;ccf45555::a55:b44:c33:d22]

11.8.5相关标准

与计费过程有关的IMS专用SIP消息头的规范参见：

[RFC3455]Private Header(P-Header) Extension to the Session Initiation Protocol(SIP)for the 3rd-Generation Partnership Project(3GPP)