This article provides an outline of the general guidelines and basic principles for certain integrations that include Vidyo network server appliances and/or Vidyo clients along with an application delivery controller (ADC).  The intention of this article is to assist with the high-level knowledge needed to configure such integrations. This article is not intended to cover the specific configuration settings and variables in any given ADC system. Based on the high-level information provided here, the specific configurations needed to be performed on the ADC itself should be understood by an engineer who is trained and who has understanding of the ADC at that level.

Some examples of ADC vendors (products) are: F5 Networks (Big-IP), Citrix (Netscaler), Radware (Alteon), and KEMP Technologies.

Definitions

• ADC - Application Delivery Controller is a network device or software that is typically placed in a data center between the firewall and one or more application servers (an area known as the DMZ). Application Delivery Controllers primarily perform application acceleration by offloading a portion of web services, handle load balancing between servers, and can provide other advanced features or services.
• DNAT - Destination Network Address Translation (DNAT) is a technique for transparently changing the destination IP address of an end route packet and performing the inverse function for any replies. Any router (and some ADCs) situated between two endpoints can perform this transformation of the packet. DNAT is commonly used to publish a service located in a private network on a publicly accessible IP address.
• DNS - Domain Name System (DNS) is a hierarchical decentralized naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most prominently, it translates more readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols.
• DMZ - Demilitarized Zone (DMZ) (sometimes referred to as a perimeter network or screened subnet) is a physical or logical subnetwork that contains and exposes an organization's external-facing services to an untrusted network, usually a larger network such as the Internet. The purpose of a DMZ is to add an additional layer of security to an organization's local area network (LAN): an external network node can access only what is exposed in the DMZ, while the rest of the organization's network is firewalled. The DMZ functions as a small, isolated network positioned between the Internet and the private network and, if its design is effective, allows the organization extra time to detect and address breaches before they would further penetrate into the internal networks.
• DR - Disaster Recovery (DR) is a automatic or manual failover mechanism used between VidyoPortals™ to provide high availability. Portal servers may fail-over within a given region or between regions and may or may not retain the same IP address afterward.
• EMCP - Endpoint Management Control Protocol (EMCP) is the signaling protocol used between Vidyo client endpoints (as well some server components) and the VidyoManager. EMCP is used for controlling and signaling call status with the VidyoPortal and system. The default port is TCP_17992.
• GTM - Global Traffic Manager (GTM) is the term used by F5 networks for its global load balancer, which provides global load balancing and other services primarily via its DNS engine. Other ADC vendors provide similar services.
• Hairpinning/NAT Hairpinning - NAT hairpinning, also known as NAT loopback or NAT reflection, is a feature in many routers which permits the access of a service via the public IP address from inside the local network. This eliminates the need for using separate domain name resolution for hosts inside the network than for the public network for a website.
• iRule - iRules are supported by F5 in their ADC implementation. iRules are a highly customized, Tcl-based scripting language that allows complete programmatic access to application traffic in real time. When looking to inspect, analyze, modify, route, re-direct, discard, or manipulate traffic in any way, chances are it can be accomplished with an iRule. Other ADC vendors may offer similar customization capabilities.
• Load Balancer - Load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware, such as a ADC or a Domain Name System server process.
• LTM - Local Traffic Manager (LTM) is the term used by F5 Networks for its local traffic load balancer. LTM is a networking term synonymous with the term "load balancer".
• NAT - Network Address Translation (NAT) is a method of remapping one IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device.
• RMCP - Router Management Control Protocol (RMCP) is the signaling and call control protocol used between VidyoRouter components and the VidyoManager. The default port is TCP_17991.
• Reverse Proxy - A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the proxy server itself. Unlike a forward proxy, which is an intermediary for its associated clients to contact any server, a reverse proxy is an intermediary for its associated servers to be contacted by any client.
• SCIP - Session Control Initiation Protocol (SCIP) is the signaling protocol used between Vidyo client endpoints (as well some server components) and the VidyoRouter. SCIP is used for control and signaling call status with the VidyoRouter for each individual call and conference.
• SNAT - SNAT is a term that varies by vendor. Here SNAT is used for Source NAT. Source NAT (SNAT) is the NATing of the source IP of a given connection, masquerading the previous IP address of the client.
• SSL/TLS - Secure Sockets Layer (SSL), and the more advanced descendant, Transport Layer Security (TLS), are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols are used in applications such as web browsing, email, instant messaging, and voice and video over IP communications. Websites and servers can use SSL/TLS to secure all communications between their servers and web browsers and/or clients. SSL/TLS typically uses digital certificates to help identify and validate the authenticity of the server.
• SSL Offloading/Bypass - Offloading is a technique of offloading cryptographic protocol calculations onto a specialized system (the ADC). With offloading, the ADC terminates the secured connections between the client and the ADC, and establishes a second secured or unsecured connection to the server destination host. Bypass is a setting to bypass this technique and simply route the secured traffic to the destination host itself.
• Tenant - Tenant is a segregated space within the VidyoPortal. Using Tenants, each group of users within an organization is divided into its own segment and domain for conferences.
• VidyoCloud Hybrid Component - A server component hosted on a user's/customer's premise, providing local connection for media services. Currently available hybrid components are VidyoRouter, VidyoGateway, and VidyoReplay. Each hybrid component registers and integrates with the VidyoCloud portal and system.
• VidyoProxy - For implementations where the signaling and/or UDP ports are closed on the user’s/company network, the VidyoProxy solution overcomes these blocking issues in a secure fashion by tunneling the Vidyo traffic on port 443 using industry standard TCP SSL (Secure Sockets Layer). For more information on the VidyoProxy solution, see Appendix B. VidyoProxy in the VidyoPortal and VidyoRouter Administrator Guide.
• Web Proxy - A forward proxy, which is an intermediary for its associated clients to contact any server. A web proxy may be a Transparent proxy, also known as an intercepting proxy, inline proxy, or forced proxy. A transparent proxy intercepts normal communication at the network layer with or without requiring any special client configuration. Clients need not be aware of the existence of the proxy. A transparent proxy is normally located between the client and the Internet, with the proxy performing some of the functions of a gateway or router, and typically controls which internet services a client is allowed to access.
• X-Forwarded-For - The X-Forwarded-For (XFF) HTTP header field is a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer.

