Skip to end of metadata
Go to start of metadata

In this section:

Overview

This document describes support of Rf interface on SBC as IMS Network elements P-CSCF and IBCF.

The first phase of Rf Interface support was implemented in 4.2.0 release for INVITE or Session-related charging records. This release extends Rf functionality to support reporting Non-Session related offline charging events, including the following:

  • Subscription – Initial Subscribe, un-Subscribe, un-Subscribe using Notify, Administratively unsubscribe using CLI/EMA
  • Registration – Initial Register, de-register, de-register using notify, Administratively De-register using CLI/EMA
  • Sessions – ACR (START/STOP/INTERIM/EVENT) for session setup, tear-down, long duration calls and failed calls respectively.
  • Out-of-dialog Notify relay–Event record is generated
  • Out-of-dialog Message relay
  • Out-of-dialog Publish relay
  • Out-of-dialog Option relay
  • Out-of-Dialog REFER relay

IMS network elements share the charging information with each other using SIP header fields. SIP headers "P-charging-Vector" and "P-charging-Function-Address" as defined in RFC 3455 are used to transfer the charging information among IMS core network elements.

IMS network elements (S-CSCF, P-CSCF, I-CSCF, BGCF, IBCF, and MGCF) apply off-line charging through the Rf interface using the CDF address as received via SIP signaling or the locally configured CDF address in the IMS network element.

The charging architecture implementing Diameter adheres to the structure where all communications for off-line charging purposes between the CTF (Diameter client) and the CDF (Diameter server) are carried out on the Diameter Rf reference point, where the CTF reports charging information to the Charging Data Function (CDF). The CDF uses this information to construct and format CDRs.

3GPP Logical Off-line Charging Architecture

The Rf reference point from the Charging Trigger Function (CTF) to the Charging Data Function (CDF) is intended for the transport of off-line charging events. The following figure depicts the position of the Rf within the overall 3rd Generation Partnership Project (3GPP) charging architecture.

Figure : 3GPP Network Architecture

Key

CTF: Charging Trigger Function

CDF: Charging Data Function

CGF: Charging Gateway Function

BD: Billing Domain. This may also be a billing mediation device/post-processing system.

The SBC Core supports the following Rf Interface functionality:

  • Rf interface-based offline billing either as IBCF or P-CSCF, which is compliant with standard IMS along with the file based and stream based CDR.
  • A system-wide flag to select either CDR/streaming-based charging or Rf-interface based charging.
  • Base diameter towards Rf Interface.
  • Diameter node support of Rf application along with the existing Rx application. The Diameter node uses "Route Table" to find peer for outbound request based on destination realm and application.

Rf Interface is configured with the following steps:

  1. Configure Diameter Node–Configure Diameter host configuration (SBC) stating primary and secondary origin host, plus IP Interface Group and the IP Address used by the Node to create connections towards peer.

    % set addressContext <addressContextName> diamNode <diamNodeName> primaryOriginHost <primaryOriginHostName> secondaryOriginHost <secondaryOriginHostName> ipV4Address <ipV4AddressName> ipV6Address <ipV6AddressName> originRealm <originRealmName> transactionTimeout <timeOut> ipInterfaceGroupName <ipInterfaceGroupName>
  2. Configure Diameter peers–Rf servers that are used as CDF are configured as Diameter Peers, including IP address, FQDN name, and TCP port.

     % set addressContext <addressContextName> diamNode <diamNodeName> peer <peerName> fqdn <fqdn Name> ipAddress <ipAddress> tcpPort <tcpPortName> state enabled
  3. Configure Realm routes for this Diameter Node–Identify the Realm FQDN of this route and the Peer to which the Realm belongs.

    % set addressContext <addressContextName> diamNode <diamNodeName> realmRoute <realmRoute> realm <RealmFqdn> peer <peerName> state enabled

Use the global signaling Diam Sig Controls object to configure global diameter signaling controls such as enabling the Rf Accounting application at the system level to send accounting information over Rf Interface. See Signaling - CLI for configuration details.

Charging Trigger Function

The Charging Trigger Function (CTF) generates charging events based on the observation of network resource usage. In every network and service element that provides charging information, the CTF is the focal point for collecting the information pertaining to chargeable events within the network element, assembling this information into matching charging events, and sending these charging events towards the Charging Data Function. The CTF is therefore a mandatory, integrated component in all network elements that provide off-line charging functionality.

CTF is comprised of two functional blocks:

Accounting Metrics Collection

