Contents

1   Introduction

This document describes the 3GPP® specified Rf interface between the Call Session Control Function (CSCF) and the Charging system of the IP Multimedia Subsystem (IMS) for offline charging support. It also describes the services offered by the Charging system and used by the CSCF. Unless specified explicitly, CSCF implies both Serving CSCF (S-CSCF) and Emergency CSCF (E-CSCF).

The Diameter Charging messages sent between the CSCF, that is, the E-CSCF and the S-CSCF, and the Charging system are based on Diameter base protocol and the 3GPP technical specification for Diameter Charging applications with Ericsson-specific additions. Refer to the RFC 3588 Diameter Base Protocol and 3GPP TS 32.299 Diameter Charging Applications (v6.3.0 and v12.7.0) specifications.

Charging messages are described in the document in terms of Attributes Value Pairs (AVPs).

2   Interface Overview

The Rf interface is defined by 3GPP and is the reference point between a Charging Trigger Function (CTF) and a Charging Data Function (CDF). This is also referred to as a Charging system in this document.

The CSCF acts as a CTF, collecting the information pertaining to chargeable events, assembling this information into matching Charging events, and sending these Charging events to the CDF, see Figure 1.

The CDF receives Charging events from the CSCF and uses the information contained in the Charging events to construct CDRs.

For more details of the CTF, the CDF, and the Rf reference point, refer to the RFC 3588 Diameter Base Protocol specification.

2.1   Interface Role

This section describes the services offered by the CDF that are used by the CSCF.

The CSCF sends Diameter Accounting-Request (ACR) messages to the CDF.

The CDF responds to the CSCF using Diameter Accounting-Answer (ACA) messages.

2.2   Services

There are services used by the CSCF but there are no services offered by the CSCF to the CDF.

The services used by the CSCF are shown in Table 1.

2.3   Encapsulation and Addressing

This interface uses Diameter accounting messages that are transported over the Stream Control Transmission Protocol (SCTP) and the Transmission Control Protocol (TCP) on IPv4/IPv6. The message contents are based on the content that is defined by 3GPP and supplemented, where applicable, with Ericsson-defined information conveyed in vendor-specific AVPs.

Information including CDF realm addresses and communication port numbers must be preconfigured for the connections between the CSCF and all relevant CDFs. Connections between the CSCF and CDFs are only established based on the preconfigured data.

For further details on the configuration on the native CSCF, refer to CSCF Charging Parameter Description.

For further details on the configuration on the virtual CSCF, refer to Managed Object Model (MOM).

The user profile is downloaded from the HSS to the S-CSCF using the Cx interface. The user profile contains the primary CDF address and session-unrelated events data. The S-CSCF uses the primary CDF address as the CDF realm address when reporting accounting information for a SIP session. The secondary address is also interpreted as the realm for the CDF function. The secondary address is optional.

If no Charging function addresses are received in the profile, a locally configured default CDF realm address is used instead.

3   Procedures

In offline charging, the Charging information is transferred between the CSCF and a CDF, using the ACR and ACA messages. Charging information can be provided as session-based Charging or event-based Charging.

Session-based Charging is used to transfer accounting data related to successfully established SIP sessions. A Charging session is established between the CSCF and the CDF when the SIP session has been successfully established and is retained until the SIP session is terminated. During the Charging session, further accounting data can be transferred to the CDF, for example, following a successful media change. For more information on session-based Charging, see Section 3.4 Session-Based Charging.

Event-based Charging is used to transfer accounting data related to unsuccessful SIP session establishment attempts and to transfer accounting data for events that are not related to SIP sessions. Non-session-related events are for example SIP SUBSCRIBE and SIP NOTIFY requests. A single Charging event message is sent from the CSCF to the CDF, containing all relevant accounting data for the event. For more information, see Section 3.5 Event-Based Charging.

3.1   Accounting-Request Message

The Accounting-Request message (ACR) message is used to transmit the Charging information to the CDF, which by replying with the ACA message confirms the ACR reception.

Different Account Record types can be applied within the ACR: START_RECORD, STOP_RECORD, INTERIM_RECORD, and EVENT_RECORD.

The START_RECORD is used to start a Charging session, and is generated upon receipt of a successful final response on the initial INVITE.

An INTERIM_RECORD can be triggered by a session update event or can be time-based. An INTERIM_RECORD triggered by a session update event is generated upon receipt of a successful final response to an in-session message. re-INVITE and UPDATE are two SIP methods that can occur during an ongoing SIP session, and can modify the media. If configured so, a re-INVITE or UPDATE containing Session Description Protocol (SDP) data trigger an ACR (INTERIM_RECORD).

A time-based INTERIM_RECORD is triggered by the CSCF interim timer. A time-based INTERIM_RECORD is not related to any SIP event during a SIP session. Once a Charging session is initiated by sending the ACR (START_RECORD), the CDF can indicate in the ACA message acknowledgment, by the presence of an Accounting-Interim-Interval AVP, whether it requires from the CSCF to send intermediate ACR (INTERIM_RECORD) messages and at which time interval. If the Accounting-Interim-Interval AVP is not set or is set to 0 in an ACA message, then the CSCF stops generating new time-based INTERIM_RECORDs until an ACA message containing an Accounting-Interim-Interval AVP with a non-zero value is received.

The STOP_RECORD is used to end a Charging session and is typically generated at release of the SIP session. For more information, see Section 3.6 Charging Session Termination.

An EVENT_RECORD is generated for the exchange of information with the Charging system in an event Charging session where information about that SIP signaling event is exchanged and then immediately closed.

3.2   Accounting-Answer Messages (ACA)

The CSCF validates the ACA messages that are received from the CDF against the sent ACR messages by inspecting the following parameters:

• Session Identifier
• Record Type, that is, START, STOP, INTERIM, or EVENT
• Record Number

If the validation fails for one of these parameters, the Charging session terminates and the SIP session continues without Charging. For more information, see Section 3.6 Charging Session Termination.

3.3   Lower-Level Procedures

The CSCF Diameter accounting application depends on the connection handling capabilities of the Diameter Base Protocol that are provided by the Diameter stack.

For more information on the native CSCF, refer to Diameter User Guide.

For more information on the virtual CSCF, refer to Diameter Management.

The connection handling capabilities include the following:

• Establishing connections between the CSCF and the CDF nodes, including the exchange of capabilities.
• Transporting application messages between the CSCF and CDF nodes.
• Detecting transport failures, including the use of watchdog messages.
• Disconnecting connections between the CSCF and the CDF nodes.

Various aspects of the connection handling capabilities can be configured, including the following:

• Maximum waiting time for a response from the CDF.
• Maximum number of message sending retries.
• Maximum time without activity before a watchdog message is sent.

For further details of configuration and suggested settings, refer to CSCF Charging Parameter Description for the native CSCF and Managed Object Model (MOM) for the virtual CSCF.

3.4   Session-Based Charging

A Charging session is initiated at the reception of the 200 (OK) successful final response to a SIP INVITE for a SIP session setup. A prerequisite for this is the configuration of Charging triggers that match TRUE for the received INVITE message.

The Charging session towards CDF is initiated with an ACR (START_RECORD), possibly updated with one or more ACRs (INTERIM_RECORD) and terminated at reception of the SIP BYE method or on network-initiated release with an ACR (STOP_RECORD).

Once a Charging session is initiated by sending the ACR (START_RECORD), the CDF can indicate in the ACA message acknowledgment, by the presence of an Accounting-Interim-Interval AVP, whether it requires from the CSCF to send time-based intermediate ACR (INTERIM_RECORD) messages.

ACRs (INTERIM_RECORD) are also sent in case of successful session updates by re-INVITE or UPDATE, for example for media type change.

The CDF function can indicate in the ACA acknowledgment to the CSCF that offline charging is no longer applicable and is considered terminated by sending a 4011 value in the Experimental-Result-Code AVP, see Section 5.2.1.28 Experimental-Result-Code. However the ongoing SIP service is not terminated.

This section describes the most significant session charging sequence diagrams.

See Figure 2 for a description of normal session handling without interim records.

See Figure 3 for a description of normal session handling with interim records.

See Figure 4 for a description of normal/successful session handling, forking in the S-CSCF only.

See Figure 5 for a description of normal/successful session handling, forking in downstream proxy.

3.5   Event-Based Charging

Offline event charging is implemented by sending an ACR (EVENT_RECORD) for SIP signaling events not resulting in a durable Charging session.

The following list summarizes S-CSCF signaling events for ACR (EVENT_RECORD) generation:

• SIP Final Responses 2xx, except 200 (OK), for INVITE
• SIP Final Response 3xx indicating a redirection of the SIP request
• SIP Final Response (4xx, 5xx, or 6xx), indicating an unsuccessful SIP session setup or SIP session refresh
• SIP 2xx to acknowledge non-session related SIP messages SIP NOTIFY, SIP MESSAGE, SIP REGISTER, SIP SUBSCRIBE, SIP PUBLISH, and SIP REFER
• SIP Final Response (4xx, 5xx, or 6xx), indicating an unsuccessful session-unrelated procedure
• SIP Requests configured to be authentication challenged, the S-CSCF indicates 407 in an ACR Event
• SIP CANCEL, received in the S-CSCF

The following list summarizes E-CSCF signaling events for ACR (EVENT_RECORD) generation:

• SIP Final Responses 2xx, except 200 (OK), for INVITE
• SIP Final Response 3xx indicating a redirection of the SIP request.

  Note:  

  This does not apply to 3xx received over the SIP-based Ml interface from LRF or 3xx for session refresh. In these cases, there is no Charging event generated by E-CSCF

  
  
• SIP Final Response (4xx, 5xx, or 6xx), indicating an unsuccessful SIP session setup.

  Note:  

  This does not apply to 4xx, 5xx, or 6xx received over SIP-based Ml interface from LRF or error responses for session refresh. In these cases, there is no Charging event generated by the E-CSCF

  
  
• SIP Final responses on not-allowed messages, 501 (Not implemented), for example, SIP MESSAGE
• SIP CANCEL, received in the E-CSCF, indicating abortion of a SIP session setup.