VidyoCloud

With VidyoCloud, users access and connect using a Vidyo-hosted VidyoPortal in the cloud. Most customers also use cloud-hosted media services (VidyoRouter, VidyoGateway, VidyoReplay, and Vidyo WebRTC). Some customers may, however, have certain media services hosted locally at their own premises or data centers (a.k.a., VidyoCloud hybrid components, which currently include VidyoRouter, VidyoGateway, and/or VidyoReplay).

The following VidyoCloud scenario items cover client access to the VidyoCloud services, as well various possible hybrid components; each running behind an ADC with the ADC acting as either a Web Proxy and/or Reverse Proxy for the hybrid components between the clients and/or hybrid components and VidyoCloud hosts.

• Vidyo Client Access (Desktop and VidyoRoom Clients) - Vidyo clients accessing VidyoCloud components from behind the ADC.
  
  
  
  
  • General firewall and client networking info: see VidyoCloud Firewall Information for Connecting Clients/Endpoints
  • Follow VidyoPortal global DNS records for DR failover possibilities. (ADC needs to provide DNS services (often service of GTM) and may require iRule or similar to achieve this.)
  • Should be configured to use sticky sessions to VidyoPortal and any other VidyoCloud component client it may be connecting with.
  • DNAT - Difficult with DR and possible dynamic VidyoPortal IP addresses; if DNAT portal, then it's best to follow public DNS records for proper DNAT mapping. Other VidyoCloud media server resources are also difficult to use with DNAT due to cloud component scaling and elasticity: units are added and removed as needed and specific IPs are not always available.
  • SSL Offloading (with DNAT) - Tenant/EMCP/SCIP addresses must match. Bypass is recommended to avoid possible difficulty maintaining.
• VidyoCloud Hybrid Component - Vidyo server components accessing VidyoCloud components from behind the ADC.
  
  
  
  
  • General hybrid networking info: see VidyoCloud Hybrid Implementation
  • Follow VidyoPortal global DNS records for DR failover possibilities. (ADC needs to provide DNS services (often service of GTM) and may require iRule or similar to achieve this.)
  • Should be configure to use sticky sessions to VidyoPortal.
  • General Web Proxy - Server components to do support connections via web proxy, a web proxy rule/exception is required.
  • SSL Offloading - Where applicable, server FQDNs must match.  Bypass is recommended to avoid possible difficulty maintaining.
  • DNAT - Difficult with DR and possible dynamic VidyoPortal IP addresses; if DNAT portal, then it's best to follow public DNS records for proper DNAT mapping. Other VidyoCloud media server resources: elasticity, units are added and removed as needed, and specific IPs are not always available.
    
    
  • Hybrid VidyoRouter
    • If behind a NAT, it needs a 1-1 NAT: Each VidyoRouter server needs its own public IP. Be sure to follow VidyoRouter NAT configuration guidelines as outlined in the VidyoPortal and VidyoRouter Administrator Guide.
    • SSL Offloading is achievable for signaling and VidyoProxy (SCIP: 17990_TCP and 443_TCP respectively). The ADC certificate and the local VidyoRouter SSL certificate must have the same CN (common name) for the signaling and VidyoProxy address (or use the same certificate and key at both the ADC and the VidyoRouter).   
    • UDP traffic cannot be offloaded because certificates are not used (the UDP media uses per session keys), thus UDP needs a bypass.
      
  • Hybrid VidyoGateway
    • If behind a NAT, it needs a 1-1 NAT: Each VidyoGateway server needs its own public IP if access is needed from Public Legacy endpoints and/or if the VidyoGateway is not connecting to local hybrid VidyoRouter(s).
    • SSL Offloading - N/A
  • Hybrid VidyoReplay
    • If behind a NAT, it needs a 1-1 NAT: Each VidyoReplay controller needs its own public IP if access is needed from Public endpoints and/or if all the VidyoReplay servers are not connecting to local hybrid VidyoRouter(s).
    • SSL Offloading - Controller server FQDNs must match (Replay CMS TCP_443 only). Bypass is recommended to avoid possible difficulty maintaining.
      
      