This process exhibits the following behavior:

  • Monitors signaling functions for calls, service events or sessions established by the network users
  • Handles user traffic for these calls, service events or sessions
  • Service delivery to the user via these calls, service events or sessions.

Metrics are included to identify the user and the user's consumption of network resources and/or services in real-time. The exact behavior and functionality of this process involves following depending upon functions / services that the NE provides. The Account Metrics Collection can therefore be considered as the network element dependent part of the CTF.

  • trigger conditions for collection of charging information,
  • information elements to collect,
  • which service events, signaling or user traffic to monitor,
  • relationship to services/bearers/sessions.

Depending on implementation choice, NE functions (for example, the handling of service events or signaling/user traffic) are distributed among multiple physical “devices” within the NE. To capture the required charging information from the service events or signaling/user traffic, the design of the Accounting Metrics Collection must match the physical design / distribution of these functions within the NE (In other words, the Accounting Metrics Collection becomes a distributed functionality itself).

Accounting Data Forwarding

This process receives the collected accounting metrics and determines the occurrence of chargeable events from a set of one or more of these metrics. It then assembles charging events that match the detected chargeable events, and forwards the charging events towards the Charging Data Function via the Rf reference point. The charging events provide information pertinent to the chargeable event, that is, characterizing the network resource usage together with an identification of the involved user(s). There is no assumption of any synchronization between the reception of individual accounting metrics; however, it must be possible for the Accounting Data Forwarding to complete its overall functionality per charging event in real-time.

While the exact information received by the Account Data Forwarding from the Account Metrics Collection, and the relevant chargeable events, are specific to each type of network element, the overall functionality of receiving, assembling and forwarding the charging information can be considered generic. Hence the Accounting Data Forwarding is considered the NE independent part of the CTF.

Charging Data Function

The Charging Data Function (CDF) receives charging events from the Charging Trigger Function via the Rf reference point. It then uses the information contained in the charging events to construct CDRs. This procedure is characterized by the following conditions:

  • CDRs may be constructed from single charging events, that is, a 1:1 relation between event and CDR.
  • CDRs may be constructed from a set of several charging events, that is, a n:1 relation between event and CDR.
  • Each charging event is used for exactly one CDR, that is, a 1:n relationship between event and CDR (with n>1) is not possible.
  • Multiple charging events that are used to create a single CDR may not necessarily be of the same type.
  • There is no requirement or assumption of any synchronization between the reception of the charging event(s) and the creation of the resulting CDR. However, the CDF is capable of receiving and processing charging events and generating the resulting CDR in near real-time.
  • The relationship between CDF and CTF may be 1:1 (integrated CDF) or 1:n (separated CDF). This includes the possibility of NEs of different types feeding charging events into the same CDF.
  • All charging events used to build a CDR must originate from the same NE, that is, there is no cross-NE or cross-NE-type correlation of charging events in the CDF.

The results of the CDF tasks are charging data records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain / subsystem / service in the related middle tier charging specifications.

Charging Gateway Function

The CDRs produced by the CDF are transferred immediately to the Charging Gateway Function (CGF) via the Ga reference point. The CGF acts as a gateway between the 3GPP network and the Billing Domain. It uses the Bx reference point for the transfer of CDR files to the BD. The entity relationship between the CDF and the CGF is m:1, that is, one or more CDFs may feed CDRs into a single CGF. The CGF comprises the following main functions:

  • CDR reception from the CDF via the Ga reference point in near real-time. The protocols that may cross the Ga reference point are specified in 3GPP TS 32.295 [54].
  • CDR preprocessing:
    • Validation, Consolidation and (Re-) Formatting of CDRs.
    • CDR error handling.
    • Persistent CDR storage.
  • CDR routing and filtering, that is, storing CDRs on separate files based on filtering criteria such as CDR type, CDR parameters, originating CDF, and so on.
  • CDR File Management, for example, file creation, file opening / closure triggers, file deletion.
  • CDR file transfer to the BD.

Offline Charging Functionality

Off-line charging functionality is based on the network elements reporting accounting information upon reception of various messages which trigger charging generation, as most of the accounting relevant information is contained in these messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [start, interim, stop, and event] from the network elements to the CDF.

Off-line charging is classified into following types.

  • Session-based charging (types START, INTERIM, STOP).
  • Event-based charging (type EVENT) for OOD SUBSCRIBE, REFER, NOTIFY, REGISTER, OPTIONS, MESSAGE and PUBLISH.

