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.
