Deployment Guide for Video Mesh

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Deployment Guide for Video Mesh

Chapter Title

Prepare Your Environment

Results

Updated:
May 16, 2023

Chapter: Prepare Your Environment

Prepare Your Environment

Requirements for Video Mesh

Video Mesh is available with the offers documented in License Requirements for Hybrid Services.

Call Control and Meeting Integration Requirements for Video Mesh

Call control and existing meetings infrastucture are not required to use Video Mesh, but you can integrate the two. If you're integrating Video Mesh with your call control and meeting infrastructure, make sure your environment meets the minimum criteria that are documented in the following table.

Table 1. Call Control and Meeting Requirements for Video Mesh

Component Purpose

Minimum Supported Version

On-Premises call control

Cisco Unified Communications Manager, Release 11.5(1) SU3 or later. (We recommend the latest SU release.)

Cisco Expressway-C or E, Release X8.11.4 or later. (See the "Important Information" section in the Expressway Release Notes for more information.)

Meeting infrastructure

Webex Meetings WBS33 or later. (You can verify that your Webex site is on the correct platform if it has the Media Resource Type list available in the Cloud Collaboration Meeting Room site options.)

To ensure that your site is ready for Video Mesh, contact your customer success manager (CSM) or partner.

Note

 

Video Mesh does not work on Webex sites with telephony service provider (TSP) audio. The correct platform is not available if you're using TSP audio.

Failover handling

Cisco Expressway-C or E, Release X8.11.4 or later. (See the "Important Information" section in the Expressway Release Notes for more information.)

One Button to Push (OBTP)

Cisco TMS 15.2.1 and Cisco TMSXE5.2, WBS31 Webex Productivity Tools

Endpoint and Webex App App Requirements

Table 2. Endpoint and App Requirements for Video Mesh

Component Purpose

Details

Supported Endpoints

See Webex Video Compatibility and Support.

Supported versions of the Webex App app

Video Mesh supports Webex App for desktop (Windows, Mac) and mobile (Android, iPhone, and iPad). To download the app for a supported platform, go to https://www.webex.com/downloads.html.

Supported codecs

See Webex| Video Specifications for Calls and Meetings for the supported audio and video codecs. Note these caveats for Video Mesh:

  • For video quality, Video Mesh supports up to 1080p in certain scenarios. You can configure this setting in https://admin.webex.com.

  • For SIP video systems, Video Mesh supports SIP clients that do dual tone multi frequency (DTMF) audio tones. The service also supports keypad markup language (KPML).

  • Webex Teams for Windows and Mac and Room, Desk, and Board devices registered to the cloud support up to 1080p 30fps with content audio.

  • H.323 clients are mentioned in the data sheet, but they only go to the cloud.

Supported Webex-registered Room, Desk, and Board devices

The following devices are tested and confirmed to work with Video Mesh nodes:

System and Platform Requirements for Video Mesh Node Software

Production Environments

In production deployments, there are two ways to deploy Video Mesh Node software on a particular hardware configuration:

  • You can set up each server as a single virtual machine, which is best for deployments that include many SIP endpoints.

  • Using the VMNLite option, you can set up each server with multiple smaller virtual machines. VMNLite is best for deployments that mainly include Webex App and cloud-registered endpoints.

These requirements are common for the all configurations:

  • VMware ESXi 6 or vSphere 6 or later

  • Hyperthreading enabled

The Video Mesh nodes running independent of the platform hardware need dedicated vCPUs and RAM. Sharing resources with other applications is not supported. This applies to all images of the Video Mesh software.

For Video Mesh Lite (VMNLite) images on a CMS platform, we only support having VMNLite images. No other Video Mesh image or non-Video Mesh application can be on the CMS hardware with the VMNLite software.

Table 3. System and Platform Requirements for Video Mesh Node Software in a Production Environment

Hardware Configuration

Production Deployment as a Single Virtual Machine

Production Deployment with VMNLite VMs

Notes

Cisco Meeting Server 1000 (CMS 1000)

  • 72vCPUs (70 for Video Mesh Node, 2 for ESXi)

  • 60 GB main memory

  • 80 GB local hard disk space

Deploy as 3 identical virtual machine instances, each with:

  • 23 vCPUs

  • 20 GB main memory

  • 80 GB local hard disk space

We recommend this platform for Video Mesh Node.

Caution

 

If you deploy VMNLite on a CMS 1000 with a 300 GB hard drive, you can run out of space when upgrading to ESXi 7. We recommend that you upgrade to at least 500 GB hard drives before upgrading VMware.

Specifications-based Configuration

(2.6-GHz Intel Xeon E5-2600v3 or later processor required)

  • 72vCPUs (70 for Video Mesh Node, 2 for ESXi)

  • 60 GB main memory

  • 80 GB local hard disk space

    or

    80 GB of NFS storage

Deploy as 3 identical virtual machine instances, each with:

  • 23 vCPUs

  • 20 GB main memory

  • 80 GB local hard disk space

    or

    80 GB of NFS storage

Each Video Mesh virtual machine must have CPU, RAM and hard drives reserved for itself.

Use either the CMS1000 or VMNLite option during configuration.

Peak IOPs (input/output operations per second) for NFS storage is 300 IOPS.