On-Prem

On premises installations (also known as "on-prem") are Vidyo installations where the customer hosts the full Vidyo solution on their own premises or data center(s). The information below covers running the various components on-prem and behind an ADC that's acting as a Reverse Proxy and that supports external users on the public Internet.

• VidyoPortal
  • Should be configure to use sticky sessions to the VidyoPortal.
  • SSL Offloading - Achievable for both web services (TCP_443), EMCP signaling (TCP_17992), and RMCP signaling (TCP_17991). Server FQDNs must match. Bypass is recommended to avoid possible difficulty maintaining. (This is N/A for all-in-one VidyoPortal/VidyoRouter deployments.)
  • Follow VidyoPortal global/local DNS records for Hot Standby (1+1 no shared IP) or DR failover possibilities, if implemented. (ADC may need to provide DNS services (often service of GTM) and may require iRule or similar to achieve this.)
  • Hot Standby [1+1 with Shared IP (Virtual IP / VIP)]
    VidyoPortal automatic failover solution for high availability, using shared IP address.
    • If behind a NAT, only need Public IP for Shared IP (VIP) with NAT to internal Shared IP (VIP).
    • ADC (DNS) needs to resolve to and only use the Shared IP (VIP) for the active Portal.
  • Hot Standby [1+1 no Shared IP]
    VidyoPortal automatic failover solution for high availability, without using shared IP address (allows for the two portals to be on different subnets/locations).
    • If behind a NAT, it needs a 1-1 NAT: Each VidyoPortal needs its own public IP.
    • ADC (DNS) needs to resolve to and use the IP (both internal and external appropriately) for the active Portal. See Hot Standby configuration in the VidyoPortal and VidyoRouter Administrator Guide for more information on this Hot Standby setup. The ADC itself can be used to handle the failover for this use case.
• VidyoRouter
  • If behind a NAT, it needs a 1-1 NAT: Each VidyoRouter server needs its own public IP. Be sure to follow VidyoRouter NAT configuration guidelines as outlined in the VidyoPortal and VidyoRouter Administrator Guide.
  • SSL Offloading is achievable for signaling and VidyoProxy (SCIP: 17990_TCP and 443_TCP respectively). The ADC certificate and the local VidyoRouter SSL certificate must have the same CN (common name) for the signaling and VidyoProxy address (or use the same certificate and key at both the ADC and on the VidyoRouter).  
  • UDP traffic cannot be offloaded as certificates are not used (the UDP media uses per session keys), thus UDP needs a bypass.
• VidyoGateway
  • If behind a NAT, it needs a 1-1 NAT: Each VidyoGateway server needs its own public IP, if access is needed from Public Legacy endpoints.
  • SSL Offloading - N/A
• VidyoReplay
  • If behind a NAT, needs a 1-1 NAT: Each VidyoReplay controller needs its own public IP, if access is needed from Public endpoints.
  • SSL Offloading - Controller server FQDNs must match (Replay CMS TCP_443 only). Bypass is recommended to avoid possible difficulty maintaining.
• Vidyo WebRTC
  • If behind a NAT, it needs a 1-1 NAT: each Vidyo WebRTC server needs its own public IP, if access is needed from Public endpoints.
  • If supporting TURN on a Custom Port, then a second public IP with 1-1 NAT to secondary internal IP is also required.  Each Public IP then also requires is own unique FQDN.
  • SSL Offloading - Session Manager server FQDN must match (WebRTC Session Manager TCP_443 only).  Bypass is recommended to avoid possible difficulty maintaining.
  • WebRTC Session Managers can be load balanced and/or geographically resolved using DNS load balancing and health checks, and/or Geo-based resolution.