Monitoring Webex Meetings with Cloud and Enterprise Agents

Best Practices

We recommend that you set up the following tests with Webex Cloud Agents to better understand your Webex Meeting performance. For full visibility into Webex, these tests should supplement any HTTP server, web transaction, or DNS tests that you have targeting your Webex environment. For instructions on setting up the recommended tests, a Webex Meeting Health dashboard, and custom alerts, see the Webex Meeting Test Template section below.

  • An RTP Stream Test between any applicable Enterprise Agents and the Webex Cloud Agent hosted within the VPC of your closest multimedia platform server. You should use (UDP) 9000 and 5004, with DSCP 46. This will help you understand inbound performance of voice traffic into the Webex Cloud environment.

  • An Agent-to-Agent Bidirectional Test between any applicable Enterprise Agents and the Webex Cloud Agent hosted within the VPC of your closest multimedia platform server. You should use (UDP) 9000 and 5004, with DSCP 34. This will help you understand simulated, bidirectional performance of video-marked traffic into the Webex Cloud environment.

    Keep in mind that for agent-to-agent tests, in many cases you must configure the firewall to allow the test to succeed. For detailed information, see Firewall Configuration.

If the Enterprise Agent in the test is behind a NAT, you must also select the Behind a NAT option. For detailed information, see NAT Traversal Requirements.

  • Optional: Secondary RTP Stream and Agent-to-Agent Bidirectional Tests For more complete visibility, set up the above RTP stream and agent-to-agent tests to your second-closest multimedia platform server. You should use the same test settings targeting your backup Webex multimedia platform location, providing visibility into its reachability and network traffic performance.

If you attempt to run a TCP-based test, we recommend that you enable in-session path trace mode for consistent path visualization results. If you don’t enable this setting, you may notice TCP packets getting dropped at the ingress of the Webex infrastructure.

  • Vanity Webex HTTP Server URL Test for monitoring the primary landing page that your users connect to when they access Webex. This example shows, but you will want to use https://<your-company-name>

Make sure to update the Advanced Settings > Network > Data Collection > Protocol to ICMP.

  • Authoritative Webex DNS Server Test is used to ensure that your vanity Webex domain is properly resolving both internally and externally. When using Enterprise Agents, update the DNS Servers field to use your internal name servers. If you use Cloud Agents for external visibility, use the Lookup Servers button to auto-populate the authoritative external name servers. This example shows Cloud Agents resolving You will need to update it to your organization's vanity domain.

If you use and Enterprise Agents, make sure to update the Advanced Settings > Network > Protocol to TCP and the Advanced Settings > Network > DNS to Send recursive queries. If you use both Cloud and Enterprise agents, set Advanced Settings > Network > DNS > Transport to UDP.

  • Optional: Transaction Test to Check the Webex Status Page The code sample below can be pasted into the Transaction Script field and used to monitor the Webex Status page

Make sure to update Advanced Settings > Network > Data Collection > Protocol to ICMP.