Cisco Meeting Server 2000 (CMS 2000)

Deploy as 8 identical virtual machine instances, each with:

  • 72vCPUs (70 for Video Mesh Node, 2 for ESXi)

  • 60 GB main memory

  • 80 GB local hard disk space

    or

    80 GB of NFS storage

Deploy as 24 identical virtual machine instances, each with:

  • 23 vCPUs

  • 20 GB main memory

  • 80 GB local hard disk space

    or

    80 GB of NFS storage

We recommend this platform for Video Mesh Node.

Each blade must be a complete Cisco Meeting Server 1000 with reserved CPU, RAM and hard drives per blade.

Peak IOPs for NFS storage is 300 IOPS.

Demo Environments

For basic demo purposes, you can use a specifications-based hardware configuration, with the following minimum requirements:

  • 14vCPUs (12 for Video Mesh Node, 2 for ESXi)

  • 8 GB main memory

  • 20 GB local hard disk space

  • 2.6 GHz Intel Xeon E5-2600v3 or later processor

For more information about the demo software, see Video Mesh Node Demo Software.

Bandwidth Requirements

Video Mesh Nodes must have a minimum internet bandwidth of 10 Mbps for both upload and download to operate properly.

Requirements for Proxy Support for Video Mesh

  • We officially support the following proxy solutions that can integrate with your Video Mesh nodes.

    • Cisco Web Security Appliance (WSA) for transparent proxy

    • Squid for explicit proxy

  • For an explicit proxy or transparent inspecting proxy that inspects (decrypts traffic), you must have a copy of the proxy's root certificate that you'll need to upload to the Video Mesh node trust store on the web interface.

  • We support the following explicit proxy and authentication type combinations:

    • No authentication with http and https

    • Basic authentication with http and https

    • Digest authentication with https only

    • NTLM authentication with http only

  • For transparent proxies, you must use the router/switch to force HTTPS/443 traffic to go to the proxy. You can also force Web Socket to go to proxy. (Web Socket uses https.)


    Note

    Video Mesh requires web socket connections to cloud services, so that the nodes function correctly. On explicit inspecting and transparent inspecting proxies, http headers that are required for a proper websocket connection are altered and websocket connections fail.

    The symptom when this occurs on port 443 (with transparent inspecting proxy enabled) is a post-registration warning in Control Hub: “Webex Video Mesh SIP calling is not working correctly.” The same alarm can occur for other reasons when proxy is not enabled. When websocket headers are blocked on port 443, media does not flow between apps and SIP clients.

    If media is not flowing, this often occurs when https traffic from the node over port 443 is failing:

    • Port 443 traffic is allowed by the proxy, but it is an inspecting proxy and is breaking the websocket.

    To correct these problems, you may have to “bypass” or “splice” (disable inspection) on port 443 to: *.wbx2.com and *.ciscospark.com.

Capacity for Video Mesh nodes

Because Video Mesh is a software-based media product, the capacity of your Video Mesh nodes varies. In particular, meeting participants on the Webex cloud place a heavier load on nodes. You get lower capacities when you have more cascades to the Webex cloud. Other factors that impact capacity are:

  • Types of devices and clients

  • Video resolution

  • Network quality

  • Peak load

  • Deployment model


Note

Video Mesh usage doesn't impact your Webex license counts.

In general, adding more nodes to the cluster doesn't double the capacity because of the overhead for setting up cascades. Use these numbers as general guidance. We recommend the following:

  • Test out common meeting scenarios for your deployment.

  • Use the analytics in Control Hub to see how your deployment is evolving and add capacity as needed.


Note

Overflows on low call volume (especially SIP calls that originate on-premises) aren't a true reflection of scale. Video Mesh analytics (under Control Hub > Resources > Call Activity) indicate the call legs that originate on-premises. They don't specify the call streams that came in through the cascade to the Video Mesh node for media processing. As remote participant numbers increase in a meeting, cascades increase and consume on-premises media resources on the Video Mesh node.

This table lists capacity ranges for different mixes participants and endpoints on regular Video Mesh nodes. Our testing included meetings with all participants on the local node and meetings with a mix of local and cloud participants. With more participants on the Webex cloud, expect your capacity to fall in the lower end of the range.

Table 4. Capacity on regular Video Mesh nodes

Scenario

Resolution

Participant capacity

Meetings with only Webex App participants

720p

100–130

Meetings and 1-to-1 calls with only Webex App participants

720p

60–100

Meetings with only SIP participants

720p

70–80

Meetings with only SIP participants

1080p

30–40

Meetings with Webex App and SIP participants

720p

75–110

Note

  • The base resolution for Webex App meetings is 720p. But when you share, the participant thumbnails are at 180p.

  • These performance numbers assume that you enabled all the recommended ports.

Capacity for VMNLite

We recommend VMNLite for deployments that mainly include Webex App and cloud-registered endpoints. In these deployments, the nodes use more switching and fewer transcoding resources than the standard configuration provides. Deploying several smaller virtual machines on the host optimizes resources for this scenario.

This table lists capacity ranges of different mixes participants and endpoints. Our testing included meetings with all participants on the local node and meetings with a mix of local and cloud participants. With more participants on the Webex cloud, expect your capacity to fall in the lower end of the range.

Table 5. Capacity on VMNLite nodes

