VIP Beacon and Invitation Server

The Beacon server is a container in the VIP suite and facilitates many aspects of remote audio and connection discovery and negotiation using the popular WebRTC codecs. Beacon acts as a signalling server to handle the primary connection and communication process for WebRTC connections between panels and accessories. It coordinates the exchange of SDP information and keeps track of real-time connections, ensuring both connections are established and terminated correctly. The Beacon server also coordinates invitation management and user authentication in the VIP architecture.

Beacon provides the following primary functionality:

VIP Virtual Panel Management
User Management
Email Integration
WebRTC Signalling
Connection Tracking
Invitation Mechanism

Setting Up the Beacon Server

The first login will require some setup from a site administrator.

The fields shown below in Figure 2 must be filled out, and the information entered will serve as the main Beacon administrator account login.

Once the correct information has been entered, click "Save," then log in with your newly-created account details.

Once logged in, the main Beacon landing page will appear which allows management of e-mail servers, VIP Invites, and more.

Clicking on the “VIP: VIP Link Gateway” and this will show the list of virtual panels associated with that gateway (see Figure 5)

In this configuration, clicking on VIP1: Director shows the user the virtual panel has been associated with (see Figure 6). Clicking on the “Link” button will provide a URL that can be emailed to the user allowing them to operate their internet virtual panel. When the user has connected to the virtual panel through their browser, the status will change to “On Line”. User access to the virtual panels is managed using the “edit’ button to enable the virtual panel for a specific time.

Creating and Managing Users

There are two types of user roles available:

Admin - Has permission to change settings and manage users.
User - Has permission to access invitations.

Settings

The Settings section is at the heart of the Beacon server's purpose: Sending e-mail invites and finding the best network route for audio connections.

STUN Servers (Session Traversal Utilities for NAT)

STUN is used for many underlying protocols including WebRTC. It provides a tool for hosts to discover a network address translator, and to discover the mapped IP address and port numbers the NAT has allocated between remote hosts. This allows devices to establish direct peer-to-peer connections, even when they are on different networks and behind other NATs. A NAT device allows multiple devices behind the network to use the same public facing V4 IP address.

A STUN server acts as a public facing service that allows devices to determine their public IP address and port as seen from the internet. When a device behind a NAT, such as the Directors virtual panel, needs to establish a connection with the Sound virtual panel on a separate internet connection, it sends a request to the STUN server asking for the Sound virtual panel. The STUN server responds with the virtual panels public IP address and port, which can then be used to set up a direct connection.

You may provide your own STUN server address or use one of the many free STUN services available, such as the one from Google included in the container.

TURN Servers (Traversal Using Relays around NAT)

A TURN server is used to relay WebRTC data in the event STUN connections fail. In order for most WebRTC applications to function, a server is required for relaying the traffic between peers since a direct socket is often not possible between the clients (unless they reside on the same local network).

TURN servers require bandwidth to relay audio data between VIP clients and VIP hosted servers, either on-prem or cloud-provided. As a result, their services are typically not free.

For geographically diverse clients, it is recommended to specify several TURN servers as doing so greatly reduces the risk of "trombone routing" which can add significant latency.

E-mail Server Settings

In order for the Beacon server to send invites, it needs access to an account from which to send e-mails. Several different e-mail protocols are supported:

SMTP - Simple Mail Transfer Protocol, perhaps the most commonly used protocol.
Mailjet - A cloud-based e-mail delivery and tracking system which allows users to send marketing and transactional e-mails.
Mailgun - An API-based e-mail delivery service for sending, receiving, and tracking e-mails.
Sendgrid - A communication platform for marketing and transactional e-mail.

Once all e-mail credentials have been entered, click on the "Save App Setup" button, then send a test e-mail to yourself. If everything is correct, you will see two successful notifications in the bottom right corner as shown below in Figure 10.

Miscellaneous Section

Public URL - This is the public web address of the Beacon server, and is populated with the URL entered from the "#3 Set VIP Domain Name" field of the main VIP menu. If this field is empty in the main VIP menu, run Option #3 from the main menu again.
Public URL Override - This option can be used for systems employing a custom proxy of the Web URLs but is not used in a typical setup and can be left empty.
Invite Password Length - Determines the length of the randomly-generated password required to join the invite; zero-length passwords are permitted.