The following illustrations highlight the exchanges of ACR (EVENT_RECORD) and ACA between the CSCF and the Charging system.

See Figure 6 for a description of successful mid-session event handling.

See Figure 7 for a description of successful out-of-session event handling.

See Figure 8 for a description of event handling in unsuccessful session setup.

3.6   Charging Session Termination

A Charging session is terminated in the following cases:

• Upon receipt of a SIP BYE request to terminate a SIP session, the CSCF issues an ACR (STOP_RECORD).
• On network initiated releases, such as on call session time-out or on administrative state set to lock, the CSCF issues an ACR (STOP_RECORD).
• On receipt of an AVA with a Result-Code AVP indicating unsuccessful Diameter messaging. See Section 5.2.1.48 Result-Code for details.
• The CDF requests that the CSCF sends no more Charging information for the remainder of the SIP session by setting the Experimental-Result-Code value in the ACA as described in Section 5.2.1.28 Experimental-Result-Code. The CSCF sends no further ACRs (INTERIM or STOP) to the CDF.
• On receipt of an AVA without both the Result-Code AVP and the Experimental-Result-Code AVP. The CSCF sends no further ACRs (INTERIM or STOP) to the CDF. See Section 5.1.2 Accounting-Answer Message.
• On ACA message validation failure, the CSCF sends no further ACRs (INTERIM or STOP) to the CDF. See Section 3.2 Accounting-Answer Messages (ACA).

The CSCF terminates the Charging session without changing the state of the SIP session.

3.7   Offline Charging Triggers

A CSCF node can be configured to allow and support offline charging depending on the combination of a set of trigger conditions which include conditions on, for example, SIP method, Request-URI, SIP Header, SIP Header content, and Session Case. A session-based or an event-based Charging is successfully established when the configured conditions are matched successfully. The S-CSCF and the E-CSCF have independent trigger condition configurations.

3.8   Offline Charging Variants

The CSCF supports two offline charging variants: Variant-1 and Variant-2.The two variants support different combinations of Diameter, 3GPP and Ericsson-specific AVPs over the Rf interface.

Variant-1 supports Diameter and 3GPP AVPs mostly specified in 3GPP specifications before release 7 (3GPP TS 32.299 Diameter Charging Applications v6.3.0 and 3GPP TS 32.260 IP Multimedia Subsystem (IMS) Charging v6.2.0) with a few AVPs specified in later 3GPP releases, for example Related-IMS-Charging-Identifier AVP from release 12 (refer to 3GPP TS 32.299 Diameter Charging Applications v12.7.0). Variant-1 generates many AVPs in an Ericsson specific grouped and sub-AVP structure.

Variant-2 supports offline charging according to 3GPP release 12 specifications (refer to 3GPP TS 32.299 Diameter Charging Applications v12.7.0 and 3GPP TS 32.260 IP Multimedia Subsystem (IMS) Charging v12.6.0). Variant-2 outputs all Diameter and 3GPP specified AVPs in the 3GPP specified grouped and sub-AVP structure.

The S-CSCF and the E-CSCF have independent variant configurations. The two variants are not compatible with each other. It is possible to change variants in the CSCF in real time (refer to CSCF Charging Parameter Description). The CDF must be capable to support same variants as the CSCF. This document provides detailed information on AVPs and ACR/ACA message contents for offline charging Variant-1 and Variant-2 supports by the S-CSCF and the E-CSCF.

3.9   Error Handling

The Diameter connection is supervised and when no activity is detected, watchdog requests are sent. When no watchdog requests are answered or any other messages are received on that connection, the connection is considered closed and the CDF is down.

Attempts are always made to reopen closed connections. Three watchdog requests are sent after a successful TCP reconnection and the Diameter connection is considered up after three successful watchdog requests.

If a request from the CSCF is not answered within a configurable time, the request is retransmitted a configurable number of times.

If multiple peers are specified for the destination realm, the message is sent to an alternative and available peer that serves the application on the realm in case of receiving the following errors owing to a temporary failure:

• 3002: DIAMETER_UNABLE_TO_DELIVER
• 3004: DIAMETER_TOO_BUSY
• 4002: DIAMETER_OUT_OF_SPACE
• 4003: ELECTION_LOST

Accounting-Requests for already established Charging sessions (INTERIM and STOP) do not switch over but are buffered until the used server comes up again.

If there is only one peer specified in the request, it is retransmitted to the same peer as long as the connection is established and there are no indications of temporary failure.

If the secondary server also fails, all Accounting-Requests are buffered. As long as there are Accounting-Requests buffered, the CSCF regularly tries to resend the first request in the buffer. A delay is introduced before the message is retried after the latest temporary failure indication. The delay takes the recovery mechanism in the transport profile for Diameter into account. A recommended value is slightly more than three times Twinit (about 100 seconds). The buffered Accounting-Request is stored on the disk after it has not been successfully transmitted to the CDF.

There are no dependencies when sending the Accounting-Requests stored on the file disk to multiple destinations. When at least one of the connections is up again, the CDF answers the Accounting-Requests that are sent from the buffer. The CSCF can then remove the corresponding request from the buffer and continue with sending the other requests that are stored on the disk to the connected server. If the buffer gets full, subsequent Charging information is lost and an alarm is raised.

4   Information Model

The command codes used to identify messages sent on the Rf interface are specified in the RFC 3588 Diameter Base Protocol specification.

The two Diameter Charging messages used in the CSCF for offline charging have the command codes defined in Table 2.

5   Formal Syntax

The following symbols are used in this document:

• < AVP > indicates a mandatory AVP with a fixed position in the message.
• { AVP } indicates a mandatory AVP in the message.
• [ AVP ] indicates an optional AVP in the message.
• * AVP indicates that multiple occurrences of an AVP are possible.

The symbols are according to the 3GPP TS 32.299 v6.3.0 Diameter Charging Applications specification.

5.1   Diameter Header

A Diameter header has the format as shown in Figure 9.

5.1.1   Accounting-Request Message

The Diameter Charging Request message is used for sending CSCF-specific Charging information to the CDF. The subsections summarize the contents and AVP structure of the ACR messages for the different offline charging variants. All the CSCF-supported optional AVPs are included in the respective summaries.

5.1.1.1   Variant-1

S-CSCF ACR (START_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Subscription-Id ]
     →{ Subscription-Id-Type }
     →{ Subscription-Id-Data }
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ]
     →[ SIP-Request-Timestamp ]
     →[ SIP-Response-Timestamp ]
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    *[ SDP-Session-Description ] 
    *[ SDP-Media-Component ] 
     →[ SDP-Media-Name ]
     →*[ SDP-Media-Description ]
    [ Service-Information ]
     →[ PS-Information ]
     →→[ 3GPP-SGSN-MCC-MNC ]
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Carrier-Select-Routing-Information ]
    [ Number-Portability-Routing-Information ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ Dial-Around-Indicator ]
     →[ Authentication-Method ]
     →[ SIP-Request-Timestamp-Fraction ]
     →[ SIP-Response-Timestamp-Fraction ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
    [ GPRS-Roaming-Status ]
    [ SIP-Ringing-Timestamp ]
    [ Event-NTP-Timestamp ]

S-CSCF ACR (INTERIM_RECORD)

The AVPs identified with a "(note)" are present in a SIP re-INVITE or SIP UPDATE message triggered ACR (INTERIM_RECORD) only. They are absent in a time-based ACR (INTERIM_RECORD).

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Subscription-Id ]
     →{ Subscription-Id-Type }
     →{ Subscription-Id-Data }
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ] (note)
     →[ SIP-Request-Timestamp ] (note)
     →[ SIP-Response-Timestamp ] (note)
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    *[ SDP-Session-Description ] 
    *[ SDP-Media-Component ] 
     →[ SDP-Media-Name ]
     →*[ SDP-Media-Description ]
    [ Service-Information ]
     →[ PS-Information ]
     →→[ 3GPP-SGSN-MCC-MNC ]
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Carrier-Select-Routing-Information ]
    [ Number-Portability-Routing-Information ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ Dial-Around-Indicator ]
     →[ Authentication-Method ]
     →[ SIP-Request-Timestamp-Fraction ] (note)
     →[ SIP-Response-Timestamp-Fraction ] (note)
     →*[ Transaction-Info ] (note)
     →→{ Transaction-Type } (note)
     →→{ Transaction-Data-Name }(note)
     →→*{ Transaction-Data-Value }(note)
    [ GPRS-Roaming-Status ]
    [ SIP-Ringing-Timestamp ]
    [ Event-NTP-Timestamp ]

S-CSCF ACR (STOP_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Subscription-Id ]
     →{ Subscription-Id-Type }
     →{ Subscription-Id-Data }
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ]
     →[ SIP-Request-Timestamp ]
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    *[ SDP-Session-Description ] 
    *[ SDP-Media-Component ] 
     →[ SDP-Media-Name ]
     →*[ SDP-Media-Description ]
    [ Service-Information ]
     →[ PS-Information ]
     →→[ 3GPP-SGSN-MCC-MNC ]
    [ Cause ]
     →{ Cause-Code }
     →{ Node-Functionality }
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Carrier-Select-Routing-Information ]
    [ Number-Portability-Routing-Information ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ Dial-Around-Indicator ]
     →[ Authentication-Method ]
     →[ SIP-Request-Timestamp-Fraction ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ Disconnect-Direction ]
    [ SIP-Reason ]
     →[ SIP-Reason-Cause ]
     →[ SIP-Reason-Text ]
    [ GPRS-Roaming-Status ]
    [ SIP-Ringing-Timestamp ]
    [ Event-NTP-Timestamp ]

