3. Configuring Diameter peers

Diameter peer configuration is required by Diameter applications Radiator supports. Diameter applications and <ServerDIAMETERTelco> need peer definitions to work properly
All Diameter peers a Radiator instance talks to, must have a matching DiaPeerDef clause. A DiaPeerDef clause defines what is advertised to the peer, which applications are supported for the peer and if Radiator should actively open connections to the peer instead of waiting for a connection from the peer.
You can configure a single instance of Radiator to support, for example, relaying requests from some peers and processing the requests locally by the other peers.
You can configure Radiator to advertise certain applications to certain peers. The peer definition also determines if Radiator should act as an initiator and establish a connection to the peer. Alternatively Radiator can act as a responder waiting for the peer connection. It is possible to configure Radiator as an initiator for some peer connections and responder for the others.
A <ServerDIAMETERTelco> clause is required to create a listen socket for the incoming Diameter peer connections.

3.1. <DiaPeerDef attribute=value,attribute=value,...>

A DiaPeerDef clause defines describes and defines a Diameter peer this Radiator instance can be connected to. A Diameter connection can be initiated by Radiator or by the peer.
A minimal Radiator configuration requires one DiaPeerDef clause in addition to any AuthBy DiaPCRF, DiaPCEF, DiaRelay or other Diameter based AuthBys. When there is no ServerDIAMETERTelco clause, the DiaPeerDef clauses must be configured with the Initiator flag to connect to the Diameter peers.
A ServerDIAMETERTelco clause allows accepting incoming Diameter connections. When a ServerDIAMETERTelco is configured, Radiator will act as a Diameter responder. The settings for the connecting peers are looked up from DiaPeerDef clauses. The clauses are matched against the incoming CER (Capabilities Exchange Request) from the peer.
Note
At least one DiaPeerDef clause is always required.
If a ServerDIAMETERTelco clause is configured but there are no DiaPeerDef clauses, the incoming CER messages are rejected by Radiator. A DiaPeerDef is required to form a successful CEA (Capabilities Exchange Answer) back to the peer.
Here is an example of configuring DiaPeerDef clauses. The first clause defines a Diameter peer that Radiator connects to. The connection is made to the IP address and port configured within the clause. An IP address and port are only needed when Initiator flag parameter is set.
The second DiaPeerDef clause defines a peer that must initiate a connection. When a Diameter peer connects to Radiator, the transport layer responder parameters, such as use of TLS, are defined within a <ServerDIAMETERTelco> clause. When the transport layer is successfully set up, the peer sends a Diameter Capabilities-Exchange-Request (CER). If the CER has Origin-Host with value epdg.epc.mnc001.mcc001.3gppnetwork.org , it matches the first DiaPeerDef and defines how Radiator responds to the CER.
# Our DRA requires that Radiator initiates the connection
<DiaPeerDef Origin-Host=dra.mnc001.mcc001.3gppnetwork.org>
    Identifier example-dra

    SupportedVendorIds 3GPP
    AuthApplicationIds 3GPP SWx, 3GPP SWm, 3GPP S6b

    ProductName Radiator 3GPP AAA Server

    Peer 172.16.172.80
    Port 3868
    Initiator

    OriginHost radiator-3gpp.aaa.mnc001.mcc001.3gppnetwork.org
    OriginRealm aaa.mnc001.mcc001.3gppnetwork.org
</DiaPeerDef>

# Definition of direct peering our ePDG initiates
<DiaPeerDef Origin-Host=epdg.epc.mnc001.mcc001.3gppnetwork.org>
    Identifier example-epdg

    SupportedVendorIds 3GPP
    AuthApplicationIds 3GPP SWm

    ProductName Radiator 3GPP AAA Server

    OriginHost radiator-3gpp.aaa.mnc001.mcc001.3gppnetwork.org
    OriginRealm aaa.mnc001.mcc001.3gppnetwork.org
</DiaPeerDef>

# Listen to incoming Diameter connections
<ServerDIAMETERTelco>
    Identifier diameter-server

    Port 3880
    # TLS and other settings
</ServerDIAMETERTelco>

3.1.1. Identifier

This is an optional parameter, which defines the name of the specific <DiaPeerDef> clause and its configuration.

3.1.2. Initiator

This is an optional flag, which defines if the Radiator instance can act as a connection initiator. It is not set by default.
Initiator must be set if Radiator instance has to act as an initiator and create a connection to the Diameter peer defined by this <DiaPeerDef>. If Initiator is not set, the Radiator instance does not initiate connections but other instances, such as ePDG (Evolved Packet Data Gateway), must act as a initiator.

3.1.3. AddToRequestFromDia

This parameter defines the Diameter attributes, which are added to a request object in addition with OriginHost and OriginRealm. The request object is created when a Diameter request message is received. The request object is then sent to the handler with the correct application AuthBy for this request.

3.1.4. PreHandlerHook

This is an optional parameter, which defines the Perl function that is called before the request object is sent to the handlers. The only passed argument is the reference to the current request object.

3.1.5. NoReplyHook

This is an optional parameter, which defines the Perl function that is called if no reply is received from any Diameter peer.

3.1.6. NoreplyTimeout

This integer defines how soon, in seconds, NoReplyHook is called if the request stored in proxy does not receive a reply. The default value is 5.

3.1.7. ProductName

This is an optional parameter, which defines the name of the specific Diameter peer. If defined, it is sent to the other Diameter peers within the CER and CEA messages. The default value is Radiator.

3.1.8. OriginHost

This string defines the name that <ServerDIAMETERTelco> uses to identify itself to the Diameter peers. It is sent to the Diameter peers in the Diameter CER and CEA messages. The Diameter peers use OriginHost to determine whether they have connected to the correct peer. OriginHost must be specified.

3.1.9. OriginRealm

This string defines the name of the Realm the <ServerDIAMETERTelco> uses. It is sent to the Diameter peers in the CER and CEA messages. The peer uses it to determine which requests are routed to this Radiator instance. OriginRealm must be specified.

3.1.10. DestinationHost

This string defines the value for Destination-Host for Diameter requests. The usage of this parameter depends on the Diameter application that uses this <DiaPeerDef>. This is an optional parameter.

3.1.11. DestinationRealm

This string defines the value for Destination-Realm for Diameter requests. The usage of this parameter depends on the Diameter application that uses this <DiaPeerDef>. This is an optional parameter.

3.1.12. SupportedVendorIds

This is an optional parameter, which defines the supported vendor IDs announced in CER and CEA messages. This has no default value and the supported vendor ID is not announced by default. The default dictionary or the configured dictionary file consist an alias group DictVendors for all supported vendors.

Example

# Advertise Open System Consultants and 3GPP
SupportedVendorIds 9048, 3GPP

3.1.13. AcctApplicationIds

This is an optional parameter, which defines the Acct-Application-Id attributes announced in the CER and CEA messages. The Acct-Application-Id is not announced by default.

Example

AcctApplicationIds Base Accounting

3.1.14. VendorAuthApplicationIds

This is an optional parameter, which defines the authentication Vendor-Specific-Application-Id attributes announced in the CER and CEA messages. The Vendor-Specific-Application-Id is not announced by default. The parameter value is a comma-separated list of vendor:application values. Both names and direct numeric values are accepted.

Example

VendorAuthApplicationIds 3GPP:3GPP-Rx, 3GPP:3GPP-Gx

3.1.15. VendorAcctApplicationIds

This is an optional parameter, which defines the accounting Vendor-Specific-Application-Id attributes announced in the CER and CEA messages. The Vendor-Specific-Application-Id is not announced by default. The parameter value is a comma-separated list of vendor:application values. Both names and direct numeric values are accepted.

Example

VendorAcctApplicationIds OSC:Example accounting app

3.1.16. Peer

This parameter defines the name or IP address of the Diameter peer. Both IPv4 and IPv6 addresses are supported. This parameter is required when <DiaPeerDef> is configured to act as an initiator.

3.1.17. Port

This is an optional parameter, which defines the network port <ServerDIAMETERTelco> listens to for connections from Diameter peers. For more information, see Radiator reference manual Opens in new window under section <ServerDIAMETER>.

3.1.18. LocalAddress and LocalPort

These parameters control the address and optionally the port number used for the client source port, although this is usually not necessary. LocalPort is a string, it can be a port number or name. It binds the local port if LocalAddress is defined. If LocalPort is not specified or if it is set to 0, a port number is allocated in the usual way.
When SCTP multihoming is supported, multiple comma separated addresses can be configured. All addresses defined with LocalAddress must be either IPv4 or IPv6 addresses.
LocalAddress 203.63.154.29
LocalPort 12345

3.1.19. Protocol

This is an optional parameter, which allows choosing transport layer protocol, TCP or SCTP, for carrying Diameter messages. For more information, see Radiator reference manual Opens in new window under section <ServerDIAMETER>.

3.1.20. TLS_*

These parameters enable and configure of TLS (Transport Layer Security) authentication and encryption. For more information, see Radiator reference manual Opens in new window under section "TLS configuration". To enable TLS, you need to define TLS_Protocols configuration parameter with the other TLS related parameters, such as certificates, that depend on your operating environment.
Note
Old configuration parameters UseTLS and UseSSL are obsolete and should not be used. Use TLS_Protocols instead.