Scenario

Resolution

Participant capacity with 3 VMNLite nodes on a server

Meetings with only Webex App participants

720p

250–300

Meetings and 1-to-1 calls with only Webex App participants

720p

175–275

Note

The base resolution for Webex App meetings is 720p. But when you share, the participant thumbnails are at 180p.

Clusters in Video Mesh

You deploy Video Mesh nodes in clusters. A cluster defines Video Mesh nodes with similar attributes, such as network proximity. Participants use a particular cluster or the cloud, depending on the following conditions:

  • A client on a corporate network that can reach an on-premises cluster connects to it—the primary preference for clients on the corporate network.

  • Clients joining a Video Mesh private meeting only connect to on-premise clusters. You can create a separate cluster specifically for these private meetings.

  • A client that can't reach an on-premises cluster connects to the cloud—the case for a mobile device unconnected to the corporate network.

  • The chosen cluster also depends on latency, rather than just location. For example, a cloud cluster with lower STUN round-trip (SRT) delay than a Video Mesh cluster may be a better candidate for the meeting. This logic prevents a user from landing on a geographically far cluster with a high SRT delay.

Each cluster contains logic that cascades meetings, except for Video Mesh private meetings, across other cloud meeting clusters, as needed. Cascading provides a data path for media between clients in their meetings. Meetings are distributed across nodes. Clients land on the most efficient node nearest to them, depending on factors such as network topology, WAN link, and resource utilization.

The client's ability to ping media nodes determines reachability. An actual call uses a variety of potential connection mechanisms, such as UDP and TCP. Before the call, the Webex device (Room, Desk, Board, and Webex App) registers with the Webex cloud, which provides a list of cluster candidates for the call.


Note

The nodes in a Video Mesh cluster require unimpeded communication with each other. They also require unimpeded communication with the nodes in all your other Video Mesh clusters. Ensure that your firewalls allow all communication between the Video Mesh nodes.

Clusters for Private Meetings

You can reserve a Video Mesh cluster for private meetings. When the reserved cluster is full, the private meeting media cascades out to your other Video Mesh clusters. When the reserved cluster is full, private meetings and non-private meetings share the resources of your remaining clusters.

Non-private meetings won’t use a reserved cluster, reserving those resources for the private meetings. If a non-private meeting runs out of resources on your network, it cascades out to the Webex cloud instead.

For details on the Video Mesh private meetings feature, see Private Meetings.


Important

You can't use the short video address format (meet@your_site) if you reserve all Video Mesh clusters for private meetings. These calls currently fail without a proper error message. If you leave some clusters unreserved, calls with the short video address format can connect through those clusters.

Guidelines for Video Mesh Cluster Deployment

  • In typical enterprise deployments, we recommend that customers use up to 100 nodes per cluster. There are no hard limits set in the system to block a cluster size with greater than 100 nodes. However, if you need to create larger clusters, we strongly recommend that you review this option with Cisco engineering through your Cisco Account Team.

  • Create fewer clusters when resources have similar network proximity (affinity).

  • When creating clusters, only add nodes that are in the same geographical region and the same data center. Clustering across the wide area network (WAN) is not supported.

  • Typically, deploy clusters in enterprises that host frequent localized meetings. Plan where you place clusters on the bandwidth available at various WAN locations inside the enterprise. Over time, you can deploy and grow cluster-by-cluster based on observed user patterns.

  • Clusters located in different time zones can effectively serve multiple geographies by taking advantage of different peak/busy hour calling patterns.

  • If you have two Video Mesh nodes in two separate data centers (EU and NA, for example), and you have endpoints join through each data center, the nodes in each data center would cascade to a single Video Mesh node in the cloud. Theses cascades would go over the Internet. If there is a cloud participant (that joins before one of the HMN participants), the nodes would be cascaded through the cloud participant’s media node.

Time Zone Diversity

Time zone diversity can allow clusters to be shared during off-peak times. For example: A company with a Northern California cluster and a New York cluster might find that overall network latency is not that high between the two locations that serve a geographically diverse user population. When resources are at peak usage in the Northern California cluster, the New York cluster is likely to be off peak and have additional capacity. The same applies for the Northern California cluster, during peak times in the New York cluster. These aren't the only mechanisms used for effective deployment of resources, but they are the two main ones.

Overflow to the Cloud

When the capacity of all on-premises clusters are reached, an on-premises participant overflows to the Webex cloud. This doesn't mean that all calls are hosted in the cloud. Webex only directs to the cloud those participants that are either remote or can't connect to an on-premises cluster. In a call with both on-premises and cloud participants, the on-premises cluster is bridged (cascaded) to the cloud to combine all participants into a single call.

If you set up the meeting as the private meeting type, Webex keeps all the calls on your on-premises clusters. Private meetings never overflow to the cloud.

Webex Device Registers with Webex

In addition to determining reachability, the clients also perform periodic round-trip delay tests using Simple Traversal of UDP through NAT (STUN). STUN round-trip (SRT) delay is an important factor when selecting potential resources during an actual call. When multiple clusters are deployed, the primary selection criteria are based on the learned SRT delay. Reachability tests are performed in the background, initiated by a number of factors including network changes, and do not introduce delays that affect call setup times. The following two examples show possible reachability test outcomes.