S-CSCF ACR (EVENT_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Subscription-Id ]
     →{ Subscription-Id-Type }
     →{ Subscription-Id-Data }
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Event ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ]
     →[ SIP-Request-Timestamp ]
     →[ SIP-Response-Timestamp ]
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    [ Service-Information ]
     →[ PS-Information ]
     →→[ 3GPP-SGSN-MCC-MNC ]
    [ Cause ]
     →{ Cause-Code }
     →{ Node-Functionality }
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Carrier-Select-Routing-Information ]
    [ Number-Portability-Routing-Information ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ Dial-Around-Indicator ]
     →[ Authentication-Method ]
     →[ SIP-Request-Timestamp-Fraction ]
     →[ SIP-Response-Timestamp-Fraction ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
    [ SIP-Reason ]
     →[ SIP-Reason-Cause ]
     →[ SIP-Reason-Text ]
    [ GPRS-Roaming-Status ]
    [ Event-NTP-Timestamp ]

E-CSCF ACR (START_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ]
     →[ SIP-Request-Timestamp ]
     →[ SIP-Response-Timestamp ]
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    *[ SDP-Session-Description ] 
    *[ SDP-Media-Component ] 
     →[ SDP-Media-Name ]
     →*[ SDP-Media-Description ]
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Ericsson-Service-Information ]
     →[ Instance-Id ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ SIP-Request-Timestamp-Fraction ]
     →[ SIP-Response-Timestamp-Fraction ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
    [ SIP-Ringing-Timestamp ]
    [ Event-NTP-Timestamp ]

E-CSCF ACR (INTERIM_RECORD)

The AVPs identified with a "(note)" are present in a SIP re-INVITE or SIP UPDATE message triggered ACR (INTERIM_RECORD) only. They are absent in a time-based ACR (INTERIM_RECORD).

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ] (note)
     →[ SIP-Request-Timestamp ] (note)
     →[ SIP-Response-Timestamp ] (note)
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    *[ SDP-Session-Description ] 
    *[ SDP-Media-Component ] 
     →[ SDP-Media-Name ]
     →*[ SDP-Media-Description ]
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Ericsson-Service-Information ]
     →[ Related-IMS-Charging-Identifier ] (note)
     →[ Instance-Id ] (note)
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ SIP-Request-Timestamp-Fraction ] (note)
     →[ SIP-Response-Timestamp-Fraction ] (note)
     →*[ Transaction-Info ] (note)
     →→{ Transaction-Type } (note)
     →→{ Transaction-Data-Name } (note)
     →→*{ Transaction-Data-Value } (note)
    [ SIP-Ringing-Timestamp ]
    [ Event-NTP-Timestamp ]

E-CSCF ACR (STOP_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ]
     →[ SIP-Request-Timestamp ]
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    *[ SDP-Session-Description ] 
    *[ SDP-Media-Component ] 
     →[ SDP-Media-Name ]
     →*[ SDP-Media-Description ]
    [ Cause ]
     →{ Cause-Code }
     →{ Node-Functionality }
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Ericsson-Service-Information ]
     →[ Related-IMS-Charging-Identifier ]
     →[ Instance-Id ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ SIP-Request-Timestamp-Fraction ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
    [ SIP-Ringing-Timestamp ]
    [ Event-NTP-Timestamp ]

E-CSCF ACR (EVENT_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    *[ Called-Asserted-Identity ]
    [ Event-Type ]
     →[ SIP-Method ]
     →[ Event ]
     →[ Content-Type ]
     →[ Content-Length ]
     →[ Content-Disposition ]
    [ Role-of-Node ]
    [ User-Session-Id ]
    *[ Calling-Party-Address ]
    [ Called-Party-Address ]
    [ Time-Stamps ]
     →[ SIP-Request-Timestamp ]
     →[ SIP-Response-Timestamp ]
    [ Inter-Operator-Identifier ]
     →[ Originating-IOI ]
     →[ Terminating-IOI ]
    [ IMS-Charging-Identifier ]
    [ Cause ]
     →{ Cause-Code }
     →{ Node-Functionality }
    [ Served-Party-IP-Address ]
    [ Access-Network-Information ]
    [ Ericsson-Service-Information ]
     →[ Related-IMS-Charging-Identifier ]
     →[ Instance-Id ]
     →*[ IMS-Service-Identification ] 
     →[ Called-Party-Original-Address ]
     →[ SIP-Request-Timestamp-Fraction ]
     →[ SIP-Response-Timestamp-Fraction ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
    [ Event-NTP-Timestamp ]

5.1.1.2   Variant-2

S-CSCF ACR (START_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ Subscription-Id ]
     →→{ Subscription-Id-Type }
     →→{ Subscription-Id-Data }
     →[ IMS-Information ]
     →→[ Event-Type ]
     →→→[ SIP-Method ]
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Number-Portability-Routing-Information ]
     →→[ Carrier-Select-Routing-Information ]
     →→[ Requested-Party-Address ]
     →→[ Time-Stamps ]
     →→→[ SIP-Request-Timestamp ]
     →→→[ SIP-Response-Timestamp ]
     →→→[ SIP-Request-Timestamp-Fraction ]
     →→→[ SIP-Response-Timestamp-Fraction ]
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→*[ SDP-Session-Description ] 
     →→*[ SDP-Media-Component ] 
     →→→[ SDP-Media-Name ]
     →→→*[ SDP-Media-Description ]
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ]
     →→→{ Content-Type }
     →→→{ Content-Length }
     →→→[ Content-Disposition ]
     →→→[ Originator ]
     →→*[ Access-Network-Information ]
     →→[ IMS-Visited-Network-Identifier ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Dial-Around-Indicator ]
     →[ Authentication-Method ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ SIP-Ringing-Timestamp ]
     →[ Event-NTP-Timestamp ]

S-CSCF ACR (INTERIM_RECORD)

The AVPs identified with a "(note)" are present in a SIP re-INVITE or SIP UPDATE message triggered ACR (INTERIM_RECORD) only. They are absent in a time-based ACR (INTERIM_RECORD).

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ Subscription-Id ]
     →→{ Subscription-Id-Type }
     →→{ Subscription-Id-Data }
     →[ IMS-Information ]
     →→[ Event-Type ] (note)
     →→→[ SIP-Method ] (note)
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Time-Stamps ] (note)
     →→→[ SIP-Request-Timestamp ] (note)
     →→→[ SIP-Response-Timestamp ] (note)
     →→→[ SIP-Request-Timestamp-Fraction ] (note)
     →→→[ SIP-Response-Timestamp-Fraction ] (note)
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→*[ SDP-Session-Description ] (note) 
     →→*[ SDP-Media-Component ] (note) 
     →→→[ SDP-Media-Name ] (note)
     →→→*[ SDP-Media-Description ] (note)
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ] (note)
     →→→{ Content-Type }(note)
     →→→{ Content-Length }(note)
     →→→[ Content-Disposition ] (note)
     →→→[ Originator ] (note)
     →→*[ Access-Network-Information ] (note)
     →→[ IMS-Visited-Network-Identifier ]
     →→[ Related-IMS-Charging-Identifier ]
     →→[ Related-IMS-Charging-Identifier-Node ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Authentication-Method ]
     →*[ Transaction-Info ] (note) 
     →→{ Transaction-Type }(note) 
     →→{ Transaction-Data-Name }(note)
     →→*{ Transaction-Data-Value }(note)
     →[ SIP-Ringing-Timestamp ] (note)
     →[ Event-NTP-Timestamp ]

S-CSCF ACR (STOP_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ Subscription-Id ]
     →→{ Subscription-Id-Type }
     →→{ Subscription-Id-Data }
     →[ IMS-Information ]
     →→[ Event-Type ]
     →→→[ SIP-Method ]
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Time-Stamps ]
     →→→[ SIP-Request-Timestamp ]
     →→→[ SIP-Request-Timestamp-Fraction ]
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ]
     →→→{ Content-Type }
     →→→{ Content-Length }
     →→→[ Content-Disposition ]
     →→→[ Originator ]
     →→[ Cause-Code ] 
     →→*[ Reason-Header ]
     →→*[ Access-Network-Information ]
     →→[ IMS-Visited-Network-Identifier ]
     →→[ Related-IMS-Charging-Identifier ]
     →→[ Related-IMS-Charging-Identifier-Node ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Authentication-Method ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ Disconnect-Direction ]
     →[ Event-NTP-Timestamp ]

S-CSCF ACR (EVENT_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ User-Name ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ Subscription-Id ]
     →→{ Subscription-Id-Type }
     →→{ Subscription-Id-Data }
     →[ IMS-Information ]
     →→[ Event-Type ]
     →→→[ SIP-Method ]
     →→→[ Event ]
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Number-Portability-Routing-Information ]
     →→[ Carrier-Select-Routing-Information ]
     →→[ Requested-Party-Address ]
     →→[ Time-Stamps ]
     →→→[ SIP-Request-Timestamp ]
     →→→[ SIP-Response-Timestamp ]
     →→→[ SIP-Request-Timestamp-Fraction ]
     →→→[ SIP-Response-Timestamp-Fraction ]
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→*[ SDP-Session-Description ] 
     →→*[ SDP-Media-Component ] 
     →→→[ SDP-Media-Name ]
     →→→*[ SDP-Media-Description ]
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ]
     →→→{ Content-Type }
     →→→{ Content-Length }
     →→→[ Content-Disposition ]
     →→→[ Originator ]
     →→[ Cause-Code ] 
     →→*[ Reason-Header ]
     →→*[ Access-Network-Information ]
     →→[ IMS-Visited-Network-Identifier ]
     →→[ Related-IMS-Charging-Identifier ]
     →→[ Related-IMS-Charging-Identifier-Node ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →[ Dial-Around-Indicator ]
     →[ Authentication-Method ]
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ Event-NTP-Timestamp ]

E-CSCF ACR (START_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ IMS-Information ]
     →→[ Event-Type ]
     →→→[ SIP-Method ]
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Requested-Party-Address ]
     →→[ Time-Stamps ]
     →→→[ SIP-Request-Timestamp ]
     →→→[ SIP-Response-Timestamp ]
     →→→[ SIP-Request-Timestamp-Fraction ]
     →→→[ SIP-Response-Timestamp-Fraction ]
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→*[ SDP-Session-Description ] 
     →→*[ SDP-Media-Component ] 
     →→→[ SDP-Media-Name ]
     →→→*[ SDP-Media-Description ]
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ]
     →→→{ Content-Type }
     →→→{ Content-Length }
     →→→[ Content-Disposition ]
     →→→[ Originator ]
     →→*[ Access-Network-Information ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ SIP-Ringing-Timestamp ]
     →[ Event-NTP-Timestamp ]

