Venue Redesign for Heterogeneous Networks and Clients

From UW Center for Collaborative Technologies Wiki
Jump to: navigation, search

Redesign Overview

Conferences involving clients and networks of significantly different capabilities today require all participants to 'turn down' the quality in order to support the client with the least capabilities. Although there are workarounds today involving running multiple instances of the client to send and receive at different quality levels, these are overly complicated for the average user. This redesign provides native support for a venue that consists of more than one multicast group, and thus can provide a scaled quality experience depending on local capabilities.

Some goals for the redesign

  • Flexibility: Users and/or venue administrators should be able to configure venues in a variety of different ways. The venue should be able to use as many groups as make sense for most any scenario. Users of the multi-group venues will be able to assign devices and capabilities to groups without unnecessary restrictions
  • Ease of use: sensible configured defaults and client persistence should reduce mouse clicks and required user expertise.
  • Backward compatibility: Traditional venues consisting of a single group continue to exist and function. This should be a point release, meaning that we hope to allow 5.0 clients to continue working in legacy venues with updated clients and services.
  • Though this may not be part of the initial work, we consider API and other changes to accommodate dynamic venues, that is venues created on-demand.
  • We will not initially attempt to do any multiple encoding or transcoding to support different quality levels from a single device. If a node needs to send both high and low bandwidth video, for example, it will require two cameras.

Typical usage patterns

  • Configuration: The venue service admin creates and names one or more venues of the multi-group type, and provides one or more multicast addresses. The addresses may either be in a pool which can be used across multiple venues on the server, or they may be assigned to particular venues. The multi-group venues may have a configured default and maximum number of multicast addresses. Multi-group venues may have configured payload and quality defaults (eg. audio, low-quality video, high-quality video). Dynamic venues may be named venues that appear to the client as do legacy venues, or they may be venues that are created and named on demand by the client.
  • Joining the venue: When a user enters the multi-group venue, the server will resolve and return the multicast addresses. If the venue consists of more than one group, the user will be prompted with a list and asked which groups to use. If the user selects more than one group, there may be another prompt to ask the user to assign sending devices and capabilities to groups. Configured rules about which capabilities belong in which groups could be used to avoid having the second prompt. The most recent set of capability assignments and selections will be persisted on the client. Some modifications to the received groups and capability assignments may be possible to support without forcing the client to leave the venue.
  • Adding capabilities: The user initiating a capability will need to choose the group or groups to use.

Venue Service changes for multi-group venues

Backward Compatibility: A goal for the redesign of the venue service is to maintain some kinds of backward compatibility with 5.0 venue data files and with 5.0 clients.

  • Upgraded venue services should be able to open the 5.0 venue data files, however changes saved by the updated service do not need to remain compatible with 5.0 services.
  • Upgraded clients should continue to work with 5.0 venue services and 5.0 clients
  • 5.0 clients should work with upgraded venue services, but should not show multi-group venues.

As the existing storage classes and webservice APIs are changed, this must be done in such a way as to maintain compatibility, eg. we can add new optional members to existing classes. An alternative and possibly better solution in some cases is to create new storage classes and new APIs, while still supporting the old ones.

Storage and API changes: To implement multi-group and dynamic venues we will introduce:

  • A new VenueType enum added to the Venue class. This will be added before the 5.0 release with the initial value always set to the legacy venue type.
  • A DynamicVenue class containing the details of the dynamic or multi-group venue
  • A new variant of the GetVenue webservice API to return dynamic and multi-group venues.

New and old clients will continue to use the existing GetVenues API to get the initial list of venues. The VenueType enum will allow new and old clients to do the right thing with legacy and multi-group or dynamic venues.

Venue Admin Tool: The tool will need new UI to support for adding multiple groups and setting default stream types, labels and other properties.

Client: The compatible client will receive the initial venues list from the server as is done currently. When the user clicks to join a multi-group or dynamic venue, the client will use the updated GetVenue API to retrieve venue addresses and properties.

