When using Sipfront to test your infrastructure, you leverage Sipfront agents to originate and terminate the test traffic such as phone calls via SIP and RTP, WebRTC calls, or simple DNS requests or test traffic to measure and test your bandwidth.

How Sipfront agents work by default

Sipfront agents are grouped into agent pools, and you can use agents from public agent pools operated by Sipfront, or create your own agent pools and launch your own agents at the locations of your choice.

Once you launch a test, a random available agent is allocated for each relevant role, e.g. to act as calling party or called party of a SIP call, as illustrated in the image below, where Agent X and Agent Y are allocated from the agent pool Agent Pool A, and the agents would either run on Server Core 1 or Server Core 2.

You can launch your agents on whatever infrastructure or server you like (such as a bare metal server in a data center, or a Raspberry Pi, or your own laptop), and locate the hardware physically wherever you like.

1docker run \
2  --init --pull always \
3  --env SF_POOL_ID="YOUR_POOL_UUID" \
4  --env SF_POOL_SECRET="YOUR_POOL_SECRET" \
5  sipfront/agent:latest

The only restriction, due to security reasons to strictly isolate data flowing between agents, is that in a test you can only select one agent pool, so all agents involved in a test are from the same pool.

Take control over the agent placement

When you think about the random assignment of agents as described above, one problem becomes apparent:

What if you want to perform a test from a customer site as calling party via your system to a remote called party?

Of course you have to start an agent on-site at the customer site, and it needs to be in the same pool as the agent at the remote party. BUT: since agents are randomly assigned from the pool for both the calling party and called party role, how do you know if the agent running on the customer is acting as calling party, and not as called party (since the assignment is random)?

This is where agent groups come into play.

Agent groups are another layer of segmentation below the agent pools. When configuring a test, you can define both for the calling party and the called party, which agent group to use for the respective role. Based on that concept, you can now exactly define which agents are used for which role in a test.

Launching an agent with a specific group definition only requires to add the SF_POOL_GROUP option when starting the agent.

1docker run \
2  --init --pull always \
3  --env SF_POOL_ID="YOUR_POOL_UUID" \
4  --env SF_POOL_SECRET="YOUR_POOL_SECRET" \
5  --env SF_POOL_GROUP="SiteS1" \
6  sipfront/agent:latest

Use cases for agent groups

When you have a network with multiple sites (either your own point-of-presences as an operator, our possibly your customer premises), and you want to perform tests between those sites, you need to exactly control which role of the test (e.g. the calling and called party of a call, or the sender and receiver of a bandwidth test) is located where.

Feedback and new Feature Requests

We’d love to hear your opinion on the new Agent Group feature! Do you like it? Do you hate it? Would you love to have it extended or improved in one way or another?

Leave a comment below, or send us a message on X/Twitter, LinkedIn or via Email!