E-CSCF ACR (INTERIM_RECORD)

The AVPs identified with a "(note)" are present in a SIP re-INVITE or SIP UPDATE message triggered ACR (INTERIM_RECORD) only. They are absent in a time-based ACR (INTERIM_RECORD).

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ IMS-Information ]
     →→[ Event-Type ] (note)
     →→→[ SIP-Method ] (note)
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Time-Stamps ] (note)
     →→→[ SIP-Request-Timestamp ] (note)
     →→→[ SIP-Response-Timestamp ] (note)
     →→→[ SIP-Request-Timestamp-Fraction ] (note)
     →→→[ SIP-Response-Timestamp-Fraction ] (note)
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→*[ SDP-Session-Description ] (note) 
     →→*[ SDP-Media-Component ] (note) 
     →→→[ SDP-Media-Name ] (note)
     →→→*[ SDP-Media-Description ] (note)
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ] (note)
     →→→{ Content-Type }(note)
     →→→{ Content-Length }(note)
     →→→[ Content-Disposition ](note)
     →→→[ Originator ] (note)
     →→*[ Access-Network-Information ] (note)
     →→[ Related-IMS-Charging-Identifier ]
     →→[ Related-IMS-Charging-Identifier-Node ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →*[ Transaction-Info ] (note) 
     →→{ Transaction-Type }(note) 
     →→{ Transaction-Data-Name }(note)
     →→*{ Transaction-Data-Value }(note)
     →[ SIP-Ringing-Timestamp ] (note)
     →[ Event-NTP-Timestamp ]

E-CSCF ACR (STOP_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    [ Destination-Host ]
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ IMS-Information ]
     →→[ Event-Type ]
     →→→[ SIP-Method ]
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Time-Stamps ]
     →→→[ SIP-Request-Timestamp ]
     →→→[ SIP-Request-Timestamp-Fraction ]
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ]
     →→→{ Content-Type }
     →→→{ Content-Length }
     →→→[ Content-Disposition ]
     →→→[ Originator ]
     →→[ Cause-Code ] 
     →→*[ Reason-Header ]
     →→*[ Access-Network-Information ]
     →→[ Related-IMS-Charging-Identifier ]
     →→[ Related-IMS-Charging-Identifier-Node ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ Event-NTP-Timestamp ]

E-CSCF ACR (EVENT_RECORD)

<ACR> ::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Event-Timestamp ]
    [ Service-Context-Id ]
    [ Service-Information ]
     →[ IMS-Information ]
     →→[ Event-Type ]
     →→→[ SIP-Method ]
     →→→[ Event ]
     →→[ Role-of-Node ]
     →→{ Node-Functionality }
     →→[ User-Session-Id ]
     →→*[ Calling-Party-Address ]
     →→[ Called-Party-Address ]
     →→*[ Called-Asserted-Identity ]
     →→[ Requested-Party-Address ]
     →→[ Time-Stamps ]
     →→→[ SIP-Request-Timestamp ]
     →→→[ SIP-Response-Timestamp ]
     →→→[ SIP-Request-Timestamp-Fraction ]
     →→→[ SIP-Response-Timestamp-Fraction ]
     →→[ Inter-Operator-Identifier ]
     →→→[ Originating-IOI ]
     →→→[ Terminating-IOI ]
     →→[ IMS-Charging-Identifier ]
     →→*[ SDP-Session-Description ] 
     →→*[ SDP-Media-Component ] 
     →→→[ SDP-Media-Name ]
     →→→*[ SDP-Media-Description ]
     →→[ Served-Party-IP-Address ]
     →→*[ Message-Body ]
     →→→{ Content-Type }
     →→→{ Content-Length }
     →→→[ Content-Disposition ]
     →→→[ Originator ]
     →→[ Cause-Code ] 
     →→*[ Reason-Header ]
     →→*[ Access-Network-Information ]
     →→[ Related-IMS-Charging-Identifier ]
     →→[ Related-IMS-Charging-Identifier-Node ]
     →→[ Instance-Id ]
    [ Ericsson-Service-Information ]
     →*[ IMS-Service-Identification ] 
     →*[ Transaction-Info ] 
     →→{ Transaction-Type } 
     →→{ Transaction-Data-Name }
     →→*{ Transaction-Data-Value }
     →[ Event-NTP-Timestamp ]

5.1.2   Accounting-Answer Message

The Accounting-Answer Message is sent by the CDF to the CTF to acknowledge one of the ACR specified in Section 5.1.1 Accounting-Request Message. The AVPs that are supported in an Accounting-Answer are listed in this section.

Each ACA must include either a Result-Code AVP or an Experimental-Result AVP. If both a Result-Code AVP and an Experimental-Result AVP exist in one ACA, then this ACA is considered as a valid ACA with the attached Result-Code AVP, and the attached Experimental-Result AVP in this ACA is neglected. If both the Result-Code AVP and the Experimental-Result AVP are missing, then the Charging session is terminated immediately without further ACRs transmission to the CDF. However the ongoing SIP service is not terminated.

The contents and AVP structure of the ACA message is applicable for both S-CSCF and E-CSCF.

The contents and AVP structure of the ACA message is applicable to both Variant-1 and Variant-2:

<ACA> ::= < Diameter Header: 271, PXY >
    < Session-Id >    
    { Result-Code }
    [ Experimental-Result ]
     →{ Vendor-Id }
     →{ Experimental-Result-Code }
    { Origin-Host }
    { Origin-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Acct-Interim-Interval ]

5.2   Attribute-Value Pairs

Table 3 and Table 4 list the following information:

• All AVPs applicable in ACR or ACA messages, or both, for Variant-1 ( Table 3) and Variant-2 ( Table 4) offline charging supports
• Vendor IDs

  The Vendor ID for Ericsson is 193

  The Vendor ID for 3GPP is 10415

  "-" indicates Diameter base protocol AVPs

• AVP codes
• AVP types
• ACR: the use of AVPs in ACR messages generated by CSCF:
  • Types

    Indicates whether the AVP is used in ACR messages with Accounting-Record-Type of Start Record, Interim Record, Stop Record, and Event Record.

  • Flags

    Indicates how the CSCF sets the Vendor-Specific, Mandatory, and Protected flags in the AVP header, refer to RFC 3588 Diameter Base Protocol.

  • Config

    Indicates whether the inclusion of the AVP in ACR messages is operator configurable.

  • Omit (only applicable for Variant-2 in Table 4)

    Indicates whether the omission of the AVP in all ACR messages is operator configurable.

• ACA:
  • Types

    Indicates whether the AVP is used in ACA messages received with Accounting-Record-Type of Start Record, Interim Record, Stop Record, and Event Record.

(1)  This is a grouped AVP and cannot be configured in Variant-1. Only displayed if the child AVP has been configured to True and its data is available.

(2)  This is a child AVP and its presence is not configurable. Only displayed if parent (grouped) AVP is configured to True.

A Diameter AVP header has the format as shown in Figure 11.

5.2.1   AVP Descriptions

The following sections provide information on all the Variant-1 and Variant-2 AVPs. Descriptions of Diameter Base Protocol AVPs and 3GPP Diameter Accounting AVPs are derived from RFC 3588 Diameter Base Protocol and 3GPP TS 32.299 V12.7.0 Diameter Charging Applications, respectively. The AVPs are listed in alphabetical order.

Unless it is specified explicitly, the information is applicable to both offline charging Variant-1 and Variant-2.

5.2.1.1   3GPP-SGSN-MCC-MNC

This AVP holds the Mobile Country Code and the Mobile Network Code used by an operator. The value is downloaded from the Home Subscriber Server (HSS) in the user profile.

The Mobile Country Code (MCC) consists of three digits and the Mobile Network Code (MNC) consists of two or three digits depend on the value of MCC.

Example:

23415

Where:

• 2=MCC digit 1
• 3=MCC digit 2
• 4=MCC digit 3
• 1=MNC digit 1
• 5=MNC digit 2

The value does not change during the Charging session.

This AVP is for offline charging Variant-1 only. The AVP length is is greater than 12.

5.2.1.2   Access-Network-Information

This AVP contains the content of the SIP P-header P-Access-Network-Information. If the P-Access-Network-Information header is not available in the request, the E-CSCF with a HTTP-based Ml interface can, depending on the configuration for the reference location information, query the HSS for the location information to use in the AVP.

The AVP value can be updated during a SIP session. For more information, refer to RFC 3455 Private Header Extensions to the SIP for the 3GPP.

Offline charging Variant-1 supports only one instance of this AVP in an ACR message. The value is obtained from the P-Access-Network-Information header in SIP requests of the served user.

Offline charging Variant-2 supports multiple instances of this AVP in an ACR for multiple SIP P-Access-Network-Information headers. The values are obtained from the P-Access-Network-Information headers in requests and responses of the served user of the respective CSCF node.

The AVP length is greater than 12.

5.2.1.3   Accounting-Record-Number

The AVP identifies this record within one Charging session or Charging event. It is an unsigned integer that starts with 0. It is incremented for each new record within the Charging session.

The AVP length is 12.

5.2.1.4   Accounting-Record-Type

This AVP contains the type of accounting record being sent.

Defined values:

• EVENT_RECORD 1

  Accounting Event Record is used to indicate that a one-time event has occurred, meaning that the start and end of the event are simultaneous. This record contains all information relevant to the service, and is the only record of the service.

• START_RECORD 2

  Start Record is used to initiate a Charging session, and contains Charging information that is relevant to the SIP session.

• INTERIM_RECORD 3

  An Interim Accounting Record contains cumulative Charging information for an existing Charging session. The selection of whether to use timer-based INTERIM_RECORD records is done by the Acct-Interim-Interval AVP.

• STOP_RECORD 4

  An Accounting Stop Record is sent to terminate a Charging session and contains cumulative Charging information relevant to the existing session.

The AVP length is 12.

5.2.1.5   Acct-Application-Id

