How to Start Mobius Diameter Open Source

Starting the stack involves setting up local and remote peers, configuring their network parameters, and managing the lifecycle of Diameter sessions. This guide explains the setup and configuration process for starting a Diameter server and client using the Mobius Diameter Stack, with example for E4 application for handling User Data Requests (UDR) and User Data Answers (UDA). It will help you understand the individual components of the Mobius Diameter Stack and how they work together to facilitate communication over SCTP (Stream Control Transmission Protocol).

Important: Ensure you are using the JDK (Java Development Kit) and not the JRE (Java Runtime Environment). The JRE does not include the necessary development tools required by Mobius Diameter.

Client and Server Setup Overview

The Mobius Diameter stack manages sessions, message exchanges, and network links between Diameter peers. The setup process requires initializing the Diameter stack on both client and server sides, configuring communication parameters (such as timeouts and IP addresses), and defining the message exchange protocol for the E4 application.
The following components are key to the setup:

• DiameterStack: Central entity managing Diameter operations, session lifecycle, and communication.
• NetworkManager: Handles SCTP/TCP connections between peers and manages message transmission.
• WorkerPool: Manages worker threads for processing tasks asynchronously.
• Listeners (ClientListener and ServerListener): Handle incoming messages, process requests, and generate responses.

1. Server Setup

The server is responsible for receiving requests from the client, processing them, and sending the appropriate responses. 

1.1 Worker Pool Initialization

WorkerPool is used to manage worker threads that will handle tasks asynchronously. This is essential for non-blocking communication between peers.

1.2 Server Stack Initialization

This code initializes the DiameterStack on the server. The parameters define various operational aspects such as:
ClassLoader: Loads relevant classes.
IDGenerator: Generates unique session IDs.
WorkerPool Queues: Handles task execution.
Timeouts: Manages session and response timeouts.
Hostname and Realm: Identifies the server for Diameter communication.

1.3 Adding and Starting a Network Link

For this particular example Client was set up on machine with IP 192.168.33.54 and
Server was set up on the machine with IP 192.168.33.55

addLink: This sets up the network link between the server (192.168.33.55) and client (192.168.33.54).
SCTP Ports: Defines the ports for communication (13868 for the server and 4868 for the client).
Hostnames: The localHost and destinationHost define the identity of the Diameter nodes.
startLink: This activates the link, allowing messages to be exchanged between the peers.

1.4 Setting up the Server Listener

ServerListener: This listener is responsible for processing incoming Diameter requests, such as, in this particular case, User Data Requests (UDR). It waits for the request, processes it, and generates the appropriate User Data Answer (UDA) response.
Session Management: Stack uses a stateless session for processing, meaning that the server does not retain session information between requests. 
The open source version of Mobius Diameter could work in both Stateless and Stateful modes.

1.5 Sending User Data Answer

MessageFactory: The server creates a User Data Answer (UDA) to respond to the UDR received from the client.
AsyncCallback: This ensures non-blocking communication. The onSuccess and onError methods allow the server to handle the result of sending the UDA.

2. Client Setup

The client initiates communication with the server by sending requests and processing the server's responses. 

2.1 Worker Pool Initialization

Just like the server, the client uses a WorkerPool to manage threads for processing tasks asynchronously.

2.2 Client Stack Initialization

This initializes the DiameterStack on the client. The setup is similar to the server, with parameters defining timeouts, hostnames, and task handling.

2.3 Adding and Starting a Network Link

addLink: Establishes a link from the client (192.168.33.54) to the server (192.168.33.55).
SCTP Ports: Defines the ports for communication (4868 for the client and 13868 for the server).
Hostnames: Similar to the server, the client and server hostnames are defined.
startLink: Activates the link to initiate communication between the client and server.

2.4 Creating and Sending User Data Request

User Data Request: The client creates a User Data Request (UDR) using the MessageFactory and sends it to the server.
Session Management: The E4ClientSession manages the client-side session and sends the initial request. The AsyncCallback handles the success or failure of the operation.

3. SCTP and Diameter Message Flow 

When starting the Mobius Diameter Stack, communication between the client and server relies on a sequence of SCTP messages followed by Diameter protocol messages. Understanding this message flow is essential for diagnosing connectivity issues and ensuring proper session management. Here’s an overview of the key message exchanges that occur when establishing and maintaining a Diameter session:

3.1 SCTP Handshake

Before any Diameter communication can take place, the client and server must establish a connection using the SCTP protocol. The following messages are exchanged during the handshake process:
INIT / INIT_ACK: These messages are the initial handshake between the client and server. The client sends an INIT message, and the server responds with INIT_ACK to acknowledge the connection setup.
COOKIE_ECHO / COOKIE_ACK: SCTP uses a cookie mechanism to prevent connection hijacking. After the initial handshake, the client sends a COOKIE_ECHO, and the server responds with COOKIE_ACK, confirming the establishment of the SCTP connection.
Once the SCTP connection is established, Diameter messages can be exchanged.

3.2 Capabilities-Exchange

The first Diameter messages exchanged between the client and server are the Capabilities-Exchange Request (CER) and Capabilities-Exchange Answer (CEA). This exchange is essential for establishing the parameters of communication:
CER (Capabilities-Exchange Request): The client sends this message to inform the server of its capabilities, including supported applications, vendor-specific extensions, and session handling capabilities.
CEA (Capabilities-Exchange Answer): The server responds with its own capabilities. This message confirms that both peers are compatible and ready for Diameter communication.

3.3 User Data Request/Answer

In our test setup we chose an E4 application which is used to facilitate the exchange of IP-connectivity session data between the Network Attachment Subsystem (NASS) and Resource and Admission Control Subsystem (RACS). This exchange ensures efficient resource allocation and admission control for IP-based services. 
So after the capabilities exchange, the client and server can begin exchanging actual Diameter application messages, such as (specific for E4 application) User Data Requests (UDR) and User Data Answers (UDA):
UDR (User Data Request): The client sends this message to request user-specific information from the server. In the context of the E4 application, this might be related to user session data or authentication information.
UDA (User Data Answer): The server processes the request and responds with the appropriate data using a User Data Answer. A successful UDA includes the requested information and indicates the completion of the request.

3.4 Device-Watchdog

To maintain the connection between peers and ensure that neither party has become unresponsive, the client and server periodically exchange Device-Watchdog Requests (DWR) and Device-Watchdog Answers (DWA):
DWR (Device-Watchdog Request): The client or server sends this message periodically to confirm that the peer is still reachable and active.
DWA (Device-Watchdog Answer): The receiving peer responds with a DWA to acknowledge that it is still alive and ready to continue communication.

3.5 Session Termination

Finally, when either the client or server wishes to terminate the session, a Disconnect-Peer Request (DPR) is sent:
DPR (Disconnect-Peer Request): This message is sent by the initiating peer (usually the client) to signal that it wishes to close the Diameter session.
DPA (Disconnect-Peer Answer): The receiving peer responds with a Disconnect-Peer Answer (DPA), confirming that it acknowledges the termination request.
After this, the SCTP connection is closed gracefully using SCTP Shutdown messages to cleanly terminate the session.