top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter Credit Control Application--Issue during CCR-Update

+1 vote
529 views

We are facing a problem with Diameter Credit Control Application:

Diameter client sends a CCR-update message to server,but server does not respond to the request. Now,as client is configured with session failover, it will send CCR-update to backup server. In this update message, Destination Host AVP is not being included. (???) Hence, in same destination realm, this request is forwarded to random peer. This random peer is responding with failure message as "Diamater Unable to Comply". Whats wrong here..?? (in rfc 4006, I'm not able to track this kind of scenario!)

posted May 17, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

Hard to know since we do not have further information of the message contents and deployment details. The error you received is due the server not knowing what to do with the received request for an application it supports. I would have expected to see e.g. DIAMETER_UNKNOWN_SESSION_ID, though. I am _not_ a "CCR expert" but unless the primary and backup server share the session state, sending an update to a random server is obvious to fail. There is no such state change in the CCR state machine afaik (after a very quick look).

In RFC4006 Section 7 there is an explicit text stating:
In the following state machine table, the failover to a secondary server upon 'Temporary error' or 'Failure to send' is not explicitly described. Moving an ongoing credit-control message stream to an alternative server is, however, possible if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, as described in section 5.7.

Re-sending a credit-control event to an alternative server is supported as described in section 6.5.

In Section 6.5 it says:
Failover to an alternative credit-control server is allowed for a one time event, as the server is not maintaining session states.

Since your client is sending updates, I assume you are operating in a session-based credit-control mode, right? Sending an update to a backup server would cause an error and your client would be misbehaving.

In Section 5.7 it says:
If a failure occurs during an ongoing credit-control session, the credit-control client may move the credit-control message stream to an alternative server if the CC-server indicated FAILOVER_SUPPORTED in the CC-Session-Failover AVP. A secondary credit-control server name, either received from the home Diameter AAA server or configured locally, can be used as an address of the backup server. If the CC- Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the credit-control message stream MUST NOT be moved to a backup server.

Are these conditions met before sending the update to a random backup server?

answer May 19, 2013 by anonymous
Similar Questions
+5 votes

State the difference between Diameter Credit Control Applications and Ro applications with reference to Diameter protocol?

+3 votes

I'm doing some integration toward Gy client (PCEF), and encountered an unclear area. I'm not sure if it is unclear in RFC 4006 or the 3GPP TS32.299 or both.

Scenario: A user logs on. The user has no credit left for a rating-group 42.

CCR-initial and CCA-initial:
Nothing interesting. In Gy it is typically just "empty" requests for the purpose of registering the user session.

The user then attempts to use rating-group 32:

CCR-update:

 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Requested-Service-Unit {
 }
 }

to which the OCS (Gy server) would normally respond:

CCA-update:

 Result-Code = 2001 (success)
 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Result-Code = 4012 (credit-limit-reached)
 Final-Unit-Indication {
 ...
 }
 }

However, the Gy specification says that a zero-grant is needed, which to me sounds a bit odd, but nevertheless:

Result-Code = 2001 (success)
 Multiple-Services-Credit-Control {
 Rating-Group = 42
 Result-Code = 4012 (credit-limit-reached)
 Granted-Service-Unit {
 CC-Total-Octets = 0
 }
 Final-Unit-Indication {
 ...
 }
 }

Now, the Gy client vendor says that the result-code inside the MSCC must be 2001 (success). It sort of makes sense because there is a grant.

But that made me wonder: In which case would result-code=4012 make sense? Is it just 3GPP who has "mangled" diameter-credit-control in the Gy application?

+2 votes

PGW sending a USU of 0 in CCR Updates after the first USU in first CCA Update was sent correctly. GSU from PCRF is 10Mb.

...