The SBC Core 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.
createPChargingVectorat IP Signaling Profile
storePChargingVectorat IP Signaling Profile
pChargingVectorHeadertransparency flag at IP Signaling Profile
interOperatorIdflag at Trunk Group
The Transparency Profile is the recommended method of configuring transparency on the SBC Core for new deployments as well as when applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.
Refer to the SBC SIP Transparency Implementation Guide for additional information.
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 SBC 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:
pChargingVectorHeadertransparency flag at the IP Signaling Profile attached with the TG, towards the IMS Core side.
createPChargingVectorflag at the IP Signaling Profile attached with the TG, towards the IMS Core side.
storePChargingVectorflag 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
The SBC 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:
pChargingVectorHeadertransparency flag in the IP Signaling Profile attached with the TG, towards the IMS Core side.
createPChargingVectorflag in the IP Signaling Profile attached with the TG, towards the IMS Core side.
- Enabling the
storePChargingVectorflag in the IP Signaling Profile attached with the TG, both towards the UE side and IMS Core side.
The SBC adds a P-Charging-Vector header with the Note The
termIOI parameter to the 18x response sent to the ingress network. The
termIOI parameter sends the terminating networking identifier to the ingress network. The SBC creates and sends the
termIOI parameter when there is no egress network, which occurs when the call is terminated in the script. When there is an egress network, the
termIOI parameter is received from the egress network.
termIOI parameter is configured in the Signaling SIP Trunk Group.
The SBC adds a P-Charging-Vector header with the
When the P-Charging-Vector Header transparency option is selected in the IP Signaling Profile screen, the SBC 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 SBC 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.
The SBC 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.
If the SBC receives the PCV when the
storePChargingVector flag is disabled, the SBC 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:
interOperatorID parameter, use:
The CLI syntax to enable/disable
pChargingVectorHeader transparency flag for IBCF is shown below:
The CLI syntax to enable/disable the
storePChargingVector flag for P-CSCF and IBCF is shown below:
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 SBC transparently passes through Transit-IOI values received in P-Charging-Vector header.
Based on local policy, the SBC 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 SBC 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.
For configuration details, refer to: