Subject: [AAA-WG]: Questions about draft-hakala-diameter-credit-control-01.txt

From: <[email-masked]>
Date: Mon, 18 Mar 2002 13:27:09 +0200

Hi,

I have few questions about this diameter-credit-control -draft...

About this spontaneous updating which was already discussed here earlier.
I still think that there will be cases where the spontaneous Interim_record trigger is needed from client to server. This could be caused by tariff change time or QoS changes. 
Because this was not accepted to the diameter base, should it be mentioned in this credit-control -draft?

In the several interrogation scenario it is stated that only one Unit-type 
must be used. It would also be useful to give the possibilities to send at least two Unit-type during a credit control session for example time and volume so as the first 
condition met is reported. This would enable charging model where is expected to send 
only a certain amount of data volume in a given time, if the volume is exceeded the 
user would pay more.

In 3GPP network we might have a number of accounting sessions and events 
related to the same SIP session or used service coming from different network 
elements/servers. How can we correlate this sessions/events? Maybe a new AVP is needed to transport a correlation identifier, if we refer to e.g. IMS this could be the "charging correlation vector".

In chapter 5.15 Time stamp indicate the time when the service is requested. 
What happen with the time stamp in several interrogation scenario? Is this always the time stamp of the first ACR or..? This should be clarified in the document, just in case.

Br,
JPK