top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration

How these Capabilities Update Procedure Works ?

+2 votes
86 views

I had a look on this Q/A and got one thing in my mind. How this Procedure works ? because i have read the both RFC but did not find this Procedure and there working.

Reference: http://tech.queryhome.com/41739/why-do-we-require-capabilities-update-procedure-diameter

posted Apr 28, 2014 by Aman

Share this question
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

1 Answer

+4 votes
  • It is a procedure to dynamically update capabilities of an Application (Client/Server). Application that is wanted to use this feature MUST advertise Application-Id 10 in CER/CEA (Capabilities-Exchange-Request/Answer)message. Both communicating nodes MUST support Application-Id 10.

  • An application that is going to send Capabilities-Update-Request (CUR) shall send all the Application-Ids currently supported by it (rather than sending only upgraded) on established connection. This message can not modify the security constraint applied on established connection.

  • Receiver of CUR MUST look for intersection of supported Application-Ids received with its own Application-Ids, If there are some common applications then it shall send CUA with Result-Code set to DIAMETER_SUCCESS and shall store the values of Application-Ids else it send Result-Code set to DIAMETER_NO_COMMON_APPLICATION and should terminate transport connection, if there are some on going sessions then it may delay the termination process till completion of sessions.

Capabilities-Update-Request/Answer command code id 328 and Message Format is as follow:

   <CUR> ::= < Diameter Header: 328, REQ >
            { Origin-Host }
            { Origin-Realm }
         1* { Host-IP-Address }
            { Vendor-Id }
            { Product-Name }
            [ Origin-State-Id ]
          * [ Supported-Vendor-Id ]
          * [ Auth-Application-Id ]
          * [ Acct-Application-Id ]
          * [ Vendor-Specific-Application-Id ]
            [ Firmware-Revision ]
          * [ AVP ]
   <CUA> ::= < Diameter Header: 328 >
                           { Origin-Host }
                           { Origin-Realm }
                           { Result-Code }
                           [ Error-Message ]
                         * [ AVP ]

During the processing of CUR/CUA message Vendor-Id AVP in the Vendor-Specific- Application-Id MUST NOT be used in decision making. A Node (Peer) can not use CUR/CUA message to notify the change in its own identity i.e. Origin-Host

Like CER/CEA message; CUR/CUA message can not be relayed, proxied and redirected.

answer Apr 29, 2014 by Hiteshwar Thakur
Similar Questions
+2 votes

What is the sense of giving Capabilities Update Procedure described in new RFC-6737.

+2 votes

In what all scenarios, this procedure gets executed ? And why this procedure need to be executed ?

+2 votes

We are connecting the PCEF to PCRF. But the Gx link is not coming up. I have observed that there are CER/CEA successful between PCEF a PCRF. DWR is generated by PCRF (i.e. seen in the logs) but it is not sent (i.e. not seen in the capture). Any suggestion on what could be the issue.

Contact Us
+91 9880187415
sales@queryhome.net
support@queryhome.net
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Bangalore-560102
Karnataka INDIA.
QUERY HOME
...