1. Accounting Guide
  2. CDR Attribute Reference
  3. Oracle RADIUS Acme-Extended-Attributes VSAs
  4. VoLTE and SMS VSAs
  5. Including P-Visited Network Identifier and History-Info Headers in CDRs

Including P-Visited Network Identifier and History-Info Headers in CDRs

You can configure the SBC to add fully compliant P-Visited Network Identifier (PVNI) and History-Info (HI) headers in CDRs. You configure this by adding the pcscf-cdr-compliance option to the account-config, specifying whether you want to include PVNI (PVNI-pref), HI (HI-pref), or both. The behavior is dependent on the type of call, including Mobile Terminating (MT) and Mobile Originating (MO), information provided by SIP, and whether you are also using an S8HR profile.

The PVNI and HI fields in CDRs may or may not contain data. When configured, the SBC performs processes to determine whether or not to add:

  • P-Visited-Network-ID to the applicable CDR field
  • History-Info to the applicable CDR field

You configure the pcscf-cdr-compliance in the applicable account-config to use these processes within your environment. 

ORACLE# configure terminal
ORACLE(configure)# session-router
ORACLE(session-router)# account-config
ORACLE(account-config)# select
ORACLE(account-config)# options +pcscf-cdr-compliance=PVNI-pref

If you save and activate this configuration, the SBC enables PVNI CDR population for MT calls. To configure for both PVNI and HI headers, configure the option with both values separated by a comma and enclosed in quotes. 

ORACLE(account-config)# options +pcscf-cdr-compliance="PVNI-pref,HI-pref"

Support for P-Visited-Network-ID Field

For MT calls, the access SBC, deployed as an A-SBC, inserts the PVNI header in CDRs based on the called party registration cache entry (MCC/MNC). If the Called party registration cache does not have a PVNI value, the A-SBC inserts the network-id value from the access side (egress realm) sip-interface configuration as the PVNI into CDRs.

For both MO and MT and when you configure it to add PVNI to CDRs, the A-SBC checks for an s8hr-profile in the same interface:

  • If there is an S8HR profile on the access sip-interface:
    • If the SBC receives an MCC/MNC from the Rx server, it creates the PVNI header using the called party registration cache entry (MCC/MNC) and adds it to the CDR.
    • If the SBC does not receive an MCC/MNC, It checks whether there is a network-id value on the access side sip-interface:
      1. If so, the SBC creates the PVNI using that network-id value.
      2. If not, the SBC uses the local-mccmnc value as the PVNI, and adds it to CDR.

        Note:

        If you have not configured the local-mccmnc value in your S8HR profile, the SBC uses the default, which is 999999.
  • If there is not an S8HR profile on the access sip-interface, the SBC checks whether there is a network-id value on the access side sip-interface. If so, the SBC uses the network-id value as the PVNI, and adds it to CDR.
  • If both the S8HR and the egress (access) network-id are not configured, the SBC checks whether the initial INVITE/MESSAGE comes from a trusted endpoint and contains a PVNI:
    • If so, the SBC relays the PVNI and add to CDR.
    • If not, the SBC leaves the PVNI field empty.

When you have set the pcscf-cdr-compliance option to include PVNI, and the SBC is acting as an I-SBC handling MO/MT calls, the SBC uses the following sequence for populating the CDR field:

  1. If configured, uses the network-id on the ingress sip-interface as PVNI.
  2. If populated and from a trusted endpoint, uses the PVNI from the initial INVITE.
  3. Leaves the PVNI field empty.

Note:

This behavior applies to the INVITE or any Re-INVITE.

Support for History-Info Field

For MO calls, if you have configured the HI option in the account-config, SBC uses the History-Info(s) received in the initial INVITE replies, including those with 181, 180 or 200 status-codes. The SBC populates the CDR with the last provisional (>100) or final (200) response containing History-Info(s). If History-Info is not available in provisional or final replies, the SBC leaves the History-Info in the CDR empty.

For MT calls, SBC extracts History-Info header(s) from the initial INVITE and adds them to the CDR. If History-Info is not available in the initial INVITE, the SBC leaves the HI field empty.

If there are multiple History-Info headers in the initial INVITE, the SBC concatenates all the history-info headers values, and without exceeding the default or configured CDR field size, adds them to the CDR.

For example, assume INVITE has three History-Info headers in the following order:
  1. HI-1 - 100 characters
  2. HI-2 - 100 characters
  3. HI-3 - 100 characters

By default, the maximum CDR field size is 246. In this case, the SBC includes the first two History-Info headers in their entirety, and truncates HI-3.

Consider the presence of the following HI headers:

  • History-Info: <sip:bob@example.com>;index=1
  • History-Info: <sip:office@example.com>;index=1.2;mp=1
  • History-Info: <sip:office@192.0.2.5>;index=1.2.1;rc=1.2

The SBC populates the History-Info CDR as follows 

<sip:bob@example.com>;index=1, <sip:office@example.com>;index=1.2;mp=1, <sip:office@192.0.2.5>;index= 1.2.1;rc=1.2