ACR types START, INTERIM and STOP are used for accounting data related to successful sessions. The SBC sends the START and STOP records if Rf accounting is enabled. SBC sends available charging information as per Rf interface specifications.

In contrast, EVENT accounting data is unrelated to sessions, and is used for example, for a simple registration or interrogation or successful service event triggered by a network element or unsuccessful session establishment attempts.

In this release, SBC supports only event records for unsuccessful session attempts.

The Accounting Request (ACR) and Accounting Answer (ACA) as specified in the Diameter Base Protocol Accounting (DBPA) application are the messages used for off-line charging.

Offline charging can be operator-configurable in the nodes for which SIP messages an Accounting Request is sent. The following table lists all possible ACRs that might be sent from a P-CSCF, I-CSCF, S-CSCF, MGCF, or BGCF.

Table : SBC Handling of Diameter Messages

 

Diameter Message

IMS Node Triggering of SIP Methods / ISUP Messages

ACR [Start]

IMS Node sends ACR (Start) to Rf Accounting server when SIP 200 OK acknowledging an Initial SIP INVITE is received.

ACR [Interim]

IMS Node sends ACR (Interim) to Rf Accounting server, when "Accounting Interim interval" for the session expires.

When "Acct-Interim-Interval" AVP is received from the AAA server in ACA message, SBC treats the value received as the "Accounting Interim interval" for the session.

When "Acct-Interim-Interval" AVP is NOT received from the AAA server in ACA message, SBC treats the default "Accounting Interim interval" value configured on the system as "Accounting Interim Interval" for the session.

When "Acct-Interim-Interval" AVP is NOT received from the AAA server in ACA message and "Accounting Interim Interval" value configured on the system is '0', SBC does NOT send ACR (Interim) Message for the session.

When "Acct-Interim-Interval" AVP is received from the AAA server in ACA message, SBC sends ACR (Interim) Message for the session based on the value received in "Acct-Interim-Interval AVP", irrespective of "Accounting interim interval" value configured on the system.

ACR [Stop]




IMS Node sends ACR (STOP) with Cause-Code AVP (AVP code 861) to Rf Accounting server when session is terminated. (Session for which ACR (Start) was originally sent by the node).

Termination examples:

  • SIP BYE request received for SIP INVITE session from Calling or called Party
  • Any Abnormal SIP session release (Internal error or call released by SBC, for example, call release because of inactivity timer expiry, long duration call, call drop because of card failure and so on.)
When an ongoing SIP session has been normally released either by the user or by the network (SIP BYE message initiated by the user or initiated by the network has been received by the IMS node after the reception of the SIP ACK message), SBC sends the ACR (STOP) as below.

When the SIP session is not successfully established (that is, Timer H expires and SIP ACK is not received, or SIP BYE is received after reception of the 200 OK final response and SIP ACK is not received), SBC sends the ACR:

Cause-code AVP (AVP code 861) = "Unsuccessful session setup"    2

When the SIP session is terminated by the IMS node because of a system error (for example, system wide error or failure, crash, card failure) after session is established, SBC sends the ACR:

Cause-code AVP (AVP code 861) = "Unspecified error"       1

 "Unspecified error" is used when Specific Cause-codes not defined. SBC sends "1" for any "Internal" or unspecified errors which cannot be mapped to any existing cause-codes.

ACR [Attempt]

IMS Node sends the ACR (EVENT) to Rf Accounting server to report a failed session attempt in following scenarios:

  • Terminate Session due to receipt of SIP CANCEL before INVITE session is established,
  • Terminate Session due to receipt of Final SIP response (4xx, 5xx, 6xx) before INVITE session is established,
  • Any Abnormal SIP session release due to Internal error, for example, call drop because of card failure etc. before INVITE session is established.

On the Rf interface there is no ACR (ATTEMPT) record type, ACR (EVENT) is used to report attempt records.

 

IMS Node sends the ACR (EVENT) to Rf Accounting server, to report a redirection of a session attempt in following scenario.

  • Session is redirected because of receipt of Final SIP response (3xx) before INVITE session is established,
 

IMS Node sends the ACR (EVENT) to Rf Accounting server to report a redirection of a session attempt in following scenario.

  • Redirect Session due to receipt of Final SIP response (3xx) before INVITE session is established
ACR [Event]

