Upon TCP connectivity establishment, Diameter peers in an SR node exchange Capability Exchange messages. These messages contain information about the peer such as the peer’s identity, supported applications, protocol version, and security mechanisms. Capability Exchange messages do not traverse Diameter nodes but instead they are exchanged only between the peers (immediate Diameter next hops).
In this phase, an SR node performs peer authorization where the peer identity received from the peer through a Capability Exchange message (origin-host in CEA) is compared to the locally configured peer identity. This peer identity (the peer name) comparison in SR OS is case insensitive. If the compared peer names do not match, the TCP session is closed.
For example:
The configured peer name for SR OS is: peer-1.acme. This identifies the peer that the SR is allowed to establish a connection with.
The origin strings received from this peer in CEA are:
Origin-host: peer-1
Origin-realm: realm-x
In this scenario, SR rejects the connection from this peer because the configured peer name in the SR (peer-1.acme) does not match the origin-host received from the same peer in CEA (peer-1).
An SR node always advertises all three supported applications (NASREQ, Gx, and Gy) in Capability Exchange, regardless of whether these applications are configured in an SR node.
If no common applications are negotiated, the peer (the receiver of a Capability Exchange Request - CER) must return a Capability Exchange Answer (CEA) with the Result-Code AVP set to DIAMETER_NO_COMMON_APPLICATION and should disconnect the transport layer connection.
If the application ID of 0xffffffff (Diameter Relay Agent - DRA) is received by an SR node, then this is interpreted as having a common application with the peer.
Diameter names and realms learned from peers through Capability Exchange are used in SR nodes to populate local peer and realm routing tables that are then used for forwarding and routing of the Diameter messages.