The vast majority of Telco Systems under Test (SuT) are located in private networks or behind firewalls. The reason for that is that a big part of testing takes place in development environments (which often reside directly on developers' computers), in confined lab environments, or within Continuous Integration workflows. Production systems on the other hand are usually protected by firewalls and ACLs and only allow traffic from and to certain IP address ranges.

The problem with cloud-based tests and private environments

The situation with private and protected SuT is quite a hurdle for cloud-based test systems like Sipfront. One option is to publish a list of IP addresses of the traffic generation agents, so users can whitelist and/or forward them in their security perimeters. This puts heavy constraints onto both the operator of such test systems and its users, because you can’t just scale up by adding more agents without each user having to adapt their ACLs, which is quite a show stopper.

The second option is to create a direct connection from the cloud test system into the user’s environment via a VPN. This somewhat solves the problem of reaching private network environments and at least makes it easier to manage network ACLs. One big issue though is that lots of lab environments are not exactly equipped with a big connection to the Internet. With a couple hundreds of concurrent audio calls (or worse, video calls), you fill up the capacity of the user’s Internet connection very quickly, making that the bottle-neck of their tests.

Local Sipfront traffic generation agents to the rescue

Sipfront solves these issues in an elegant and unique way by letting its users run their own traffic generation agents in their own environment.

This approach allows users to create different Agent Pools for different locations, and run as many Traffic Agents as necessary per pool to generate the test traffic.

Traffic agents are packaged as Docker containers and can be launched with just one simple command.

The SF_POOL_ID and SF_POOL_SECRET values are obtained when users create their agent pools via the web interface at https://app.sipfront.com/agentpools.

Securing the traffic to the Sipfront Cloud

Each agent instance launched by a user connects to a Message Queue at mq.sipfront.com in the Sipfront Cloud on ports 8883 and 61614. The connections are encrypted via TLS to avoid evesdropping of 3rd parties on users' traffic. Each agent is further authenticated and authorized by the message queue, to make sure nobody else except for the user’s agents and the Sipfront infrastructure can read and write data for a user’s test session.

Traffic agents also require to download auxiliary data from the Sipfront Cloud, like configuration files and test credentials. This data is fetched via a REST API at api.sipfront.com on port 443, again encrypted via TLS and authenticated and authorized via JWT per test session. This ensures a user’s data for a test can only be accessed throughout the duration of a test by the agent instances involved in the test.

To allow the local traffic generation agents to communicate with the Sipfront Cloud, you therefore have to allow the following connections from the network environment running your agents towards the Sipfront Cloud:

• 8883/TCP to mq.sipfront.com
• 61614/TCP to mq.sipfront.com
• 443/TCP to api.sipfront.com

We hope you find this new feature helpful to further increase the test coverage of your Telco systems. Happy Testing!