This AVP is used to advertise support of the Accounting portion of an application and is displayed in every ACR. The value is set to 3 which is the application ID used by the Rf Interface. For more information, refer to 3GPP TS 32.299 V12.7.0 Diameter Charging Applications.

The AVP length is 12.

5.2.1.6   Acct-Interim-Interval

This AVP is sent from the CDF to the CSCF. The CSCF uses information in this AVP to decide if and when to produce timer-based Interim Charging messages.

The following charging procedure is directed by the inclusion of this AVP:

• The omission of the Acct-Interim-Interval AVP or its inclusion with Value field set to 0 in an ACA message received means that timer-based INTERIM_RECORDs are not sent by the CSCF.
• The inclusion of the AVP with Value field set to a non-zero value means that INTERIM_RECORD records must be produced between START_RECORD and STOP_RECORD records if the SIP session is long enough. The Value field of this AVP is the nominal interval between these Charging messages in seconds.

The AVP length is 12.

5.2.1.7   Authentication-Method

This AVP identifies the Authentication Method of the originating subscriber. This AVP is only contained in the ACR triggered by the Requests in the originating half call.

Possible values for the Authentication type:

• NoAuthentication = 0
• AkaAuthentication = 1
• NassBundledAuthentication = 2
• DigestAuthentication = 3
• SsoAuthentication = 4

Note:  

The authentication type NoAuthentication represents two cases: authentication disabled in the S-CSCF node and authentication enabled, but performed in a trusted gateway. DigestAuthentication includes both Digest and Optimized Digest authentications.

This AVP is for the S-CSCF only.

The AVP length is 16.

5.2.1.8   Called-Asserted-Identity

This AVP holds the SIP URI or tel URI or both addresses of the asserted called party. The address is obtained from the P-Asserted-Identity SIP header field of the 2xx responses corresponding to a SIP request either initiating a dialog or a standalone transaction. This field can appear several times in the request when the P-Asserted-Identity contains both a SIP URI and a tel URI.

The CSCF puts at most one SIP URI and at most one tel URI in the Called-Asserted-Identity. A maximum of two Called-Asserted-Identity AVP instances are supported.

In offline charging Variant-1, the value of Called-Asserted-Identity does not change during the Charging session.

In offline charging Variant-2 for S-CSCF, the value of the AVP is updated if it is changed in the P-Asserted-Identity header during the Charging session.

Example:

As SIP URI
sip: +46813200000@ericsson.com 
As Tel URI 
tel: +468132000000

The AVP length is greater than 12.

5.2.1.9   Called-Party-Address

This AVP holds the address (SIP URI or tel URI) of the party (Public User ID or Public Service ID) to whom the SIP transaction is posted. It includes all URI parameters separated by ";".

For the S-CSCF, if offline charging is triggered on the SIP Register message, the Called-Party-Address is obtained from the "To:" header. Otherwise, on the originating side, the Called-Party-Address is obtained from the Request-URI of the outgoing SIP message, and, on the terminating side, the Called-Party-Address is obtained from the Request-URI of the incoming SIP message.

For the E-CSCF, the value is obtained from the Request-URI of the outgoing SIP message. It can be a SIP URI, a tel URI, or a URN.

In offline charging Variant-1, the value of Called-Party-Address does not change during the Charging session.

In offline charging Variant-2 for the S-CSCF, the value of the AVP is updated if changed in the SIP message during the Charging session.

Example:

- As SIP URI:
sip: +46813200000@ericsson.com;user=phone
- As Tel URI:
tel: +468132000000

The AVP length is greater than 12.

5.2.1.10   Called-Party-Original-Address

The Called-Party-Original-Address AVP identifies the destination as received by the CSCF from the end user or an Application Server. It is present only if the Request-URI in the out-going request is modified.

The value of Called-Party-Original-Address does not change during the Charging session.

Since the Called-Party-Original-Address AVP is only valid on the originating side, it is not sent in a terminating Charging session.

This AVP is for offline charging Variant-1 only.

Example:

- As sip URI:
sip: +46813200000@ericsson.com;user=phone
- As Tel URI:
tel: +468132000000

The AVP length is greater than 12.

5.2.1.11   Calling-Party-Address

The Calling-Party-Address AVP identifies the originating user of the session.

For the S-CSCF, the originating user of the session is a SIP URI, tel URI, or both, if available, including possible parameters obtained from the P-Served-User header, applicable only for AS UAC cases, of a SIP message. If the P-Served-User header for an AS UAC case is not received, then it is obtained from the P-Asserted-Identity header of a SIP message. If it is not a P-Served-User header for AS UAC case, or a P-Asserted-Identity header is received, then the originating user of the session is obtained from the From header.

For the E-CSCF, it is a SIP URI, tel URI, or both, if available, including possible parameters.

If the HTTP-based Ml interface is configured, the originating user of the session is extracted from one of the three following headers received in the incoming request, according to the following priority order:

1. P-Asserted-Identity header
2. P-Preferred-Identity header
3. From header

If the SIP-based Ml interface is configured, when the ecscfNonRegAssertedCallerIdPreLrfEnabled parameter is set to false, the originating user of the session is extracted from one of the following three headers in the outgoing request to PSAP according to the following priority order:

1. P-Asserted-Identity header
2. P-Preferred-Identity header
3. From header

When the ecscfNonRegAssertedCallerIdPreLrfEnabled parameter is set to true, the originating user of the session is extracted from one of the following two headers in the outgoing request to PSAP according to the following priority order:

1. P-Asserted-Identity header
2. From header

For more information about the ecscfNonRegAssertedCallerIdPreLrfEnabled parameter, refer to the CSCF Common Parameter Description for the native CSCF and to the Managed Object Model (MOM) for the virtual CSCF.

In offline charging Variant-1, it is configurable whether to use the SIP URI or the tel URI, or both, if available.

Note:  

It is configurable by the parameters ScscfChargingPreferredCallingPartyAddress and EcscfChargingPreferredCallingPartyAddress for the S-CSCF and the E-CSCF, respectively. These parameters are deprecated and are available in offline charging Variant-1 only.

If the wanted type of address is not available, the existing type is used. A maximum of two Calling-Party-Address AVP instances are supported, containing a SIP URI and a tel URI.

In offline charging Variant-1, the value of Calling-Party-Address does not change during the Charging session.

In offline charging Variant-2, if both SIP URI and tel URI are available, then both are always used for Calling-Party-Address AVP generation.

In offline charging Variant-2 for the S-CSCF, the value of the AVP is updated if changed in the SIP message during the Charging session.

Example:

- As SIP URI:
sip:u000000.pub1@ericsson.com
- As Tel URI (either local or global):
tel: +468132000000

The AVP length is greater than 12.

5.2.1.12   Carrier-Select-Routing-Information

This AVP holds information on Carrier Select routing information received by an S-CSCF in an initial SIP request, within the Request-URI header, or from an ENUM response. The Carrier Select routing information is outputted in global format if the CIC Routing feature is enabled.

This AVP is for the S-CSCF only.

The AVP length is greater than 12.

5.2.1.13   Cause

This is a grouped AVP, including the Cause-Code AVP that contains the cause value and the Node-Functionality AVP that contains the function of the node where the cause code was generated.

Grammar:

 < Cause > ::=< AVP Header: 860 >
		{ Cause-Code }
		{ Node-Functionality }

This AVP is for offline charging Variant-1 only.

The AVP length is 44.

5.2.1.14   Cause-Code

The Cause-Code AVP is the cause code value from the CSCF node. It is used in ACR (STOP) and ACR (EVENT) messages.

In offline charging Variant-1, it is a mandatory sub-AVP of the Cause grouped AVP. For more information, refer to 3GPP TS 32.299 V6.0.0 Diameter Charging Applications.

In offline charging Variant-2, it is an optional sub-AVP of the IMS-Information grouped AVP. For more information, refer to 3GPP TS 32.299 Diameter Charging Applications release 12.

Within the cause codes, values less than or equal to 0 are reserved for successful causes while values greater than or equal to 1 are used for failure causes. In case of errors, where the SIP session has been terminated as a result of a specific known SIP error code, the SIP error code is also used as the cause code.

Successful cause-code values:

• "Normal end of session" 0

  The cause "Normal end of session" is used in Accounting-Request (STOP) message to indicate that an ongoing SIP session has been normally released 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).

• "Successful transaction" -1

  The cause "Successful transaction" is used in Accounting-Request (EVENT) message to indicate a successful SIP transaction, for example REGISTER, MESSAGE, NOTIFY, or SUBSCRIBE.

• "End of SUBSCRIBE dialog" -2

  The cause "End of SUBSCRIBE dialog" is used to indicate the closure of a SIP SUBSCRIBE dialog. The subscription terminates when a SIP NOTIFY with a Subscription-State header containing the value terminated is received.

• "2xx Final Response" -2xx

  The cause "2xx Final Response" is used to indicate the closure of a SIP transaction because of receiving/initiating a 2xx Final response (except 200).

• "3xx Redirection" -3xx

  The cause "3xx Redirection" is used when the SIP transaction is terminated because of an IMS node receiving/initiating a SIP 3xx response.

• "End of REGISTER dialog" -3

  The cause "End of REGISTER dialog" is used to indicate the closure of a SIP REGISTER dialog. For instance, a successful SIP REGISTER transaction terminating the dialog has been detected by the CSCF, for example, REGISTER with expire time set to 0).

Failure cause-code values:

• "Unspecified error" 1

  The cause "Un-normal termination" is used when the SIP transaction is terminated because of an unknown error. For example, a BYE is sent for both the Originating and Terminating sides because of a session time-out.

• "Unsuccessful session setup" 2

  The cause "Unsuccessful session setup" is used in the Accounting-Request (STOP) when the SIP session has not been successfully established, that is: Session Timer 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.

• "Internal error" 3

  The cause "Internal error" is used when the SIP transaction is terminated because of an IMS node internal error (for example, error in processing a request/response).

• "4xx Request failure" 4xx

  The cause "4xx Request failure" is used when the SIP transaction is terminated because of an IMS node receiving/initiating a SIP 4xx error response.

