From UW Center for Collaborative Technologies Wiki
- Scenarios for which we might like to enable or improve workarounds include the following:
- Clients on networks with low throughput inbound and/or outbound
- Clients on unreliable networks (high loss)
- Clients using systems with weak CPUs
- Clients on networks which do not support multicast
- For clients on low throughput networks: With the current mapping of one multicast address per venue we require that all venue participants have enough network bandwidth to receive all streams in the venue. In the case of a conference between participants with heterogeneous bandwith capabilities, the participant with the smallest inbound bandwidth defines the upper limit on number and quality of streams in the conference. Exceeding the limit of the lowest bandwidth participant will result in an unsatisfactory experience for that participant. An improved design would split the venue across multiple multicast groups and give clients some control over inbound bandwidth.
- Clients on unreliable networks might be helped by adding NACK-based functionality such as PGM. We may want to research this area.
- Clients on systems with weaker CPUs can currently perform varous manual workarounds such as turning off the rendering of inbound video streams and disabling outbound video. Additional flexibility for clients to deal with this case could be provided by redesigning the venue to span multiple multicast groups. We could consider the automatic detection of a CPU constraint causing a warning, and/or automatic suspension of video rendering, with the goal of allowing audio streams to continue encoding and playing without choppiness.
- Clients on networks which do not support multicast are already well served by the CXP Reflector service. Possible enhancements to reflector include the addition of automatic failover, Integration of reflector functionality into the standard CXP node