Versions Compared

Old Version 9

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version 10

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Add_workflow_for_techpubsAUTH2AUTH1REV5REV6REV3REV1
Panel

In this section:

Table of Contents
maxLevel4

Info
iconfalse

Related articles:

 

Overview

The

Spacevars
0series4
supports P-Charging-Vector (PCV) headers as part of P-CSCF functionality. P-Charging-Vector is a collection of charging information, including a globally unique charging identifier (icid-value), that allows carriers to charge for access and services in a network by correlating charging records generated for an IMS by the various network entities involved in the session.

P-Charging-Vector flags:

  • createPChargingVector at IP Signaling Profile
  • storePChargingVector at IP Signaling Profile
  • pChargingVectorHeader transparency flag at IP Signaling Profile
  • interOperatorId flag at Trunk Group

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

A P-CSCF does not transparently pass a P-Charging-Vector header received from UE in any request to IMS core. P-CSCF creates a new P-Charging-Vector header for each request (REGISTER, INVITE, and OOD non-INVITE) containing a unique "icid-value" and "icid-generated-at" parameters and insert the same in the outgoing request towards the core.

The

Spacevars
0product
 retains the same "icid-value" (which is generated during the first egressed INVITE) during the Crankback/Redirected (3xx) call in the P-Charging-Vector header in an egressed INVITE. When the flag storeICID is enabled, all the CDRs (ATTEMPT/START/STOP) contains the same ICID value for Crankback/Redirected call in protocol specific string as well as in the original call records.

This is achieved by:

  • Disabling pChargingVectorHeader transparency flag at the IP Signaling Profile attached with the TG, towards the IMS Core side.
  • Enabling createPChargingVector flag at the IP Signaling Profile attached with the TG, towards the IMS Core side.
  • Disabling storePChargingVector flag at the IP Signaling Profile attached with the TG, towards the UE.

In addition, P-CSCF includes orig-IOI parameter in the newly-created PCV for REGISTER and INVITE messages. The value for orig-IOI parameter is configurable through InterOperatorID parameter from sipTrunkGroup object.

The

Spacevars
0product
acting as IBCF transparently passes the PCV received in any request from the P-CSCF to the IMS Core. Also, IBCF adds the stored PCV in the response to UE. This is achieved using the following configuration:

  • Enabling pChargingVectorHeader transparency flag in the IP Signaling Profile attached with the TG, towards the IMS Core side.
  • Disabling createPChargingVector flag in the IP Signaling Profile attached with the TG, towards the IMS Core side.
  • Enabling the storePChargingVector flag in the IP Signaling Profile attached with the TG, both towards the UE side and IMS Core side.

SBC Provisioning

When the P-Charging-Vector Header transparency option is selected in the IP Signaling Profile screen, the

Spacevars
0product
copies the P-Charging-Vector header as-is from the ingress message to the egress message. P-Charging-Vector header transparency is supported in INVITE and REGISTER requests.

When the Create P-Charging-Vector option is selected in the IP Signaling Profile screen, the

Spacevars
0product
 creates a new P-Charging-Vector header in the outgoing message. Creating P-Charging-Vector headers is supported in INVITE, REGISTER, SUBSCRIBE, OPTIONS, NOTIFY, REFER, MESSAGE and PUBLISH messages.

CDR Processing

The

Spacevars
0product
saves the P-Charging-Vector header with the "icid-value", "icid-generated-at values", and "access-network-charging-info" to the CDR in ingress and egress protocol specific variants fields. P-Charging-Vector headers received or created in INVITE messages are saved to the CDR; P-Charging-Vector header register requests are not saved to the CDR. This is controlled with the “storePChargingVector” flag provisioned from the IP Signaling Profile at ingress or egress side.

Note

If the

Spacevars
0product
receives the PCV when the storePChargingVector flag is disabled, the
Spacevars
0product
ignores the PCV and does not log the CDR.

The CLI syntax to enable/disable the createPChargingVector flag for P-CSCF and IBCF is shown below:

Code Block
languagenone
% set profiles signaling ipSignalingProfile <profile name towards core> commonIpAttributes flags createPChargingVector <enable | disable>

For populating interOperatorID parameter, use:

Code Block
languagenone
% set addressContext default zone defaultSigZone sipTrunkGroup <EGRESS_TG_NAME> signaling interOperatorID <interoperator ID for MGCF> 

The CLI syntax to enable/disable pChargingVectorHeader transparency flag for IBCF is shown below:

Code Block
languagenone
% set profiles signaling ipSignalingProfile <egress name> commonIpAttributes transparencyFlags pChargingVectorHeader <enable | disable> 

The CLI syntax to enable/disable the storePChargingVector flag for P-CSCF and IBCF is shown below:

Code Block
languagenone
% set profiles signaling ipSignalingProfile <profile name towards core> commonIpAttributes flags storePChargingVector <enable | disable> 

Transit-IOI Handling

A P-Charging-Vector header is used to correlate the charging records generated by different entities on the path of the call. To include the information of the transit carriers for charging purposes, The P-Charging-Vector header can also carry a new parameter transit-IOI, if the transit carriers are involved in a call. The Transit Inter Operator Identifier (Transit-IOI) is shared between sending, transit and receiving networks, service providers, or content providers. The transit-IOI header field parameter is an indexed value that is incremented each time a value is added. If P-Charging-Vector transparency is enabled or create/store P-Charging-Vector is enabled, the

Spacevars
0product
 transparently passes through Transit-IOI values received in P-Charging-Vector header.

Based on local policy, the

Spacevars
0product
 acting as entry or exit IBCF can also be configured to add Transit-IOI in the P-Charging-Vector header in the outgoing requests or responses. To achieve this behavior, Transit-IOI must be configured on the Trunk Group facing the transit network. However, the
Spacevars
0product
 does not support an explicit configuration for the removal of Transit-IOI values in outgoing messages. This can be achieved by using an appropriate SMM rule.

Div
classexcerptdiv
Excerpt

Use the transitIOI parameter located under SIP Trunk Group's signaling object to populate the specified value in the P-Charging-Vector header. This parameter must be configured on the Trunk Group facing the transit network and the configured value is inserted on the other leg in case of an egress message.

For configuration details, refer to:

 

Caption
0Figure
1 Transit-IOI Insertion in P-Charging-Vector Call Flow
3 Transit-IOI Insertion in P-Charging-Vector Call Flow

Pagebreak