Dynamic Venue Workflow: Dynamic venues are created on demand by the venue service from a pool of multicast addresses. The workflow may be as follows:

  • The client requests a venue, including in the request the number of multicast groups, the name, an optional password, a timeout.
  • A second client requests the venue by name, may be prompted for a password, then is given the multicast groups.
  • As clients use the venue, they send periodic keep-alive messages to the venue service.
  • After the last client leaves, and the timeout elapses, the venue's multicast addresses are reclaimed to the pool by the venue service.

To support the dynamic venue workflow, we will need a few new API's and API variants to make the initial request and to carry out the keep-alives. Again, the VenueType enum can be used to allow new and old clients to ignore unsupported venues and use correct APIs to interact with new venue types.

Archiving multi-group venues

Backward Compatibility: We want to maintain the following kinds of backward compatibility

  • 5.0 clients should be able to record and playback from upgraded archive servers
  • Upgraded clients should be able to record and playback single-group venues on 5.0 archive servers
  • Upgraded clients should be able to playback from upgraded servers into venues with both new and old clients.
  • 5.0 databases should be compatible with upgraded archive servers.

Archive: When requested to archive a multi-group conference, the archive service will join and archive data from all groups. The participants and streams from all groups will be recorded using a single entry in the conference database. The following changes will be made to support this:

  • A new API will be added to allow the client to find the Archive Service version. This will let upgraded clients know to allow archiving in multi-group scenarios. This change will be made prior to 5.0
  • A new variant of the RecordConference API will be added to support multi-group recording
  • A new attribute will be added to the Participant table to indicate which multicast group was used to originate the participant's streams. This will be added prior to the 5.0 release, but initially left unused.

Playback of a multi-group recording: When a playback is requested, the user will select streams across all multicast groups involved in the conference. This should require no changes.

Playback into a multi-group venue: When a client in a multi-group venue initiates a playback from an upgraded archive service, the user will be prompted to select which streams to play into which groups. Additional changes needed to support this:

  • A new variant of the Play API to accept multiple multicast groups and multiple sets of stream ID's.

Using Reflector in the multi-group scenario

A multi-group reflector client node will need to send and receive data for multiple multicast groups to/from the reflector. The reflector currently builds a table mapping client endpoints to multicast groups. When unicast packets are received, the reflector looks up the endpoint in the table to determine which multicast group to send to. To support a client with multiple reflected groups, we can bind different port numbers for each multicast group on the client so that the client will have one endpoint per group. With this change the existing reflector code should function as-is. One disadvantage to this approach is that sites with organizational firewalls will need to have changes made, but this can be mitigated if the design continues to use well-known ports, eg. 7004-7013 would handle scenarios up to 5 groups.

Using the Diagnostic service in the multi-group scenario

Currently we are encoding the venue name into RTCP App packets, and sending these along with sender and receiver reports to the diagnostic server for aggregation. Currently this venue name is the only key that the diagnostic service has available to do the aggregation. In multi-group scenarios we will want the diagnostic server to be able to build reports per-group, but also to show all the groups that are currently being used in a venue. A simple way to support this will be to encode additional information in the app packet to identify both the group and the venue.

The diagnostic service currently supports a webservice call accepting a venue name and returning a connectivity matrix. In multi-group scenarios we will want to retrieve one matrix per multicast group instead of one matrix per venue. This can be implemented with an update to the webservice API. To permit updated clients to operate properly with 5.0 diagnostic service in a single-group environment, we will also add a GetVersion API prior to the 5.0 release.

Changes for ConferenceXP 5.0

For the ConferenceXP 5.0 release we plan to include the updates which will enable implementation of the venue redesign without breaking 5.0 clients. Of course the 5.0 clients will not support multi-group venues, but they should still be able to use legacy venues to work with updated clients and services.


  • After the GetVenues call, we will filter out and ignore any venues that are not of the legacy type.

Diagnostic Service

  • Add the multicast group to RTCP App packets
  • Add a GetVersion API to allow updated clients to determine whether multi-group scenarios are supported.

Venue Service

  • Add a VenueType enum to the Venue class so that 5.0 clients will be able to ignore future dynamic or multi-group venues.

Archive Service

  • Add a GetVersion API to allow updated clients to determine whether multi-group scenarios are supported.
  • Add an attribute for the multicast group to the participant table.