Internet DRAFT - draft-henrikson-sip-charging-information
draft-henrikson-sip-charging-information
Internet Draft E. Henrikson
Document: draft-henrikson-sip-charging-information- Lucent
Expires: December 2002 Technologies
Category: Informational
June 2002
Private SIP Extension for Mobile Charging Information
draft-henrikson-sip-charging-information-05
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo describes a private extension to SIP in the form of
P-Charging-Function-Addresses and P-Charging-Vector headers. The
former header is used to pass the addresses of entities that
provide a charging function. The latter header is used to pass
charging correlation information. The affected UAs and proxies
associated with a dialog or standalone transaction need to know the
identities or addresses of the appropriate charging entities. They
also need to pass correlation information so that the records
generated and sent to the charging entities may be properly
associated for a coordinated billing effort.
Table of Contents
1. Background....................................................2
2. Discussion of Mechanism.......................................3
3. Applicability Statement.......................................3
4. Syntax and definition.........................................4
4.1 General......................................................4
Henrikson Expires - December 2002 [Page 1]
Private SIP Extension for Mobile Charging Information
June 2002
4.2 P-Charging-Function-Addresses................................4
4.3 P-Charging-Vector............................................5
5. Usage.........................................................6
5.1 Procedures at the UA.........................................6
5.2 Procedures at the Proxy......................................6
5.3 Procedures at the Back to Back UA............................7
5.4 Examples of Usage............................................7
6. Security Considerations.......................................8
7. IANA Considerations...........................................8
8. References....................................................9
8.1 Normative References.........................................9
8.2 Informative References.......................................9
9. Author's Addresses...........................................10
10. Acknowledgements............................................10
11. Full Copyright Statement....................................11
1. Background
Third Generation Partnership Project (3GPP) has selected SIP [1] as
the protocol to establish and tear down multimedia sessions in the
IP Multimedia Subsystem (IMS). A description of the IMS can be
found in 3GPP TS 23.228 [6] and 3GPP TS 24.229 [7].
3GPP has defined a distributed architecture that results in
multiple network entities becoming involved in providing access and
service. Operators need the ability and flexibility to charge for
the access and services as they see fit. This requires
coordination among the network entities, which includes correlating
charging records generated from different entities that are related
to the same session. There is a need to inform each network entity
involved about common charging functions to receive the generated
records.
The solution provided by 3GPP is to define two types of charging
functions: Charging Collection Function (CCF) and Event Charging
Function (ECF). CCF is used for off-line charging and ECF is used
for on-line charging. There may be a primary and secondary CCF and
ECF, for redundancy purposes. The CCF and ECF addresses may be
passed during the establishment of a dialog or standalone
transaction. The details are specified in the 3GPP documents, see
3GPP TS 32.200 [5].
Additionally, a charging vector is defined that may be filled in
during the establishment of a dialog or standalone transaction.
The information inside the charging vector may be filled in by
multiple network entities and retrieved by multiple network
entities. There are three types of correlation information to be
passed: IMS Charging ID (ICID), Inter Operator Identifiers (IOI)
Henrikson Expires - December 2002 [Page 2]
Private SIP Extension for Mobile Charging Information
June 2002
and access network charging information. ICID is a globally unique
value that may be used to correlate charging records. There may an
IOI generated from each side of the dialog to identify the network
associated with each side. There is also expected to be access
network charging information, which consists of network specific
identifiers for the access level (e.g. 3GPP radio access network or
IEEE 802.11b). The details of the information for each type of
network are not described in this memo.
2. Discussion of Mechanism
The provided mechanism uses private headers "P-Charging-Function-
Addresses" and "P-Charging-Vector" in either the initial request or
subsequent response for a dialog or standalone transaction. Only
one instance of each header is allowed in a particular request or
response.
The mechanisms by which an entity determines which values to
populate in the P-Charging-Function-Addresses and P-Charging-Vector
headers are specific to the local implementation and outside the
scope of this document.
3. Applicability Statement
The P-Charging-Function-Addresses and P-Charging-Vector headers are
applicable within a single private network where coordination of
charging is required. For example, according to the architecture
specified in 3GPP TS 32.200 [5]. The P-Charging-Vector header is
also applicable between private networks with a trust relationship.
The P-Charging-Function-Addresses header is not sent outside of a
private network. The P-Charging-Vector header is not sent to
another network if there is no trust relationship. Neither header
is applicable if the private network does not provide a charging
function or manages charging in a way that does not require
correlation of records from multiple network entities.
The P-Charging-Function-Addresses header is applicable whenever the
following circumstances are met:
1. A UAC sends a REGISTER or dialog initiating request (e.g.,
INVITE) or a standalone transaction request to a proxy in
a private network.
2. A registrar, proxy or B2BUA that is located in the private
network wants to generate charging records.
3. A registrar, proxy or B2BUA that is located in the private
network has access to the addresses of the charging
function entities for that network.
Henrikson Expires - December 2002 [Page 3]
Private SIP Extension for Mobile Charging Information
June 2002
The P-Charging-Vector header is applicable whenever the following
circumstances are met:
1. A UAC sends a REGISTER or dialog initiating request (e.g.,
INVITE) or a standalone transaction request to a proxy in
a private network.
2. A registrar, proxy or B2BUA that is located in the private
network wants to generate charging records.
3. A proxy or B2BUA that is located in the private network
has access to the charging correlation information for
that network.
4. Optionally, a registrar, proxy or B2BUA that is part of
the dialog or standalone transaction and is located in
another private network wants to generate charging records
and correlate the records with the other private network.
4. Syntax and definition
4.1 General
All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) defined in RFC
2234 [2]. Further, the BNF definitions from RFC 3261 [1] are
inherited for the P-Charging-Function-Addresses and P-Charging-
Vector headers and are not repeated here. Implementers need to be
familiar with the notation and content of RFC 3261 [2] and RFC 2234
[2] to understand this document.
4.2 P-Charging-Function-Addresses
The syntax for the P-Charging-Function-Addresses header is:
p-charging-addr = "P-Charging-Function-Addresses" HCOLON
charge-addr-params *(SEMI charge-addr-params)
charge-addr-params = ccf1 / ccf2 / ecf1 / ecf2 / generic-param
ccf1 = "ccf1" EQUAL gen-value
ccf2 = "ccf2" EQUAL gen-value
ecf1 = "ecf1" EQUAL gen-value
ecf2 = "ecf2" EQUAL gen-value
Example:
P-Charging-Function-Addresses: ccf1=135.18.232.565;
ccf2=135.18.232.766
A P-Charging-Function-Addresses header may be inserted into a
request or response by any SIP node traversed by that message.
However, there may only be one instance of a P-Charging-Function-
Henrikson Expires - December 2002 [Page 4]
Private SIP Extension for Mobile Charging Information
June 2002
Addresses in a SIP message. Further, a particular instance of P-
Charging-Function-Addresses shall always contain the ccf1 parameter
and may contain one instance of each of the other parameters: ccf2,
ecf1 and ecf2.
The allowable usage of headers is described in Table 2 of SIP [1].
Addition of P-Charging-Function-Addresses to the Table 2 in SIP
[1], section 4.1 of the SIP-specific event notification [8], tables
1 and 2 in the SIP INFO method [9], tables 1 and 2 in Reliability
of provisional responses in SIP [10], tables 1 and 2 in the SIP
UPDATE method [11], tables 1 and 2 in the SIP extension for Instant
Messaging [12] and table 1 in the SIP REFER method [13]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Charging-Function-Addresses ard - o - o o o
Header field SUB NOT PRA INF UPD MES REF
_______________________________________________________________
P-Charging-Function-Addresses o o o o o o o
4.3 P-Charging-Vector
The syntax for the P-Charging-Vector header is:
p-charging-vector = "P-Charging-Vector" HCOLON charge-params
*(SEMI charge-params)
charge-params = icid / orig-ioi / term-ioi / generic-param
icid = "icid" EQUAL gen-value
orig-ioi = "orig-ioi" EQUAL gen-value
term-ioi = "term-ioi" EQUAL gen-value
Example:
P-Charging-Vector: icid=1234bc9876e;orig-ioi=ACCESSDOMAIN
A P-Charging-Vector header may be inserted into a request or
response by any SIP node traversed by that message. However, there
may only be one instance of a P-Charging-Vector in a SIP message.
Further, a particular instance of P-Charging-Vector shall always
contain the icid parameter and may contain one instance of each of
the other parameters: orig-ioi and term-ioi. Lastly, it is
expected that there will be network specific information included
in the extension parameter generic-param.
The allowable usage of headers is described in Table 2 of SIP [1].
Addition of P-Charging-Vector to the Table 2 in SIP [1], section
4.1 of the SIP-specific event notification [8], tables 1 and 2 in
Henrikson Expires - December 2002 [Page 5]
Private SIP Extension for Mobile Charging Information
June 2002
the SIP INFO method [9], tables 1 and 2 in Reliability of
provisional responses in SIP [10], tables 1 and 2 in the SIP UPDATE
method [11], tables 1 and 2 in the SIP extension for Instant
Messaging [12] and table 1 in the SIP REFER method [13]:
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
P-Charging-Vector ardm - o - o o o
Header field SUB NOT PRA INF UPD MES REF
_______________________________________________________________
P-Charging-Vector o o o o o o o
5. Usage
5.1 Procedures at the UA
The UAC and UAS (originating and terminating UA) behave as usual.
They are not required to understand the P-Charging-Function-
Addresses header, but MAY retrieve the information if received.
The UAC and UAS (originating and terminating UA) behave as usual.
They are not required to understand the P-Charging-Vector header,
but MAY retrieve the information if received.
5.2 Procedures at the Proxy
The P-Charging-Function-Addresses and P-Charging-Vector headers are
treated like any other unknown header by intermediate proxies.
They simply forward it on towards the destination.
If a proxy that supports this extension receives a request or
response without the P-Charging-Function-Addresses or P-Charging-
Vector header, it MAY insert a P-Charging-Function-Addresses or P-
Charging-Vector header prior to forwarding the message.
If a proxy that supports this extension receives a request or
response with the P-Charging-Function-Addresses or P-Charging-
Vector header, it MAY retrieve the information from the header to
use with application specific logic, i.e. charging. The proxy
SHOULD retain the P-Charging-Function-Addresses and P-Charging-
Vector header in the outbound message. Per local application
specific logic, the proxy MAY modify the contents of the P-
Charging-Vector header prior to sending the message. If the next
hop for the message is outside the closed network of the proxy,
then the proxy MUST remove the P-Charging-Function-Addresses header
and MAY remove the P-Charging-Vector header from the message.
Henrikson Expires - December 2002 [Page 6]
Private SIP Extension for Mobile Charging Information
June 2002
5.3 Procedures at the Back to Back UA
If a B2BUA that supports this extension receives a request or
response without the P-Charging-Function-Addresses or P-Charging-
Vector header, it MAY insert a P-Charging-Function-Addresses or P-
Charging-Vector header prior to forwarding the message.
If a B2BUA that supports this extension receives a request/response
with the P-Charging-Function-Addresses or P-Charging-Vector header,
the B2BUA SHOULD copy the headers from the receiving side UA to the
sending side UA. Per local application specific logic, the B2BUA
MAY modify the contents of the P-Charging-Vector header prior to
sending the message.
5.4 Examples of Usage
We present example in the context of the scenario presented in the
Background section earlier in this document. The network diagram
is replicated below:
Scenario
UA1----P1-----P2-----UA2
This example shows the message sequence for an INVITE transaction
originating from UA1 eventually arriving at UA2. P1 is an outbound
proxy for UA1. In this case P1 also inserts charging information.
P1 then routes the call via P2 to UA2.
Message sequence for INVITE using P-Charging-Function-Addresses and
P-Charging-Vector:
F1 INVITE UA1 -> P1
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
. . .
Henrikson Expires - December 2002 [Page 7]
Private SIP Extension for Mobile Charging Information
June 2002
F2 INVITE P1 -> P2
INVITE sip:joe SIP/2.0
Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04
Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7
To: Joe <sip:joe>
From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 18 INVITE
Contact: <sip:UA@192.0.2.4>
P-Charging-Function-Addresses: ccf1=135.18.232.565;
ccf2=135.18.232.766
P-Charging-Vector: icid=1234bc9876e;orig-ioi=ACCESSDOMAIN
. . .
6. Security Considerations
It is expected as normal behavior that proxies and B2BUAs within a
closed network will modify the values of P-Charging-Function-
Addresses and P-Charging-Vector and to insert these headers into a
request for a dialog, e.g. INVITE request (or other request or
response). However, these proxies and B2BUAs that share this
information SHOULD have a trust relationship.
If an untrusted entity got inserted between trusted entities, it
could potentially interfere with the charging correlation mechanism
or substitute a different charging function address. Therefore, an
integrity protection mechanism such as IPsec or other available
mechanisms SHOULD be applied in order to prevent such attacks.
Since each trusted proxy or B2BUA may need to view or modify the
values in the P-Charging-Function-Addresses and P-Charging-Vector
headers, the protection should be applied on a hop-by-hop basis.
7. IANA Considerations
This document defines the SIP extension headers "P-Charging-
Function-Addresses" and "P-Charging-Vector" which should be
included in the registry of SIP headers defined in SIP [1]. As
required by the SIP change process draft-tsvarea-sipchange [4] the
SIP extension header name "Charging-Function-Addresses" and
"Charging-Vector" should also be registered in association with
this extension.
The following is the registration for the P-Charging-Function-
Addresses header field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC
number of this specification.]
Header Field Name: P-Charging-Function-Addresses
Henrikson Expires - December 2002 [Page 8]
Private SIP Extension for Mobile Charging Information
June 2002
Compact Form: none
The following is the registration for the Charging-Function-
Addresses header field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC
number of this specification.] (not yet specified,
only reserved)
Header Field Name: Charging-Function-Addresses
Compact Form: none
The following is the registration for the P-Charging-Vector header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC
number of this specification.]
Header Field Name: P-Charging-Vector
Compact Form: none
The following is the registration for the Charging-Vector header
field:
RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC
number of this specification.] (not yet specified,
only reserved)
Header Field Name: Charging-Vector
Compact Form: none
8. References
8.1 Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session
Initiation Protocol, RFC 3261", March 2002.
[2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax
specifications: ABNF," RFC 2234, Internet Engineering Task Force,
November 1997.
8.2 Informative References
[3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia-
sipping-3gpp-reqs-03.txt", March 2002.
[4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange",
March 2002.
Henrikson Expires - December 2002 [Page 9]
Private SIP Extension for Mobile Charging Information
June 2002
[5] 3GPP TS 32.200, Version 5, "Telecommunication Management;
Charging management; Charging principles".
[6] 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) -
Release 5".
[7] 3GPP TS 24.229 "IP Multimedia Subsystem (IMS) (Stage 3) -
Release 5".
[8] A. Roach, SIP-Specific Event Notification, RFC 3265, March
2002.
[9] S. Donovan, The SIP INFO method, RFC 2976, October 2000.
[10] J. Rosenberg, H. Schulzrinne, Reliability of Provisional
Responses in SIP, RFC 3262, March 2002.
[11] J. Rosenberg, The Session Initiation Protocol UPDATE Method,
draft-ietf-sip-update-02.txt, April 2002, work in progress.
[12] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D.
Gurle, Session Initiation Protocol Extension for Instant Messaging,
draft-ietf-sip-message-04, May 2002, work in progress.
[13] R. Sparks, The REFER method, draft-ietf-sip-refer-04.txt, May
2002, work in progress.
9. Author's Addresses
Eric Henrikson
Lucent Technologies
11601 Willows Rd
Suite 100
Redmond, WA 98052
US
Phone: +1 425 497 2442
EMail: ehenrikson@lucent.com
URI: http://www.lucent.com/
10. Acknowledgements
The author would like to thank Keith Drage, Miguel Garcia, Dean
Willis, Rohan Mahy and the 3GPP CN1 Working Group members for their
valuable comments on this document.
Henrikson Expires - December 2002 [Page 10]
Private SIP Extension for Mobile Charging Information
June 2002
11. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Henrikson Expires - December 2002 [Page 11]