• "5xx Server failure" 5xx

  The cause "5xx Server failure" is used when the SIP transaction is terminated because of an IMS node receiving/initiating a SIP 5xx error response.

• "6xx Global failure" 6xx

  The cause "6xx Global failure" is used when the SIP transaction is terminated because of an IMS node receiving/initiating a SIP 6xx error response.

The AVP length is 16.

5.2.1.15   Content-Disposition

This AVP indicates how the SIP message body or a message body part is to be interpreted, for example, session, render, as described in 3GPP TS 32.299 V8.2.0 Diameter Charging Applications. The value of this AVP is fetched from the Content-Disposition Header.

The AVP length is greater than 12.

5.2.1.16   Content-Length

This holds the size of the SIP message body. The value of this AVP is fetched from the Content-Length header.

The AVP length is 16.

5.2.1.17   Content-Type

This holds the media type, for example, application/sdp, text/html, of the message-body. The value of this AVP is fetched from the Content-Type header.

The AVP length is greater than 12.

5.2.1.18   Destination-Host

This AVP is provided from the Origin-Host AVP in the ACA (START_RECORD) message. It identifies the CDF address to be used for this Charging session and therefore included in ACR (INTERIM_RECORD) and ACR (STOP_RECORD) messages.

Example:

neighbour1.remote.se

The AVP length is greater than 8.

5.2.1.19   Destination-Realm

This AVP contains the realm the ACR message is to be routed to. The Destination-Realm must be present in an ACR message.

For the S-CSCF, the value is extracted from the CCF address in the user profile downloaded from the HSS. If there is no user profile available, a local configured CCF address is used (refer to CSCF Charging Parameter Description).

For the E-CSCF, only the local configured CCF address is used.

Example:

remote.se

The AVP length is greater than 8.

5.2.1.20   Dial-Around-Indicator

This AVP identifies how the carrier specified in the Carrier-Select-Routing-Information AVP was selected. The value of the DAI parameter is included in this AVP.

The possible values of the AVP are identified in Internet Draft: DAI Parameter for the "tel" URI. If the CSCF receives a DAI parameter from the application server, it inserts the value into the AVP without modifying it. If the CSCF receives a CIC parameter from an ENUM server, it adds a DIA parameter with the value of operator.

This AVP is for the S-CSCF only.

The AVP length is greater than 12.

5.2.1.21   Disconnect-Direction

Disconnect-Direction reports which side, calling or called, initiated the termination of the session, or whether it was the reporting node itself that initiated the termination.

Defined values:

• 0 = Originating side
• 1 = Terminating side
• 2 = Network

This AVP is for the S-CSCF only.

The AVP length is 16.

5.2.1.22   Ericsson-Service-Information

The Ericsson-Service-Information AVP contains vendor-specific AVPs used in Ericsson IMS solutions.

In offline charging Variant-1, the grammar is as follows:

<Ericsson-Service-Information> ::=< AVP Header: 285, Vendor Id: 193>
  *[ IMS-Service-Identification ]
  [ Called-Party-Original-Address ]
  [ Dial-Around-Indicator ]
  [ Authentication-Method ]
  [ SIP-Request-Timestamp-Fraction ]
  [ SIP-Response-Timestamp-Fraction ]
  *[ Transaction-Info ]
  [ Disconnect-Direction ]
  [ Related-IMS-Charging-Identifier ]
  [ Instance-Id ]

In offline charging Variant-2, the grammar is as follows:

<Ericsson-Service-Information> ::=< AVP Header: 285, Vendor Id: 193>
  *[ IMS-Service-Identification ]
  [ Dial-Around-Indicator ]
  [ Authentication-Method ]
  *[ Transaction-Info ]
  [ Disconnect-Direction ]
  [ SIP-Ringing-Timestamp ]
  [ Event-NTP-Timestamp ]

The AVP length is greater than 24.

5.2.1.23   Event

This holds the content of the Event header used in event-based situations described in Section 3.5 Event-Based Charging if the header is present in the message.

Example:

presence

The AVP length is greater than 12.

5.2.1.24   Event-NTP-Timestamp

This is a time stamp recorded when the event that caused the ACR message to be sent was received in the CSCF. The value represents the number of seconds and milliseconds since 1 January 1900 00:00 UTC. The integer part is in the first four octets and the fraction part is in the last four octets. The format of the AVP is according to the NTP format as specified by RFC 2030. Event-NTP-Timestamp is always included by the CSCF in the ACR messages.

Example:

095c90c780000000

The AVP length is 20.

5.2.1.25   Event-Timestamp

This is a time stamp recorded when the event that caused the ACR message to be sent was received in the CSCF. The value represents the number of seconds since 1 January 1900 00:00 UTC. Event-Timestamp is always included by the CSCF in the ACR messages. This AVP is ignored when it is received in an ACA message.

Example:

095c90c7

The AVP length is 12.

5.2.1.26   Event-Type

This AVP contains information about the type of chargeable service/event for which the ACR message is generated. Event-Type is only in ACRs triggered by SIP requests.

In offline charging Variant-1, the grammar is as follows:

 < Event-Type > ::= <AVP Header: 823 >
		[ SIP-Method ]
		[ Event ]
		[ Content-Type ]
		[ Content-Length ]
		[ Content-Disposition ]

In offline charging Variant-2, the grammar is as follows:

<Event-Type> ::= <AVP Header: 823>
  	[ SIP-Method ]
	  [ Event ]

The AVP length is greater than 24.

5.2.1.27   Experimental-Result

This is a grouped AVP, including Experimental-Result-Code AVP that contains the result code value and the Vendor-Id AVP that contains the value assigned to the vendor of the Diameter application.

Grammar:

< Experimental-Result > ::=< AVP Header: 297 >
		{ Vendor-Id }		
		{ Experimental-Result-Code }

The AVP length is 32.

5.2.1.28   Experimental-Result-Code

This AVP is displayed only if the Experimental-Result AVP is received in ACA. It is used to transfer an indication to terminate the Charging session.

The CSCF terminates the Charging session immediately without sending any further ACRs on the value "4011 Diameter Accounting Not Applicable". The SIP session is not affected.

The Experimental-Result AVP is always assured that it is received with Vendor-ID equal to 193, that is Ericsson vendor-specific.

The CSCF ignores the Experimental-Result AVP containing any other value.

The AVP length is 12.

5.2.1.29   GPRS-Roaming-Status

The GPRS-Roaming-Status is used to indicate whether the user is attached to the home network.

The value is downloaded from the HSS.

• HOME 0
• VISITED 1

This AVP is for offline charging Variant-1 only.

The AVP length is 16.

5.2.1.30   IMS-Charging-Identifier

This is the IMS Charging Identifier (ICID) as generated by an IMS node for a SIP session or a SIP session-unrelated event.

At each SIP session establishment, that is, INVITE, a new session-specific ICID is generated at the first "session state aware" IMS network element that processes the session-initiating SIP INVITE message. This ICID is used in all SIP request messages during the session until the session is terminated.

At each SIP session unrelated method, for example, REGISTER, NOTIFY, MESSAGE, a new ICID is generated at the first IMS node that processes the method.

The ICID value is globally unique across all 3GPP IMS networks for at least a month as defined by 3GPP.

Example:

00000028003c06c830735

The AVP length is greater than 12.

5.2.1.31   IMS-Information

This grouped AVP allows the transmission of additional IMS service-specific information elements.

Grammar:

<IMS-Information> ::= <AVP Header: 876>

  	[ Event-Type ]
	   [ Role-of-Node ]
  	{ Node-Functionality }
  	[ User-Session-Id ]
	   *[ Calling-Party-Address ]
	   [ Called-Party-Address ]
	   *[ Called-Asserted-Identity ]
	   [ Number-Portability-Routing-Information ]
	   [ Carrier-Select-Routing-Information ]
	   [ Requested-Party-Address ]
	   [ Time-Stamps ]
	   [ Inter-Operator-Identifier ]
	   [ IMS-Charging-Identifier ]
	   *[ SDP-Session-Description ]
	   *[ SDP-Media-Component ]
	   [ Served-Party-IP-Address ]
	   *[ Message-Body ]
	   [ Cause-Code ]
	   *[ Reason-Header ]
	   *[ Access-Network-Information ]
	   [ IMS-Visited-Network-Identifier ]
	   [ Related-IMS-Charging-Identifier ]
	   [ Related-IMS-Charging-Identifier-Node ]
	   [ Instance-Id ]

This AVP is for offline charging Variant-2 only.

The AVP length is greater than 12.

5.2.1.32   IMS-Service-Identification

The IMS-Service-Identification AVP identifies the Communication Service or IMS Port related to session. One AVP is generated for each feature tag starting with "+g." or "+u." received in the Accept-Contact header of the SIP message. Feature tags are not always available; it depends on the actual service or terminal used, and it controls the presence of this AVP.

Example:

+g.ims.mmtel

The AVP length is greater than 12.

5.2.1.33   IMS-Visited-Network-Identifier

This AVP contains the visited network identification for the served user. The value corresponds to that of the P-Visited-Network-ID header in the SIP REGISTER message of the calling party in an originating half call or the called party in a terminating half call. The AVP value is updated when the P-Visited-Network-ID header value is changed, for example on User Equipment (UE) roaming.

This AVP is applied to all ACR types, START_RECORD, INTERIM_RECORD, STOP_RECORD, and EVENT_RECORD, that are associated with the served user.

This AVP is not generated for the called party if the SIP Contact header is not available in the 200 (OK) response to the SIP INVITE or if the called party is not registered.

This AVP is for offline charging Variant-2 only.

This AVP is for the S-CSCF only.

The AVP length is greater than 12.

5.2.1.34   Instance-Id

The Instance-Id AVP holds the value of the sip.instance media feature tag which is displayed as a "+sip.instance" Contact header field parameter of a request. If the sip.instance is not found, this AVP is not available.

In offline charging Variant-1, this AVP is for the E-CSCF only.

In offline charging Variant-2, this AVP is for both the S-CSCF and the E-CSCF.