Round-trip Delay Tests—Cloud Device Fails to Reach On-Premises Cluster

Round-trip Delay Tests—Cloud Device Successfully Reaches On-Premises Cluster

Learned reachability information is provided to the Webex cloud every time a call is set up. This information allows the cloud to select the best resource (cluster or cloud), depending on the relative location of the client to available clusters and the type of call. If no resources are available in the preferred cluster, additional clusters are tested for availability based on SRT delay. A preferred cluster is chosen with the lowest SRT delay. Calls are served on premises from a secondary cluster when the primary cluster is busy. Local reachable Video Mesh resources are tried first, in order of lowest SRT delay. When all local resources are exhausted, the participant connects to the cloud.

Cluster definition and location is critical for a deployment that provides the best overall experience for participants. Ideally, a deployment should provide resources where the clients are located. If not enough resources are allocated where the clients make the majority of calls, more internal network bandwidth is consumed to connect users to distant clusters.

On-Premises and Cloud Call

On-premises Webex devices that have the same cluster affinity (preference, based on proximity to the cluster) connect to the same cluster for a call. On-premises Webex devices with different on-premises cluster affinities, connect to different clusters and the clusters then bridged to the cloud to combine the two environments into a single call.

On-Premises Call with Different Cluster Affinities

The Webex device connects to either on-premises cluster or cloud based upon its reachability. The following show examples of the most-common scenarios.

Webex Cloud Device Connects to Cloud

Webex On-Premises Device Connects to On-Premises Cluster

Webex On-Premises Device Connects to Cloud

Cloud Cluster Selection for Overflow Based on 250 ms or Higher STUN Round-Trip Delay

While the preference for node selection is your locally deployed Video Mesh nodes, we support a scenario where, if the STUN round-trip (SRT) delay to an on-premises Video Mesh cluster exceeds the tolerable round-trip delay of 250 ms (which usually happens if the on-premises cluster is configured in a different continent), then the system selects the closest cloud media node in that geography instead of a Video Mesh node.

  • The Webex App app or device is on the enterprise network in San Jose.

  • San Jose and Amsterdam clusters are at capacity or unavailable.

  • SRT delay to the Shanghai cluster is greater than 250 ms and will likely introduce media quality issues.

  • The San Francisco cloud cluster has an optimal SRT delay.

  • The Shanghai Video Mesh cluster is excluded from consideration.

  • As a result, the Webex App client overflows to the San Francisco cloud cluster.


Note

Intercluster cascades always go to the cloud.

Private Meeting Call

Signalling diagram for private meetings

Private meetings isolate all media to your network through Video Mesh. Unlike normal meetings, if the local nodes are full, the media doesn't cascade to the Webex cloud. But, by default, private meetings can cascade to different Video Mesh clusters on your network. For private meetings across geographic locations, your Video Mesh clusters must have direct connectivity to each other to allow intercluster cascades, like HQ1_VMN to Remote1_VMN in the figure.

All participants in a private meeting must belong to your organization. They can join using the Webex App or an authenticated video system. Participants with VPN or MRA access to your network can join a private meeting. But nobody can join a private meeting from outside your network.

Deployment Models Supported by Video Mesh