IMS Node sends the ACR (EVENT) to Rf Accounting server to report non-session related SIP Message events on receipt of following messages.

  • SIP 200 OK Message to acknowledge SIP NOTIFY transaction
  • SIP 200 OK Message to acknowledge SIP MESSAGE transaction
  • SIP 200 OK Message to acknowledge Initial SIP REGISTER transaction
  • SIP 200 OK Message to acknowledge Initial SIP SUBSCRIBE transaction
  • SIP 200 OK Message to acknowledge SIP PUBLISH transaction
  • SIP 200 OK Message to acknowledge SIP OPTIONS RELAY transaction
  • SIP 202 OK Message to acknowledge SIP REFER transaction

 

When a successful transaction terminating the Registration dialog is detected by the IMS node, the node sends the ACR as below.

  • Cause-code AVP (AVP code 861) = "End of REGISTER dialog"   -3

In the following scenarios:

  • SIP De-register request received from User (Expires =0).
  • SIP NOTIFY with "reg evnt" received notifying deletion of registration.
  • Deletion of registration on Expiry of registration expiry timer.
  • SIP registration administratively deleted using CLI/GUI.
 

When the SIP transaction is terminated due to an IMS node receiving/initiating a 3xx Final response, Node sends the ACR as below.

  • · Cause-code AVP (AVP code 861) = "3xx Redirection"    -3xx
 

When the SIP transaction (INVITE or Non-INVITE transaction) is terminated due to an IMS node receiving/initiating a Failure response (that is, 4xx, 5xx, 6xx) error response, Node sends the ACR with appropriate Cause-code AVP (AVP code 861) value as below.

  • "4xx Request failure"    4xx
  • "5xx Request failure"    5xx
  • "6xx Request failure"    6xx
 

When the SIP transaction (INVITE or Non-INVITE transaction) is terminated due to an IMS node has internal or Unknown error (for example, error in processing a request/response), Node sends one of the cause codes in the ACR as below.

  • · Cause-code AVP (AVP code 861) = "Unspecified error"     1

Transaction failures which do not map to previous requirements should be logged as Internal or Unknown errors. This is a catch-all cause-code.

 

When a successful transaction terminating the Subscription dialog is detected by the IMS node, the node sends the ACR with cause-code AVP (AVP code 861) = End of SUBSCRIBE dialog (-2).

  • SIP Unsubscribe request is received from User (Expires =0)
  • SIP NOTIFY (in-dialog) with subscription-state header is set to 'terminated' notifying deletion of subscription
  • Subscription is deleted on Expiry of subscription timer
  • SIP subscription is administratively deleted using CLI/GUI
 

When eventAcctState flag is enabled, EVENT records are generated for OOD SUBSCRIBE, REFER, NOTIFY, REGISTER, OPTIONS, MESSAGE, and PUBLISH.

 

On the Rf interface there is no ACR (ATTEMPT) record type, ACR (EVENT) is used to report attempt records

 

Supported Attribute-Value Pairs (AVPs)

The following AVPs are supported for Rf interface:

Table : Rf Interface Supported Attriubute-Value Pairs

AVPsAVP CodeDescription
Session-Id263This field identifies the operation session.
Origin-Host264This field contains the identification of the source point of the operation and the realm of the operation originator.
Origin-Realm296This field contains the realm of the operation originator.
Destination-Realm283This field contains the realm of the operator domain. The realm will be addressed with the domain address of the corresponding public URI.
Destination-Host293

This field is of type "DiameterIdentity". This is present in all the unsolicited agent initiated messages, may present in request messages, and must not present in answer messages.

Accounting-Record-Type480This field defines the transfer type that is, event for event based charging and start, interim, stop for session based charging.
Accounting-Record-Number485

This field contains the sequence number of the transferred messages.

Acct-Application-Id259The field corresponds to the application ID of the Diameter Accounting Application and is defined with the value 3.
User-Name1This field contains the user name determined by the domain that is, bearer, sub-system, or service as described in middle tier TS.
Acct-Interim-Interval85This field indicates the preferred intermediate charging interval value.
Origin-State-Id461

This field contains the state associated to the CTF.

Event-Timestamp55This field corresponds to the exact time the accounting is requested.
Route-record282This field contains an identifier inserted by a relaying or proxying node to identify the node from where the message is received.
Service-Context-Id461This field indicates the service and the corresponding "middle tier" TS.
Service-Information873This parameter contains the individual service specific parameters as defined in the corresponding "middle tier" TS.
Subscription-Id443

This field contains the Private User Identity and/or Public User Identity/Identities.

Parameter NameTypeCodeDescription
Subscription-Id-Type 450This field contains the identifier type.
Subscription-Id-Data 444This field contains the information about the identifier.

IMS-Information

