Vonage Experience Composer - Best Practices

Objective

This article describes how Vonage customers can get the most out of the Vonage Experience Composer.

Applies To

• Vonage Experience Composer

Session Monitoring

Customers using the Experience Composer (EC) will typically be using two video sessions. One for the web app running inside the EC environment, these apps will typically connect to a session, subscribe to the publishers in that session and perform layout functions and app processing. The second session is for the EC itself and is passed (along with an access token) in the call to start an EC instance. The EC will then publish into this session, which can later be archived, broadcast or subscribed to elsewhere.

It is not recommended that customers use the same session for both the EC App and the EC session.

Customers should monitor the health of their web apps running inside the EC. This is more important for EC Apps because there are no live users or screens to monitor.  It is highly recommended that customers use Session Monitoring Callbacks to monitor their EC Apps.  Please see the session monitoring documentation for more details on events and how to receive callbacks. 

In Experience Composer Apps, the connectionCreated and connectionDestroyed events are particularly important as part of this session monitoring.

An EC web app may subscribe to many streams, but there will be only one connection to the session. If that connection is destroyed, all subscribed streams will be disconnected. If a connectionDestroyed event is received unexpectedly, then you can proactively start a new Experience Composer instance and reload your Web App.

You can also track individual streams.  The streamCreated and streamDestroyed events will notify your server through callbacks that streams have started and stopped. The streamDestroyed event has information to indicate the reason the stream was disconnected.  This can help to determine how your application should respond to this event.

Region Selection

It helps to keep traffic in one region to optimise quality. Once the session is created, it will happen automatically when the first user (or device) connects to it and will be based on that user's/device's geolocation. Subsequent components, such as the archiver and Experience Composer, will be allocated in priority to the same region (capacity permitting). It is recommended to have cloud services in the closest region to the publishing endpoints. 

By default, the platform chooses the region closest to the first connecting publishing endpoint, which also applies to the EC. 

A “location hint” can be used to control the region choice independently from the first connected publishing endpoint. By passing an IP address from the desired geographical region as a “Location hint,” when creating the session, the Vonage video platform will locate the session in the closest data centre (given there is capacity in the desired region). For more information, see Creating a session and passing a location hint.

Resource Creation

If you submit a large number of simultaneous requests for EC instances, some requests may arrive faster than our systems can scale.  This can lead to an HTTP 500 error on some of these requests.  

In these scenarios, it is recommended that you throttle those requests to 1 request up to every 3-5 seconds and ensure that you submit retry requests for any attempts that fail. This allows our systems to scale naturally and allocate the required resources.

Additional Information

This tutorial dives deep into session monitoring events, with sample code showing how to limit users' session connection time and forcibly disconnect them once their time is up.

The EC is not deployed globally in every region. See this article for more info on which regions have EC capability.