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

From: "STURA Marco Consultant" <[email-masked]>
Date: Thu, 21 Oct 2004 14:05:13 +0200

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

[MSt] This is my interpretation as well.

Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jari Arkko
Sent: Thursday, October 21, 2004 11:38 AM
To: Ian Elz
Cc: [email-masked]
Subject: Re: [AAA-WG]: 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

---

From: <[email-masked]>
Date: Thu, 21 Oct 2004 15:40:36 +0300

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

This is my interpretation as well.

John