But what if our network doesn't support multicast? Maybe the enterprise network isn't engineered for multicast, or we have to traverse public networks (such as the Internet) where multicast isn't available. What happens then?

Here, the distribution of traffic from the person speaking to the people listening has to go via some sort of central point that all the users are connected to. We call this 'unicasting.' The ICE Rallypoint component provides this centralized point of interconnectivity.

Things like access control, encryption, floor management, audio transcoding, and other functions usually conducted by servers are delegated to the ICE clients themselves because ICE operates under the assumption that the network is multicast in nature and that no centralized server architecture is necessary. ICE Rallypoints are a means to create a "multicast-like" environment on non-multicast networks. With the understanding, though, that when using Rallypoints, network traffic utilization is pretty similar to what you'd see in traditional, server-based unicast systems.

In a unicast environment, a stream coming from one user and being sent to others through a central point creates multiple streams on the network. The count of those streams is comprised of the stream coming from the person transmitting, and one stream each for each person receiving it.

In a unicast environment, the number of streams (and therefore bandwidth utilization) is directly proportional to the number of people speaking and listening.

Obviously unicasting is far less efficient than multicasting and will not scale cleanly in the same way that multicasting does. In a unicast environment, it’s important that we concern ourselves with how many people may be sending traffic as well as how many people will be receiving it. And, of course, we have to be concerned (as with multicasting) with how many channels we have in the system since it's a big multiplier in calculating bandwidth utilization.