876This field allows the transmission of additional IMS service specific information elements.
Event Type823

This field contains the SIP Method, the content of the SIP “Event” header, and the content of the SIP “expires” header when present in the SIP request.

Node Functionality862This field contains the function of the node.
Role of Node829This field specifies whether the IMS node is serving the Originating or the Terminating party. The AVP "Role of Node" is used when SBC acts as P-CSCF and IBCF. The value of the "Role of Node" AVP is determined in SIPSG and sent to CAM through CC.
User Session ID830This field contains the session identifier. For a SIP session the Session-ID contains the SIP Call ID. When the AS acts as B2BUA, the incoming session is identified.
Calling Party Address831This field contains the address (SIP URI or TEL URI)URI of the party (Public User Identity or Public Service Identity) initiating a session or requesting a service.
Called Party Address832

For SIP transactions, except for registration, this field contains the address of the party (Public User ID or Public Service ID) to whom the SIP transaction is posted.

Number-Portability-Routing-Information2024This field includes information on number portability after DNS/ENUM request from IMS node in the calling users' home network.
Requested Party Address1251For SIP transactions this field contains the address of the party (Public User ID or Public Service ID) to whom the SIP transaction was originally posted.
Inter-Operator-Identifier838

This field is of type "Grouped" and contains the identification of the network neighbors (originating and terminating) as exchanged via SIP signaling if available.

Parameter NameTypeCodeDescription
Originating-IOI 839This field identifies the network that originated the SIP dialog.
Terminating-IOI 840This field identifies the network that terminated the SIP dialog.
IMS Charging Identifier841This field contains the IMS Charging Identifier (ICID) as generated by an IMS node for a SIP session.
Early-Media-Description1272This field contains session and media parameters related to media components set to active during the SIP session establishment and before a final successful or unsuccessful SIP answer to the initial SIP INVITE request is received.
SDP-Media-Component843This is a grouped field comprising several sub-fields associated with one media component. As several media components may exist for a session in parallel, these sub-fields may occur several times. This AVP along with the core media attributes contain all the OMR attributes including visited-realm lines and other OMR attributes.
SDP-Session-Description842This field contains the content of an "attribute-line" (i=, c=, b=, k=, a=, etc.) related to a session. For Offer SDP, this AVP contains the connection information present in the c-line of the offer SDP received by SBC. For answer SDP, this AVP contains the connection information present in the c-line of the answer SDP sent out by SBC.
Served-Party-IP-Address848This field contains the IP address of either the calling or called party, depending on whether the P-CSCF is in touch with the calling or the called party.
Access-Network-Information1263This field contains the content of the P-header P-Access-Network-Info.
Result-Code268This field contains the result of the specific query.
Cause-Code861This field contains the cause code value from IMS node related to session termination.
Time-Stamp833

This field contains the timestamp of the SIP Request and the timestamp of the response to the SIP Request.

Subscription-Id-Data444

This field is used to identify the end user.

SDP-Media-Name844This field contains the content of a "m=" line in the SDP data.
SDP-Media-Description845This field contains the content of an "attribute-line" (i=, c=, b=, k=, a=, etc.) related to a media component.
Media-Initiator-Flag882

This field indicates the party, which has requested the session modification.

Media-Initiator-Party1288This field contains the address of the party who initiates the media action, like adding/removing, connecting/disconnecting the media.
SDP-Type2036This field contains information if the SDP media component is either SDP offer or SDP answer.
SDP-TimeStamps1273This field contains the time of the SDP offer and the SDP answer.
SDP-Offer-Timestamp1274This field contains the time in UTC format of the SDP offer.
SDP-Answer-Timestamp1275This field contains the time in UTC format of the response to the SDP offer.
NNI-Information2703

This field holds information about the NNI used for interconnection and roaming. This AVP is applicable only for IBCF. The following fields are present in this AVP:

Parameter NameTypeCodeDescription
Session DirectionEnumerated2707This field indicates if the NNI is used for an inbound or outbound service request on the control plane in case of interconnection and roaming.
NNI TypeEnumerated2704This field indicates if the type of used NNI is non-roaming, roaming without loopback routing, or roaming with loop-back routing.
Relationship ModeEnumerated2706This field indicates if the other functional entity (for example, contact point of the neighboring network) is regarded as part of the same trust domain.
Neighbour Node AddressIP Address2705This field holds the control plane IP address of the neighboring network contact point that handles the service request in case of interconnection and roaming.
Media Component843

The following fields are added in this AVP:

Parameter NameTypeCodeDescription
Local GW Inserted IndicationEnumerated2604This field indicates if the local GW (TrGW, IMS-AGW) is inserted or not for the SDP media component.
IP realm Default IndicationEnumerated2603This field indicates if the IP realm used for the SDP media component is the default IP realm or not.
Transcoder Inserted IndicationEnumerated2605This Field indicates if a transcoder is inserted or not for the SDP media component.
Transit-IOI-List2701SBC sends "Transit-IOI-List" AVP in ACR [START, INTERMEDIATE, STOP, EVENT] messages over Rf interface. This is performed for both INVITE and non-INVITE messages. This is applicable to both P-CSCF and IBCF Rf messages. Multiple occurrences of this AVP are in chronological order, that is, the value in the SIP request is listed first followed by the values received in SIP responses. If only a value for the SIP response is available, the Transit-IOI-List for the SIP request are included with the value "unknown".
IMS-Communication-Service-Identifier1281SBC sends “IMS-Communication-Service-Identifier” AVP in ACR [START] messages over Rf interface. This is applicable for INVITE message. This holds the IMS Communication Service Identifier (ICSI) as contained in the P-Asserted-Service header of a SIP request. This is applicable to both P-CSCF and IBCF Rf messages.
From-Address2708SBC sends “From-Address” AVP in ACR [START, INTERMEDIATE, STOP, and EVENT] messages over Rf interface. This essentially covers both INVITE and non-INVITE messages.This includes the information from the SIP From header. This is applicable to both P-CSCF and IBCF Rf messages.
IMS-Emergency-Indicator2322SBC sends “IMS-Emergency-Indicator” AVP in ACR [START, INTERMEDIATE, STOP, and EVENT] messages over Rf interface. This indicates the IMS session as an IMS emergency session or IMS registration. This covers both INVITE and REGISTER messages. This is applicable only to P-CSCF Rf messages

Access-Transfer-Information

1263

This field is of type "Grouped", which provides information on access transfer for IMS service continuity.

Access-Transfer-Type

2710

This field is of type "Enumerated", which indicates the type of transfer occurred.

Called-Asserted-Identity

1250

This field is of type "UTF8String" and contains the address (Public User ID: SIP URI, E.164, and so on) of the finally asserted called party.

SIP-Method824This field is of type "UTF8String" and contains the name of the SIP Method (INVITE, UPDATE, and so on).
Event825This field is of type "UTF8String" and contains the content of the "Event" header.
Expires888

This field is of type "Unsigned32" and contains the content of the "Expires" header.

SIP-Request-Timestamp834

This field is of type "Time" and contains the time in UTC format of the SIP request (for example, Invite, Update, and so on).

SIP-Response-Timestamp835This field is of type "Time" and contains the time in UTC format of the response to the SIP request (for example, 200 OK).
IMS-Charging-Identifier841This field is of type "UTF8String" and contains the IMS Charging Identifier (ICID) as generated by an IMS node for a SIP session.
IMS-Visited-Network-Identifier2713This field carries P-Visited-Network-Id header value inserted by SBC in the outgoing REGISTER request.
SIP-Request-Timestamp-Fraction2301This field is of type Unsigned32 and holds the milliseconds fraction in relation to SIP-Request-Timestamp.
SIP-Response-Timestamp-Fraction2302This field is of type Unsigned32 and holds the milliseconds fraction in relation to SIP-Response-Timestamp.

For more information on AVPs, refer to the following 3GPP documents at 3GPP web sitte:

  • 3GPP TS 32.299
  • 3GPP TS 32.260

Impact to Ingress and Egress Protocol Variant Specific Field Descriptions

If the Rf flag is enabled, both Ingress and Egress Protocol Variant Specific data contain the following additional information related to Rf.

  • Node Functionality: whether P-CSCF or IBCF
  • Role of Node: Originating or Terminating
  • usePcfaCcf: Flag whether to use ccf in P-Charging-Function-Address

Figure : Accounting Records Summary for call-specific records

Field Name

ASCII Accounting

Streaming Accounting

 

Max Length in
ASCII Characters

Type

START

STOP

ATTEMPT

INTERMEDIATE

Streaming
Field ID

GMI Type

 

Record Number  

 

Ingress Protocol Variant Specific Data

1849

Characters

42

52

45

38

51

STRING

Egress Protocol Variant Specific Data
1849Characters5569595168STRING

SBC may insert non-ASCII characters in CDRs when messages are parsed in the initial INVITE.