Supported in a Video Mesh Deployment

  • You can deploy a Video Mesh Node in either a data center (preferred) or demilitarized zone (DMZ). For guidance, see Ports and Protocols Used by Video Mesh.

  • For a DMZ deployment, you can set up the Video Mesh nodes in a cluster with the dual network interface (NIC). This deployment lets you separate the internal enterprise network traffic (used for interbox communication, cascades between node clusters, and to access the node's management interface) from the external cloud network traffic (used for connectivity to the outside world and cascades to the cloud).

    Dual NIC works on both the full version and demo version of Video Mesh node software. You can also deploy the Video Mesh behind a 1:1 NAT setup.

  • You can integrate Video Mesh nodes with your call control environment. For example deployments with Video Mesh integrated with Unified CM, see Deployment Models For Video Mesh and Cisco Unified Communications Manager.

  • The following types of address translation are supported:

    • Dynamic Network Address Translation (NAT) using an IP pool

    • Dynamic Port Address Translation (PAT)

    • 1:1 NAT

    • Other forms of NAT should work as long as the correct ports and protocols are used, but we do not officially support them because they have not been tested.

  • IPv4

  • Static IP address for the Video Mesh Node

Not Supported in a Video Mesh Deployment

  • IPv6

  • DHCP for the Video Mesh Node

  • A cluster with a mixture of single NIC and dual NIC

  • Clustering Video Mesh nodes over the wide area network (WAN)

  • Audio, video, or media that does not pass through a Video Mesh Node:

    • Audio from phones

    • Peer-to-peer call between Webex App app and standards-based endpoint

    • Audio termination on Video Mesh Node

    • Media sent through Expressway C/E pair

    • Video call back

Deployment Models For Video Mesh and Cisco Unified Communications Manager

These examples show common Video Mesh deployments and help you understand where Video Mesh clusters can fit in to your network. Keep in mind that Video Mesh deployment depends on factors in your network topology:

  • Data center locations

  • Office locations and size

  • Internet access location and capacity

In general, try to tie the Video Mesh nodes to the Unified CM or Session Management Edition (SME) clusters. As a best practice, keep the nodes as centralized as possible to the local branches.

Video Mesh supports Session Management Edition (SME). Unified CM clusters can be connected through an SME, and then you must create a SME trunk that connects to the Video Mesh nodes.

Hub and Spoke Architecture

This deployment model involves centralized networking and internet access. Typically, the central location has a high employee concentration. In this case, a Video Mesh cluster can be located at central location for optimized media handling.

Locating clusters in branch locations may not yield benefits in the short term and may lead to suboptimal routing. We recommend that you deploy clusters in a branch only if there is frequent communication between branches.

Geographic Distribution

The geographically distributed deployment is interconnected, but can exhibit noticeable latency between regions. Lack of resources can cause suboptimal cascades to be setup in the short term when there are meetings between users in each geographical location. In this model, we recommend that you allocate of Video Mesh nodes near regional internet access.

Geographic Distribution with SIP Dialing

This deployment model contains regional Unified CM clusters. Each cluster can contain a SIP trunk to select resources in the local Video Mesh cluster. A second trunk can provide a failover path to an Expressway pair if resources become limited.

Ports and Protocols Used by Video Mesh

To ensure a successful deployment of Video Mesh and for trouble-free operation of the Video Mesh nodes, open the following ports on your firewall for use with the protocols.

Ports and Protocols for Management

Figure 1. Ports and Protocols for Management

Note

The nodes in a Video Mesh cluster require unimpeded communication with each other. They also require unimpeded communication with the nodes in all your other Video Mesh clusters. Ensure that your firewalls allow all communication between the Video Mesh nodes.

The Video Mesh nodes in a cluster must be in the same VLAN or subnet mask.

Purpose

Source

Destination

Source IP

Source Port

Transport Protocol

Destination IP

Destination Port

Management

Management computer

Video Mesh node

As required

Any

TCP, HTTPS

Video Mesh node

443

SSH for access to Video Mesh admin console

Management computer

Video Mesh node

As required

Any

TCP

Video Mesh node

22

Intracluster Communication

Video Mesh node

Video Mesh node

IP address of other Video Mesh nodes in the cluster

Any

TCP

Video Mesh nodes

8443

Management

Video Mesh node

Webex cloud

As required

Any

UDP, NTP

UDP, DNS

TCP, HTTPS (WebSockets)

Any

123*

53*

Cascade Signaling

Video Mesh node

Webex cloud

Any

Any

TCP

Any

443

Cascade Media

Video Mesh node

Webex cloud

Video Mesh node

Any***

UDP

Any

For specific addresses ranges, see the "IP subnets for Webex Media services" section in Network Requirements for Webex Services.

5004

50000 to 53000

For details, see the "Webex Services – Port Numbers and Protocols" section in Network Requirements for Webex Services.

Cascade Signaling

Vido Mesh Cluster (1)

Vido Mesh Cluster (2)

Any

Any

TCP

Any

443

Cascade Media

Vido Mesh Cluster (1)

Vido Mesh Cluster (2)

Vido Mesh Cluster (1)

Any***

UDP

Any

5004

50000 to 53000

Management

Video Mesh node

Webex cloud

As required

Any

TCP, HTTPS

Any**

443

Management

Video Mesh node (1)

Video Mesh node (2)

Video Mesh node (1)

Any

TCP, HTTPS (WebSockets)

Video Mesh node (2)

443

Internal Communication

Video Mesh node

All other Video Mesh nodes

Video Mesh node

Any

UDP

Any

10000 to 40000

* The default configuration in the OVA is configured for NTP and DNS. The OVA requires that you open those ports outbound to the internet. If you configure a local NTP and DNS server, then you don't have to open ports 53 and 123 through the firewall.

** Because some cloud service URLs are subject to change without warning, ANY is the recommended destination for trouble-free operation of the Video Mesh nodes. If you prefer to filter traffic based on URLs, see the "Webex Teams URLs for Hybrid Services" section of the Network Requirements for Webex Services for more information.

***The ports vary depending on if you enable QoS. With QoS enabled, the ports are 52,500-59499, 63000-64667, 59500-62999 and 64688-65500. With QoS off, the ports are 34,000-34,999.

Traffic Signatures for Video Mesh (Quality of Service Enabled)

For deployments where the Video Mesh node sits in the enterprise side of the DMZ or inside the firewall, there is a Video Mesh Node configuration setting in the Webex Control Hub that allows the administrator to optimize the port ranges used by the Video Mesh Node for QoS network marking. This Quality of Service setting is enabled by default and changes the source ports that are used for audio, video, and content sharing to the values in this table. This setting allows you to configure QoS marking policies based on UDP port ranges to differentiate audio from video or content sharing and mark all Audio with recommended value of EF and Video and Content sharing with a recommended value of AF41.

Figure 2. Traffic Signatures for Video Mesh (Quality of Service Enabled)

The table and diagram show UDP ports that are used for audio and video streams, which are the main focus of QoS network configurations. While network QoS marking policies for media over UDP are the focus of the following table, Webex Video Mesh nodes also terminate TCP traffic for presentation and content sharing for Cisco Webex Teams apps using ephemeral ports 52500–65500. If a firewall sits between the Video Mesh nodes and the Cisco Webex Teams apps, those TCP ports also must be allowed for proper functioning.

Note

 

Video Mesh Node marks traffic natively. This native marking is asymmetric in some flows and depends on whether the source ports are shared ports (single port like 5004 for multiple flows to various destinations and destination ports) or whether they are not (where the port falls in a range but is unique to that specific bidirectional session).

To understand the native marking by a Video Mesh Node, note that the Video Mesh node marks audio EF when it is not using the 5004 port as a source port. Some bidirectional flows like Video Mesh to Video Mesh cascades or Video Mesh to Webex Teams App will be asymmetrically marked, a reason to use the network to remark traffic based on the UDP port ranges provided.

Source IP Address Destination IP Address Source UDP Ports Destination UDP Ports Native DSCP Marking Media Type

Video Mesh Node

Webex cloud media services

35000 to 52499

5004

AF41

Test STUN packets
Video Mesh Node Webex cloud media services 52500 to 59499 5004 EF Audio
Video Mesh Node Webex cloud media services 63000 to 64667 5004 AF41 Video
Video Mesh Node Webex cloud media services

59500 to 62999

50000 to 51499

EF

Audio
Video Mesh Node Webex cloud media services

64668 to 65500

51500 to 53000

 AF41

Video
Video Mesh Node Video Mesh Node 10000 to 40000 10000 to 40000 — Audio
Video Mesh Node Video Mesh Node 10000 to 40000 10000 to 40000 — Video
Video Mesh Node Unified CM SIP endpoints 52500 to 59499 Unified CM SIP Profile EF Audio
Video Mesh Node Unified CM SIP endpoints 63000 to 64667 Unified CM SIP Profile AF41 Video

Video Mesh Cluster

Video Mesh Cluster

 52500 to 59499 5004 EF Audio

Video Mesh Cluster

Video Mesh Cluster

 63000 to 64667 5004 AF41 Video

Video Mesh Cluster

Video Mesh Cluster

59500 to 62999

50000 to 51499

EF

Audio

Video Mesh Cluster

Video Mesh Cluster

64668 to 65500

51500 to 53000

 AF41

Video
Video Mesh Node Webex Teams application or endpoint* 5004 52000 to 52099 AF41 Audio
Video Mesh Node Webex Teams application or endpoint 5004 52100 to 52299 AF41 Video

*The direction of media traffic determines the DSCP markings. If the source ports are from the Video Mesh node (from the Video Mesh node to Webex Teams app), the traffic is marked as AF41 only. Media traffic that originates from the Webex Teams app or Webex endpoints has the separate DSCP markings, but the return traffic from the Video Mesh node shared ports does not.

Traffic Signatures for Video Mesh (Quality of Service Disabled)

For deployments where the Video Mesh node sits in the DMZ, there is a Video Mesh Node configuration setting in the Webex Control Hub that allows you to optimize the port ranges used by the Video Mesh node. This Quality of Service setting, when disabled (enabled by default), changes the source ports that are used for audio, video, and content sharing from the Video Mesh node to the range 34000 to 34999. The Video Mesh node then natively marks all audio, video, and content sharing to a single DSCP of AF41.


Note

Because the source ports are the same for all media regardless of destination, you cannot differentiate the audio from video or content sharing based on port range with this setting disabled. This configuration does let you configure firewall pin holes for media more easily that with Quality of Service enabled.

The table and diagram show UDP ports that are used for audio and video streams when QoS is disabled.

Table 6. Traffic Signatures for Video Mesh (Quality of Service Disabled)
Source IP Address Destination IP Address Source UDP Ports Destination UDP Ports

Native DSCP Marking

Media Type
Video Mesh Node Webex cloud media services 34000 to 34999 5004 AF41 Audio
Video Mesh Node Webex cloud media services 34000 to 34999 5004 AF41 Video
Video Mesh Node Webex cloud media services 34000 to 34999 50000 to 51499 AF41 Audio
Video Mesh Node Webex cloud media services 34000 to 34999 51500 to 53000 AF41 Video
Video Mesh Node Video Mesh Node 10000 to 40000 10000 to 40000 AF41 Audio
Video Mesh Node Video Mesh Node 10000 to 40000 10000 to 40000 AF41 Video

Video Mesh Cluster

Video Mesh Cluster

 34000 to 34999 5004 AF41 Audio

Video Mesh Cluster

Video Mesh Cluster

 34000 to 34999 5004 AF41 Video

Video Mesh Cluster

Video Mesh Cluster

 34000 to 34999 50000 to 51499 AF41 Audio

Video Mesh Cluster

Video Mesh Cluster

 34000 to 34999 51500 to 53000 AF41 Video
Video Mesh Node Unified CM SIP endpoints 52500 to 59499 Unified CM SIP Profile AF41 Audio
Video Mesh Node Unified CM SIP endpoints 63000 to 64667 Unified CM SIP Profile AF41 Video

Video Mesh Node

Webex cloud media services

35000 to 52499

5004

AF41

Test STUN packets
Video Mesh Node Webex Teams application or endpoint 5004 52000 to 52099 AF41 Audio
Video Mesh Node Webex Teams application or endpoint 5004 52100 to 52299 AF41 Video

Ports and Protocols for Webex Meetings Traffic

Figure 3. Ports and Protocols for Webex Meetings

Purpose

Source

Destination

Source IP

Source Port

Transport Protocol

Destination IP

Destination Port

Calling to meeting

Apps (Webex App desktop and mobile apps)

Webex room, desk, or board device

Video Mesh node

As required

Any

UDP and TCP (Used by the Webex App app)

SRTP (Any)

Any**

5004

SIP device calling to meeting (SIP signaling)

Unified CM or Cisco Expressway call control

Video Mesh node

As required

Ephemeral (>=1024)

TCP or TLS

Any**

5060 or 5061

Cascade

Video Mesh node

Webex cloud

As required

34000 to 34999

UDP, SRTP (Any)*

Any**

5004

50000 to 53000***

Cascade

Video Mesh node

Video Mesh node

As required

34000 to 34999

UDP, SRTP (Any)*

Any**

5004

Note

Port 5004 is used for all cloud media and on-premises Video Mesh nodes.

Webex App apps continue to connect to Video Mesh nodes over shared ports 5004. These ports are also used by Webex App apps and endpoints for STUN tests to Video Mesh nodes. Video Mesh node to Video Mesh node for cascades use destination port range of 10000–40000.* TCP is also supported, but not preferred because it may affect media quality.

** If you want to restrict by IP addresses, see the IP address ranges that are documented in Webex Teams IP subnets for media.

*** The Expressway already uses this port range for the Webex cloud. So, most deployments won't require any updates to support this new requirement for Video Mesh. But, if your deployment has more stringent firewall rules, you might need to update your firewall configuration to open these ports for Video Mesh.

For the best experience using Webex in your organization, configure your firewall to allow all outbound TCP and UDP traffic that is destined toward ports 5004 as well as any inbound replies to that traffic. The port requirements that are listed above assume that Video Mesh nodes are deployed either in the LAN (preferred) or in a DMZ and that Webex App apps are in the LAN.

Video Quality and Scaling for Video Mesh

Below are some common meeting scenarios when a cascade is created. Video Mesh is adaptive depending on the available bandwidth and distributes resources accordingly. For devices in the meeting that use the Video Mesh node, the cascade link provides the benefit of reducing average bandwidth and improving the meeting experience for the user.


Note

For bandwidth provisioning and capacity planning guidelines, see the Preferred Architecture documentation.

Based on the active speakers in the meeting, the cascade links are established. Each cascade can contain up to 6 streams and the cascade is limited to 6 participants (6 in the direction of Webex Teams/SIP to Webex cloud and 5 in the opposite direction). Each media resource (cloud and Video Mesh) ask the remote side for the standard definition streams that are needed to fulfil the local endpoint requirements of all remote participants across the cascade.

To provide a flexible user experience, the Webex platform can do multistream video to meeting participants. This same ability applies to the cascade link between Video Mesh nodes and the cloud. In this architecture, the bandwidth requirements vary depending on a number of factors, such as the endpoint layouts.

Architecture

In this architecture, Cisco Webex-registered endpoints send signaling to the cloud and media to the switching services. On-premises SIP endpoints send signaling to the call control environment (Unified CM or Expressway), which then sends it to the Video Mesh node. Media is sent to the transcoding service.

Cloud and Premises Participants

Local on-premises participants on the Video Mesh node request the desired streams based on their layout requirements. Those streams are forwarded from the Video Mesh node to the endpoint for local device rendering.

Each cloud and Video Mesh node requests HD and SD resolutions from all participants that are cloud registered-devices or Webex Teams apps. Depending on the endpoint, it will send up to 4 resolutions, typically 1080p, 720p, 360p, and 180p.

Cascades

Most Cisco endpoints can send 3 or 4 streams from a single source in a range of resolutions (from 1080p to 180p). The layout of the endpoint dictates the requirement for the streams needed on the far end of the cascade. For active presence, the main video stream is 1080p or 720p, the video panes (PiPS) are 180p. For equal view, the resolution is 480p or 360p for all participants in most cases. The cascade created between Video Mesh nodes and the cloud also sends 720p, 360p and 180p in both directions. Content is sent as single stream, and audio is sent as multiple streams.

Cascade bandwidth graphs that provide a per-cluster measurement are available in the Analytics menu in Webex Control Hub. You cannot configure cascade bandwidth per meeting in Control Hub.


Note

The maximum negotiated cascade bandwidth per meeting is 20Mbps for main video for all sources and the multiple main video streams that they could send. This maximum value does not include the content channel or audio.

Main Video With Multiple Layout Example

The following diagrams illustrate an example meeting scenario and how the bandwidth is influenced when multiple factors are at play. In the example, all Webex Teams apps and Webex-registered devices are transmitting 1x720p, 1x360p and 1x180p streams. On the cascade, streams of 2x720p, 2x360p, and 2x180p are transmitted in both directions. The reason is because there are Webex Teams apps and Webex-registered devices that are receiving 720p, 360p and 180p on both sides of the cascade.


Note

In the diagrams, the bandwidth numbers for transmitted and received data are for example purposes only. They are not an exhaustive coverage of all possible meetings and accompanying bandwidth requirements. Different meeting scenarios (joined participants, device capabilities, content sharing within the meeting, activity at any given point in time during the meeting) will yield different bandwidth levels.

Figure 4. Main Video With Multiple Layout at Time of Meeting.

This diagram shows a meeting with cloud and premises registered endpoints and an active speaker.

Figure 5. Cascade From Video Mesh Node to Cloud.

In the same meeting, this diagram shows an example of a cascade created between the Video Mesh nodes and the cloud in both directions.

Figure 6. Cascade From the Cloud.

In the same meeting, this diagram shows an example of a cascade from the cloud.

Figure 7. Addition of Webex Meetings Participant.

This diagram shows a meeting with the same devices above, along with a Webex Meetings client. The system sends the active speaker and last active speaker in high definition, along with an extra HD stream of the active speaker for Webex Meeting clients because Video Mesh nodes do not support the Webex Meetings at this time.

Requirements for Webex Services

Work with your partner, customer success manager (CSM), or trials representative to correctly provision the Cisco Webex site and Webex services for Video Mesh:

  1. You must have a Webex organization with a paid subscription to Webex services.

  2. To take full advantage of Video Mesh, make sure your Webex site is on video platform version 2.0. (You can verify that your site is on video platform version 2.0 if it has the Media Resource Type list available in the Cloud Collaboration Meeting Room site options.)

  3. You must enable CMR for your Webex site under user profiles. (You can do this in a bulk update CSV with the SupportCMR attribute).


Note

If you have a Webex site that is managed in Site Administration, we recommend that you link it with Control Hub now, in order to have access to a wider set of features. See Link Cisco Webex Sites to Control Hub for Cisco Webex Teams and Analytics for more information.

For further information, see Feature Comparison and Migration Path from Collaboration Meeting Room Hybrid to Video Mesh in the Appendix.

Verify That the Source Country Is Correct

Video Mesh uses the globally distributed media (GDM) capabilities of Webex to achieve better media routing. To achieve optimal connectivity, Webex selects the nearest cloud media node to your enterprise when performing Video Mesh cascades to Webex. Traffic then passes through the Webex backbone to interact with the Webex microservices for the meeting. This routing minimizes latency and keeps most of the traffic on the Webex backbone and off the internet.

To support GDM, we use MaxMind as the GeoIP location provider for this process. Verify that MaxMind correctly identifies the location of your Public IP address to ensure efficient routing.

Procedure

Step 1

In a web browser, enter this URL with the public IP address of your Expressway or endpoint at the end.

Example:

https://ds.ciscospark.com/v1/region/<public IP address>

You receive a response like the following:

attribution: "This product includes GeoLite2 data created by MaxMind, available from http://www.maxmind.com"
clientAddress: "<public IP address>"
clientRegion: "US-WEST"
countryCode: "US"
disclaimer: "This service is intended for use by Webex Team only. Unauthorized use is prohibitted."
regionCode: "US-WEST"
timezone: "America/Chicago"

Step 2

Verify that the countryCode is appropriate for the location of your Expressway or endpoint.

Step 3

If the location is incorrect, submit a request to correct the location of your public IP address to MaxMind at https://support.maxmind.com/geoip-data-correction-request/correct-a-geoip-location.

Complete the Prerequisites for Video Mesh

Use this checklist to ensure you are ready to install and configure Video Mesh nodes and integrate a Webex site with Video Mesh.

Procedure

Step 1

Ensure that you:

Step 2

Work with your partner, customer success manager, or trials representative to understand and prepare your Webex environment so that it's ready to connect to Video Mesh. For more information, see Requirements for Webex Services.

Step 3

Record the following network information to assign to your Video Mesh nodes:

  • IP address (Recommended)
  • Network mask
  • Gateway IP address
  • DNS servers
  • NTP servers
  • A hostname and optionally domain name for the Video Mesh node. (Optional)

    Note

     

    We recommend that you use IP addresses for Video Mesh. If you plan to configure the nodes with FQDN, the FQDN value should be resolvable using all the entries in the DNS servers list configured on the node. You must also create both forward- and reverse-DNS (A- and PTR-records) in the DNS configuration.

Step 4

Before starting installation, make sure your Webex organization is enabled for Video Mesh. This service is available for organizations with certain paid Webex service subscriptions as documented in License Requirements for Cisco Webex Hybrid Services. Contact your Cisco partner or account manager for assistance.

Step 5

Choose a supported hardware or specifications-based configuration for your Video Mesh node, as described in System and Platform Requirements for Video Mesh Node Software.

Step 6

Make sure your server is running VMware ESXi 6 (or later) and vSphere 6 (or later) with a VM host operational.

Step 7

If you're integrating Video Mesh with your Unified CM call control environment and you want the participant lists to be consistent across meeting platforms, make sure your Unified CM cluster security mode is set to mixed mode so that it supports TLS-encrypted traffic. End-to-end encrypted traffic is required for this functionality to work.

See the TLS setup chapter in the Security Guide for Cisco Unified Communications Manager for more information about switching your Unified CM environment to mixed mode. See the Active Control solution guide for more information about the features and about how to set up end-to-end encryption.

Step 8

If you're integrating a proxy (explicit, transparent inspecting, or transparent non-inspecting) with Video Mesh, make sure you following the requirements as documented in Requirements for Proxy Support for Video Mesh.

What to do next

Install and Configure Video Mesh Node Software

Was this Document Helpful?

FeedbackFeedback

Contact Cisco