Subject: Re: [AAA-WG]: Diameter CCA protocol: uncovered scenarios

From: "Harri Hakala (LMF)" <[email-masked]>
Date: Tue, 19 Mar 2002 09:07:31 +0100

Hi,

answers inline.

/Harri

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?

>>>> Yes. I think that spontaneous updating is needed. I will add statement 
that in case of spontaneous updating (mid-session events) a new Accounting-Request 
should be sent even if all the granted service units have not spent or the accounting 
interim interval has not expired.

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.

>>>>we put this restriction to avoid service to be too complex.
If we allow several unit types during a credit control session (simultaneously)
we should also report several unit-types (used-service units) when the first
condition is met and let server to decide how to charge the service.
I can update this.

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".
>>>> I see your point. I can add a new AVP.

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.
>>>> I will clarify. In the first request (START) it indicates the time when
service is requested and other requests it indicates the time of the event that
triggered the sending of the ACR.