Example:

urn:gsma:imei:90420156-025763-0

The AVP length is greater than 12.

5.2.1.35   Inter-Operator-Identifier

A globally unique identifier to share between operator networks, service providers, and content providers to correlate billing information generated within the IP Multimedia Subsystem. The value does not change during the Charging session.

Grammar:

< Inter-Operator-Identifier > ::=< AVP Header: 838 >
		[ Originating-IOI ]
		[ Terminating-IOI ]

The AVP length is greater than 16.

5.2.1.36   Message-Body

This is a grouped AVP holding information about the message bodies including user-to-user data. The message bodies do not include the bodies of Content-Type=”application-sdp” as these are captured in the SDP-Session-Description AVP and SDP-Media-Component AVP.

Grammar:

< Message-Body > ::=< AVP Header: 889 >
  { Content-Type }:	
  { Content-Length }:	
  [  Content-Disposition ]:	
  [  Originator  ]

This AVP is for offline charging Variant-2 only.

The AVP length is greater than 12.

5.2.1.37   Node-Functionality

This AVP contains the functionality identifier of the node.

In offline charging Variant-1, the values are as follows:

• S-CSCF 0
• E-CSCF 7

In offline charging Variant-2, the values are as follows:

• S-CSCF 0
• E-CSCF 11

The AVP length is 16.

5.2.1.38   Number-Portability-Routing-Information

This AVP holds information on Number Portability routing information received by the S-CSCF in an initial SIP request, within the Request-URI header, or from an ENUM response. The Number Portability routing information is outputted in global format if the Generic Number Portability feature is enabled.

This AVP is for the S-CSCF only.

The AVP length is greater than 12.

5.2.1.39   Origin-Host

The Origin-Host AVP contains the identification of the source point of the operation and the realm of the operation originator.

In the ACR, it identifies the CSCF that originated the Charging message and must be present in all Diameter Charging messages. The Origin-Host is a configurable value in the CSCF.

In the ACA, it is the Diameter-Identity of the CCF.

Example:

scscf.ericsson.se

The AVP length is greater than 8.

5.2.1.40   Origin-Realm

The Origin-Realm AVP contains the Realm of the originator of any Diameter message and must be present in all messages.

The Origin-Realm is a configurable value in the CSCF.

Example:

ericsson.se

The AVP length is greater than 8.

5.2.1.41   Originating-IOI

This is the Inter-Operator Identifier for the originating network as generated by the CSCF in the home network of the originating end user. The value of this AVP is fetched from the local configuration when the CSCF is in the originating home network. Otherwise it is fetched from the P-Charging-Vector header, if available.

On the terminating side, the Originating-IOI is taken from P-Charging-Vector header. If that is not available, the Originating-IOI is taken from the previously stored Originating-IOI value.

Example:

home1.se

The AVP length is greater than 12.

5.2.1.42   Originator

This is a sub-AVP of the Message-Body grouped AVP. It indicates the originating party of the message body.

The Originator AVP is generated only for message bodies received in SIP messages. The CSCF does not generate the AVP for message bodies generated by the node itself.

Defined values:

• Calling Party: 0
• Called Party: 1

This AVP is for offline charging Variant-2 only.

The AVP length is 16.

5.2.1.43   PS-Information

This AVP is used to carry additional 3GPP PS-specific information.

Grammar:

< PS-Information > ::= < AVP Header: 874 >
		[ 3GPP-SGSN-MCC-MNC ]

This AVP is for offline charging Variant-1 only.

The AVP length is greater than 24.

5.2.1.44   Reason-Header

This AVP contains the content of the Reason-header in the SIP BYE and CANCEL. Multiple AVP instances are generated if there are multiple Reason-headers within a SIP BYE or CANCEL.

This AVP is for offline charging Variant-2 only.

The AVP length is greater than 12.

5.2.1.45   Related-IMS-Charging-Identifier

The Related-IMS-Charging-Identifier AVP holds the Related IMS Charging Identifier (ICID) as included in the P-Charging-Vector header.

For example, it is used for the target access leg of a Single Radio Voice Call Continuity (SRVCC) access transfer. Upon receipt of the INVITE from the Charging Server (CS) access network, Service Centralization and Continuity Application Server (SCC AS), or Emergency Access Transfer Function (EATF) serving as a Back-to-Back User Agent (B2BUA) sends a re-INVITE towards the S-CSCF or the E-CSCF, respectively, for updating the established SIP session. SCC AS or EATF include both IMS-Charging-Identifiers of the PS access network and the CS access network in the P-Charging-Vector header of the re-INVITE. The IMS-Charging-Identifiers of the CS access network are included as the Related-IMS-Charging-Identifier in the P-Charging-Vector header.

The Related-IMS-Charging-Identifier value is globally unique across all 3GPP IMS networks for at least a month as defined by 3GPP.

In offline charging Variant-1, this AVP is for the E-CSCF only.

In offline charging Variant-2, this AVP is for both the S-CSCF and the E-CSCF.

Example:

00000028003c06c830756

The AVP length is greater than 12.

5.2.1.46   Related-IMS-Charging-Identifier-Node

This AVP holds the address of the node that generated the Related-IMS-Charging-Identifier, for more information refer to 3GPP TS 32.299 V8.2.0 Diameter Charging Applications.

The CSCF node obtains the value from the related-icid-generated-at parameter of the P-Charging-Vector header.

This AVP is for offline charging Variant-2 only.

Example:

192.0.6.8

The AVP length is greater than 12.

5.2.1.47   Requested-Party-Address

This AVP identifies the destination as received by the CSCF from the end user or an Application Server. The AVP holds the SIP URI or tel URI contained in the Request-URI of the incoming request. It has the same content and use as the Ericsson-specific Called-Party-Original-Address AVP in offline charging Variant-1.

It is only valid on the originating side and present only if the Request-URI of the incoming request differs from the Called-Party-Address. It is not sent in a terminating Charging session.

This AVP is for offline charging Variant-2 only.

Example:

- As sip URI
sip: +46813200000@ericsson.com;user=phone
- As Tel URI 
tel: +468132000000

The AVP length is greater than 12.

5.2.1.48   Result-Code

This indicates whether a particular request was completed successfully or whether an error occurred. All Diameter ACA messages defined must include one Result-Code AVP or one Experimental-Result-Code. Table 5 describes the classes of errors provided by RFC 3588 Diameter Base Protocol and the actions taken by the CSCF for each error class.

Buffering action is described in Section 3.9 Error Handling.

Any CSCF action "Charging Session Termination" does not terminate the ongoing SIP service.

For detailed examples for each class of error, refer to section Result-Code AVP in RFC 3588 Diameter Base Protocol.

The AVP length is 12.

5.2.1.49   Role-of-Node

This AVP specifies the role of a SIP IP Multimedia node. If establishing a dialogue in the network, the CSCF stores information describing its role within the dialogue (orig/term). The role of the node is defined at establishment of the SIP Dialogue. The node keeps the same role throughout the whole SIP Dialogue; it does not change because of the direction of the current SIP transaction.

The identifier can be one of the following:

• ORIGINATING_ROLE 0
• TERMINATING_ROLE 1
• Not used 2–3

The AVP length is 16.

5.2.1.50   SDP-Media-Component

This AVP contains information about media used for an IMS session.

In offline charging Variant-1, this AVP is present in ACRs triggered by SIP messages containing SDP data or in time-based ACRs (INTERIM_RECORD) if SDP media is available in cache.

In offline charging Variant-2, this AVP is displayed only in ACRs triggered by SIP messages containing SDP data.

Grammar:

< SDP-Media-Component > ::=< AVP Header: 843 >
		[ SDP-Media-Name ]
		*[ SDP-Media-Description ]

The AVP length is greater than 24.

5.2.1.51   SDP-Media-Description

This AVP holds the content of an attribute-line (i=, c=, b=, k=, a=, and so on) related to a media component, as described in RFC 3261 SIP: Session Initiation Protocol. The attributes are specifying the media described in the SDP-Media-Name AVP.

Example:

a=rtpmap: 109 AMR/8000/1

The AVP length is greater than 12.

5.2.1.52   SDP-Media-Name

This AVP holds the content of "m=" line in the SDP data (refer to RFC 2327 SDP Session Description Protocol).

Example:

m=audio 5002 RTP/AVP 109

The AVP length is greater than 12.

5.2.1.53   SDP-Session-Description

This AVP holds the content of an attribute-line (i=, c=, b=, k=, a=, and so on) related to a session, as described in RFC 2327 SDP Session Description Protocol.

In offline charging Variant-1, this AVP is present in ACRs triggered by SIP messages containing SDP session data or in time-based ACRs (INTERIM_RECORD) if SDP session data is available in cache.

In offline charging Variant-2, this AVP is displayed only in ACRs triggered by SIP messages containing SDP session data.

The AVP length is greater than 12.

5.2.1.54   Served-Party-IP-Address

This AVP holds the IP address of the calling party from the SIP Via header. It is transferred to the Charging system of the IMS only from the originating CSCF. The calling party can either be an end-user terminal, an Application Server in the served network, or an External Network interface.

In offline charging Variant-1, the AVP value does not change during the Charging session.

In offline charging Variant-2 for S-CSCF, the AVP value is updated if the calling party address is changed in the SIP message during the Charging session.

The AVP length is 18 or 30.

5.2.1.55   Service-Context-Id

This AVP identifies the service-specific document ("middle tier") Traffic Server (TS) on which associated CDRs should be based. The AVP value is operator configured in the following format: “extensions”.MNC.MCC.”Release”.”service-context” “@” “domain”

The 3GPP specific value for “service-context” “@” “domain” for IMS Charging is as follows:

	32260@3gpp.org

For more information on the value and format, refer to 3GPP TS 32.299 V8.2.0 Diameter Charging Applications.

This AVP is for offline charging Variant-2 only.

The AVP length is greater than 12.

5.2.1.56   Service-Information

The purpose of the Service-Information AVP is to allow the transmission of additional 3GPP service-specific information elements.

In offline charging Variant-1, the grammar is as follows:

