Re: : One off Accounting Events in an Accounting Session

Ian Elz wrote:

> 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.

Ok.

> 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.

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.

> 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.

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