import { By, Key } from 'selenium-webdriver';
import { driver, browser, markers } from 'thousandeyes';
async function runScript() {
  await configureDriver();
  // Navigate to Webex Global Status Page
  await driver.get('');
  await driver.takeScreenshot();
  // Find the card for Webex Meetings
  let webex_meetings = await driver.findElement(By.xpath(`//*[text()="Webex Meetings"]`));

  // click on webex meetings to show operational status

  // Scroll the card into view and take a screenshot
  await driver.executeScript("arguments[0].scrollIntoView({block: 'center'});", webex_meetings);
  await driver.takeScreenshot();

  // Find all the list items showing each component's status
  let items = await webex_meetings.findElements(By.xpath('./../..//li'));
  // Iterate over each list item...
  await Promise.all( function (item) {
    let component = await item.findElement(By.css('span.text-secondary')).getText();
    let status = await item.findElement(By.css('span.font-body-small')).getText();
    console.log((await component), (await status));
    // ...and throw an error if any Webex Meeting Comopnent is non-Operational
    if (status != 'Operational') {
      throw Error('Component "' + component + '" is not operational: ' + status);
async function configureDriver() {
  await driver.manage().window().setRect({
    width: 1440,
    height: 900 });
  await driver.manage().setTimeouts({
    implicit: 7 * 1000 // If an element is not found, reattempt for this many milliseconds
async function configureDriver() {
    await driver.manage().setTimeouts({
        implicit: 7 * 1000, // If an element is not found, reattempt for this many milliseconds

async function click(selector) {
    await simulateHumanDelay();

    const configuredTimeouts = await driver.manage().getTimeouts();
    const clickAttemptEndTime = + configuredTimeouts.implicit;

    await reattemptUntil(attemptToClick, clickAttemptEndTime);

    async function attemptToClick() {
        await driver.findElement(selector)

async function reattemptUntil(attemptActionFn, attemptEndTime) {
    const TIME_BETWEEN_ATTEMPTS = 100;
    let numberOfAttempts = 0;
    let attemptError;
    while ( < attemptEndTime || numberOfAttempts === 0) {
        try {
            numberOfAttempts += 1;
            await attemptActionFn();
        catch (error) {
            attemptError = error;
            await driver.sleep(TIME_BETWEEN_ATTEMPTS);
            continue; // Attempt failed, reattempt
        attemptError = null;
        break; // Attempt succeeded, stop attempting

    const wasAttemptSuccessful = !attemptError;
    if (!wasAttemptSuccessful) {
        throw attemptError;

async function simulateHumanDelay() {
    await driver.sleep(550);

async function typeText(value, selector) {
    await simulateHumanDelay();
    const element = await driver.findElement(selector);
    await element.clear();
    await element.sendKeys(value);


Webex Meeting Test Template

The Webex meeting test template creates the set of tests recommended in the best practices section above. These tests are then automatically associated with a Webex Health dashboard, and custom alerts are created based on Webex monitoring best practices.

You can run the template multiple times, based on your monitoring requirements:

  1. Navigate to Cloud & Enterprise Agents > Test Settings.

  2. Use the pull down arrow beside Add New Test, and click Add From Template.

  3. Scroll down and select the Webex Meeting template.

The following screenshot is an example of the Webex Meeting Deploy Template:

Custom Template Fields

Use the "?" above the fields for helpful hints.

  • Use the pull down to select the interval that will be used for all tests in the template. After the template deploys, you can update or modify individual tests. For example, you may want to run the DNS test at a 5 or 15 minute interval, instead of a 1 minute interval.

  • Webex Site ID Name: This is your corporate site ID. For example, for only the site ID of cisco is required.

  • Webex Port: This will default to port 5004 and can be updated to port 9000. If you want to monitor both ports, run the template the first time with port 5004 and then use the same selections and update the port to 9000. The DNS Server and HTTP Server tests will not be re-created the second time you run the template.

  • Webex DNS Servers: Click the Look Up Servers button and the public DNS servers will automatically be populated. If you are running this test internally, we recommend you use your internal name servers, which can be added manually in the Enter server field. It is best practice to use the name server's IP address in this case.

  • Target Webex Agent: Use the Built-in Labels and select Webex Cloud to filter the associated Webex Cloud Agents. Then select the agent in the Webex data center that you want your tests to target.

  • Target Region (optional): This field can be used if you want tests to be configured for a certain region or building for easier troubleshooting, or based on your users. For example, you might use WEST and then target the Webex San Jose, CA Webex Data Center.

  • Source Agents: These will be where the tests will be run from. If you have any custom agent labels set up, you can use them to quickly filter and select agents.

  • Name your template: The default is Webex and it can be updated to match your monitoring requirements.

  • Click Review to verify what will be deployed.

The following image is an example of the Ready to deploy? page.

Click the Deploy Now button to generate your template. It will then display the Setup Completed Successfully! page, shown in the screenshot below.

If there are any issues, they will display at the bottom with information on how to correct the problem/s. You can always reach out to ThousandEyes Support if the issue persists.

Once the setup is completed, you can:

  • Click Done button to go back to the Tests page.

  • Click Create Another Template if you want to deploy more templates.

  • Click Go to Test Settings for a filter view of the tests created by the template.

  • Click Go to Dashboards to open the Webex Health Dashboard.

Testing Multiple Webex Agents

You can create additional tests targeting other Webex Agents or additional ports, ie. 9000, simply by re-deploying the Webex Template. The Webex Server and Webex DNS tests will not be impacted when you deploy multiple times. You can use the 'Target Region' field to append a unique region identifier to your Voice and Video tests so that new voice and video tests get created each time you re-deploy.

Webex Cloud Agent Locations

For current Webex Cloud Agent locations, see Webex Agents.

Last updated