< Service-Information > ::= < AVP Header: 873 >

		[ PS-Information ]

In offline charging Variant-2, the grammar is as follows:

< Service-Information > ::= < AVP Header: 873 >

[ Subscription-Id ]
[ IMS-Information ]

The AVP length is greater than 24.

5.2.1.57   Session-Id

The Session-Id AVP is used to identify a specific session. All messages pertaining to a specific session must include only one Session-Id AVP. The Session-Id does not change during the Charging session. The Session-Id is created by the CSCF initiating the Charging session.

Grammar:

< DiameterIdentity >;< Unique string>

DiameterIdentity = configured CSCF domain name.

Unique string = CSCF generated globally unique (over space and time) string.

Note:  

This is a string with a maximum of 24 octets.

Example:

cscf.abcdef.com;46d7f635;049cca;2286243985

The AVP length is greater than 35.

5.2.1.58   SIP-Method

This is the name of the SIP Method, INVITE, UPDATE, and so on, causing an ACR to be sent to the CDF.

The AVP length is greater than 12.

5.2.1.59   SIP-Reason

SIP-Reason AVP contains parameters from the SIP Reason header is displayed in SIP BYE and SIP CANCEL requests. SIP Reason Header Field is defined in 3GPP TS 32.299 v6.3.0 Diameter Charging Applications.

Grammar:

< SIP-Reason >:= < AVP Header: xxx, Vendor Id: 193 >
[ SIP-Reason-Cause ]
[ SIP-Reason-Text ]

This AVP is for offline charging Variant-1 only.

The AVP length is greater than 40.

5.2.1.60   SIP-Reason-Cause

The SIP-Reason-Cause AVP contains the value of the cause parameter in the Reason header.

Example:

480

This AVP is for offline charging Variant-1 only.

The AVP length is 16.

5.2.1.61   SIP-Reason-Text

The SIP-Reason-Text contains the value of the reason-text parameter in the SIP Reason header.

Example:

Called User Unregistered

This AVP is for offline charging Variant-1 only.

The AVP length is greater than 12.

5.2.1.62   SIP-Request-Timestamp

This AVP holds the time of the triggering SIP request, for example, INVITE and UPDATE, identified in SIP Method AVP, presented in UTC format. The value represents the number of seconds, without rounding, since 1 January 1900 00:00 UTC.

Example:

c8aa5abd

The AVP length is 16.

5.2.1.63   SIP-Request-Timestamp-Fraction

This AVP holds the milliseconds fraction in relation to SIP-Request-Timestamp. Together with SIP-Request-Timestamp, these two AVPs represent the number of seconds and milliseconds since 1 January 1900 00:00 UTC.

Example:

00000338

The AVP length is 16.

5.2.1.64   SIP-Response-Timestamp

This AVP holds the time of the response to the triggering SIP request, for example 200 (OK), identified in the SIP Method AVP, presented in UTC. The value represents the number of seconds, without rounding, since 1 January 1900 00:00 UTC.

Example:

c8aa5abd

The AVP length is 16.

5.2.1.65   SIP-Response-Timestamp-Fraction

This AVP holds the milliseconds fraction in relation to SIP-Response-Timestamp. Together with SIP-Response-Timestamp, these two AVPs represent the number of seconds and milliseconds since 1 January 1900 00:00 UTC.

Example:

0000034c

The AVP length is 16.

5.2.1.66   SIP-Ringing-Timestamp

The AVP contains the time on reception of the first SIP 180 (Ringing). The given time is presented in seconds since 1 January 1900 00:00 UTC.

Example:

095c90c7

The AVP length is 16.

5.2.1.67   Subscription-Id

The Subscription-Id AVP is used to identify the subscription of the served end user. The Subscription-Id AVP includes a Subscription-Id-Data AVP that holds the identifier and a Subscription-Id-Type AVP that defines the identifier type. Only one instance exists in an ACR.

Grammar:

< Subscription-Id > ::= < AVP Header: 443 >
{ Subscription-Id-Type }
{ Subscription-Id-Data }

This AVP is for the S-CSCF only.

The AVP length is greater than 28.

5.2.1.68   Subscription-Id-Data

The Subscription-Id-Data AVP is used to identify the end user. The identifier is fetched from the user profile from the HSS over the Cx interface. Only data in E.164 format is supported.

Example:

467190037

The AVP length is greater than 8.

5.2.1.69   Subscription-Id-Type

The Subscription-Id-Type AVP is used to determine which type of identifier is carried by the Subscription-Id-Data AVP. Only E.164 type is supported.

Defined values:

• END_USER_E164 0
• Not used 1 &mldr; 4

The AVP length is 12.

5.2.1.70   Terminating-IOI

This is the Inter-Operator Identifier for the terminating network as generated by the CSCF in the home network of the terminating end user. The value of this AVP is fetched from the local configuration when the CSCF is in the terminating home network. Otherwise, it is fetched from the P-Charging-Vector header, if available.

On the originating side, the Terminating-IOI is taken from P-Charging-Vector header, if not available, the Terminating-IOI is taken from previously stored Terminating-IOI value from the incoming 2xx messages.

Example:

neighbor.se

The AVP length is greater than 12.

5.2.1.71   Time Stamps

This grouped AVP holds the time of the SIP request and the time of the response to the SIP Request.

In offline charging Variant-1, the grammar is as follows:

< Time-Stamps > ::=< AVP Header: 833 >
		[ SIP-Request-Timestamp ]
		[ SIP-Response-Timestamp ]

In offline charging Variant-2, the grammar is as follows:

< Time-Stamps > ::=< AVP Header: 833 >
		[ SIP-Request-Timestamp ]
		[ SIP-Response-Timestamp ]
		[ SIP-Request-Timestamp-Fraction ]
		[ SIP-Response-Timestamp-Fraction ]

The AVP length is greater than 24.

5.2.1.72   Transaction-Data-Name

Transaction-Data-Name identifies the name of the selected data, typically a header, or an element in a message.

Example:

Contact

The AVP length is greater than 12.

5.2.1.73   Transaction-Data-Value

Transaction-Data-Value contains the value of the selected data based on Transaction-Data-Name.

Example:

sip:bob@192.0.100.2

The AVP length is greater than 12.

5.2.1.74   Transaction-Info

Transaction-Info is a grouped AVP, including:

• Transaction-Type AVP which contains the type of transaction in interest.
• Transaction-Data-Name AVP which contains the name of the transaction data.
• Transaction-Data-Value AVP which contains the value of the transaction data named in the Transaction-Data-Name AVP.

Grammar:

<Transaction-Info> ::= < AVP Header: 1264, Vendor Id: 193 >
       { Transaction-Type }			
       { Transaction-Data-Name }
    1*{ Transaction-Data-Value }

The AVP length is greater than 52.

5.2.1.75   Transaction-Type

Transaction-Type is the type of transaction the related information is captured from. It is an enumerated AVP.

Defined values:

• 0 = SIP Request
• 1 = SIP Final Response
• 2 = SIP Provisional Response (SIP 18X)

SIP Provisional Response value is supported for emergency calls, E-CSCF only. It applies to the ACR Start message only.

For multiple Provisional 18X response cases followed by the successful final SIP response, the E-CSCF reports all responses in multiple Transaction-Data-Value AVP instances in the same order as they have been received.

The AVP length is 16.

5.2.1.76   User-Name

This AVP contains the private user identity, assigned by the home network. If the private identity of the user is not known in the CSCF node in question, then this attribute is not sent. The User-Name data is fetched from the user profile from the HSS over the Cx interface. The value does not change during the Charging session.

Example:

userA@domain_name.com

The AVP length is greater than 8.

5.2.1.77   User-Session-ID

This is the user session identifier sent to the Diameter in the form of: SIP Call-ID, as described in RFC 3588 Diameter Base Protocol. The value of this AVP is fetched from the Call-ID header.

Example:

b68-c9-76f41@134.138.157.154

The AVP length is greater than 12.

5.2.1.78   Vendor-ID

This AVP is displayed only if the Experimental-Result AVP is received in ACA. It contains the vendor-specific code. Only Ericsson vendor-specific code (193) is supported. All other codes received not equal to 193 are discarded and the corresponding Experimental-Result AVP is ignored.

The AVP length is 12.

6   Security Considerations

Note:  

It is possible to configure the CSCF to run the Rf Charging interface separated from other interfaces such as the traffic interface. For more information, refer to Virtual IP Interface and Virtual IP User Guide.

6.1   IPsec Tunnel

The communication between the S-CSCF and the Charging system can be secured using IPsec, Zb interface, on the IP transport layer. Refer to the 3GPP TS 33.210 3G security; Network Domain Security (NDS); IP network layer security specification:

IP Security (IPsec) tunnels can be defined between the two nodes. Internet Key Exchange version 1 (IKEv1) performs mutual authentication between the two nodes and establishes an IKE Security Association that includes shared secret information used to establish IPsec Security Associations (SAs). Different forms of authentication and encryptions can be selected when defining the IPsec tunnels. For the native CSCF, refer to Security Management User Guide, and for the virtual CSCF, refer to eVIP Management Guide.

7   Related Standards

The offline charging implementation is compliant with the mandatory parts of the RFC 3588 Diameter Base Protocol, 3GPP TS 32.299 v6.3.0 Diameter Charging Applications, and 3GPP TS 32.299 V12.7.0 Diameter Charging Applications specifications.

All other parts that are relevant for the offline charging function in the CSCF are supported with the following comments:

• For RFC 3588 Diameter Base Protocol IPsec or TLS is not supported
• For 3GPP TS 32.260, 3GPP TS 32.260 v6.2.0 IP Multimedia Subsystem (IMS) Charging and 3GPP TS 32.260 V12.6.0 IP Multimedia Subsystem (IMS) Charging and for 3GPP TS 32.299, 3GPP TS 32.299 v6.3.0 Diameter Charging Applications, and 3GPP TS 32.299 V12.7.0 Diameter Charging Applications, refer to CSCF Statement of Compliance Overview.

The AVP grammar used in this document is compliant to the RFC 3588 Diameter Base Protocol specification.