Re: [Dime] Route-Record in CCA

["Gowda, Avinash" <agowda at starentnetworks.com>]

Hi Ravi,

 

Following section in RFC 3588 will answer your question.

 

2.10. Diameter Path Authorization

Similarly, the local Diameter agent, on receiving a Diameter response

authorizing a session, MUST check the Route-Record AVPs to make sure

that the route traversed by the response is acceptable. At each

step, forwarding of an authorization response is considered evidence

of a willingness to take on financial risk relative to the session.

A local realm may wish to limit this exposure, for example, by

establishing credit limits for intermediate realms and refusing to

accept responses which would violate those limits. By issuing an

accounting request corresponding to the authorization response, the

local realm implicitly indicates its agreement to provide the service

indicated in the authorization response. If the service cannot be

provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error

message MUST be sent within the accounting request; a Diameter client

receiving an authorization response for a service that it cannot

perform MUST NOT substitute an alternate service, and then send

accounting requests for the alternate service instead.

 

Thanks,

Avinash Gowda

---

From: dime-bounces at ietf.org [mailto:dime-bounces at ietf.org] On Behalf Of Ravi
Sent: Tuesday, March 10, 2009 10:52 PM
To: dime at ietf.org
Subject: [Dime] Route-Record in CCA

 

Hi,

   As per RFC  4006, the CCA message has the following ABNF format

 

<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >

                                  < Session-Id >

                                  { Result-Code }

                                  { Origin-Host }

                                  { Origin-Realm }

                                  { Auth-Application-Id }

                                  { CC-Request-Type }

                                  { CC-Request-Number }

                                  [ User-Name ]

                                  [ CC-Session-Failover ]

                                  [ CC-Sub-Session-Id ]

                                  [ Acct-Multi-Session-Id ]

                                  [ Origin-State-Id ]

                                  [ Event-Timestamp ]

                                  [ Granted-Service-Unit ]

                                 *[ Multiple-Services-Credit-Control ]

                                  [ Cost-Information]

                                  [ Final-Unit-Indication ]

                                  [ Check-Balance-Result ]

                                  [ Credit-Control-Failure-Handling ]

                                  [ Direct-Debiting-Failure-Handling ]

                                  [ Validity-Time]

                                 *[ Redirect-Host]

                                  [ Redirect-Host-Usage ]

                                  [ Redirect-Max-Cache-Time ]

                                 *[ Proxy-Info ]

                                 *[ Route-Record ]

                                 *[ Failed-AVP ]

                                 *[ AVP ]

 

What is the purpose of having Route-Record AVP in CCA message? What problem does it solve? As far as I know, the route-record AVP can be present only in requests.