Subject: [AAA-WG]: One off Accounting Events in an Accounting Session

From: "Ian Elz" <[email-masked]>
Date: Thu, 21 Oct 2004 09:40:06 +0100

I have been studying the Diameter Base Protocol RFC (RFC 3588) and wish to
determine if it is possible to send 'one off' Accounting  transactions with
in an open Diameter session.

Section 9.8.1 of RFC3588 states that there are 4 different
Accounting-Record-Type AVP values

      EVENT_RECORD
      START_RECORD
      INTERIM_RECORD
      STOP_RECORD

After starting a Diameter Session using the START_RECORD value is it
possible to send  additional 'one off' transactions within the same session
? The Session will use INTERIM_RECORDs to update cumulative data that gets
overwritten, as specified within the RFC, but I have a requirement to be
able to send one or more transactions within the same session relating to
cumulative data that does not get overwritten, and for which
INTERIM_RECORDs are therefore inappropriate.

The current belief is that this is not possible and that the use of the
Accounting-Sub-Session-Id AVP will be required with the conventional data
being passed in one sub-session (possibly sub-session 0) and each of the
new transactions being sent in a separate sub-session with
Accounting-Record-Type EVENT_RECORD.

Can I have confirmation as to whether this is the correct approach?

Furthermore, it would appear that it is necessary to know in advance that
you are going to use sub-sessions. The RFC says that the absence of the
Accounting-Sub-Session-Id AVP implies that no sub-sessions are in use. This
means that it is not possible to start a session without the presence of
the sub-session AVP and subsequently start using sub-sessions as it is not
possible to send INTERIM_RECORDs on the original session without implying
that no sub-sessions are in use.

Is this interpretation of the specification correct?

Ian Elz

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Oct 2004 12:37:57 +0300

> INTERIM_RECORDs are therefore inappropriate.

Ok.

> Accounting-Record-Type EVENT_RECORD.

You could do this, or you could also have the conventional data
as the top level records (no sub session AVP) and then every time
you have some transactions you send a single EVENT_RECORD with
the sub session AVP set to value.

> that no sub-sessions are in use.

Hmm... perhaps the language is a bit unclear. My interpretation
of the intent of the text is that if you send a record without
the sub session AVP then that record does not belong to a sub
session (no subsessions are in use for THIS record), but
that other sub sessions could still be in progress. But if
you send the STOP_RECORD for the top-level session then it
also implicitly closes all subsessions.

What do others think?

--Jari