Subject: [Dime] Diameter Credit Control Application--Issue during CCR-Update

From: Kamal Kotecha <[email-masked]>
Date: Fri, 17 May 2013 14:47:35 -0700 (PDT)

Hi Folks, 
We are facing a problem with Diameter Credit Control Application: 
Problem discription: 
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!)
Regards,
Kamal Kotecha

Kamal Kotecha
Wirefree Num:+91 9725683242

---

From: Jouni <[email-masked]>
Date: Sun, 19 May 2013 21:53:28 +0300

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

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?

- JOuni

On May 18, 2013, at 12:47 AM, Kamal Kotecha wrote:

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime