If you plan to use video conferences in your organization, you must ensure that your users are on multicast-enabled networks, or that they can be bridged into a video conference.
The following topics will help you implement video conferencing in your organization:
Multicast clients have the most feature-rich user experience with video conferencing and Exchange Conferencing Server. The following sections provide background information on IP multicast, multicast addresses, Time to Live (TTL) value, multicast groups, multicast scopes, and IP addresses that are reserved for multicast.
IP multicast is an extension to the IP network layer protocol defined in RFC 1112. It provides an efficient way of transmitting packets on the network from one or more sources to many destinations.
There are three basic modes of transmitting packets over an IP network: unicast, broadcast, and multicast.
In unicast mode, packets are transmitted over a point-to-point connection. If there is more than one recipient for the packet, several point-to-point connections are established and a copy of each packet is sent to each recipient.
In broadcast mode, a single copy of a packet is sent to the entire network, including subnets that don’t have recipients for the packet. Thus, extra traffic is created that consumes valuable network bandwidth.
In multicast mode, a single copy of the data is transmitted to subnets that have a recipient host subscribed to the session. Hosts subscribe to the session by joining a multicast group, which they do by propagating (through Internet Group Management Protocol) a pair of addresses — multicast address and recipient’s IP address — to the routers on the network.
Class D IP addresses, in the range 224.0.0.0 to 239.255.255.255 are called multicast addresses. Packets sent to an address in this range are not addressed to a specific host. Any host that has knowledge of a specific multicast address can join a multicast group identified by this address. Once a host joins, routers start forwarding all packets that they encounter to the subnet on which the host resides. The host can then pick up the packets being sent to that address. A host can become a member of any number of multicast groups.
It is not a good idea to distribute all packets sent to all multicast addresses. Multicast packets have a specific lifetime. The Time to Live (TTL) value identifies the lifetime of these packets. Every time a router is hit in the path of the packets, the TTL value is reduced by one, and if the value is zero, the router does not forward the packets any further. This means that packets with a TTL value of one are distributed on the subnet only. Multicast datagrams with a TTL value greater than one can be delivered to more than one subnet, if there is one or more multicast routers attached to the first subnet.
An IP multicast group, also known as a host group, is a set of hosts that finds IP traffic destined for a specific multicast IP address. Multicast IP traffic is sent to a single media access control (MAC) address but processed by multiple IP hosts. A given host receives all packets sent to a specific IP multicast address.
Internet Group Management Protocol (IGMP) manages IP multicast groups. The membership of a host group is dynamic. Hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.
A host group may be permanent or transient. A permanent group has a well-known, reserved IP address. These addresses are registered with the Internet Assigned Numbers Authority (IANA). (For more information, see “Reserved Addresses,” later in this chapter.) It is the address, not the membership of the group, that is permanent; at any time, a permanent group may have any number of members or no members.
The IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups that exist only as long as they have members. Members of a host group can span IP routers across multiple networks. This requires IP multicast support on the IP routers and the ability for hosts to register their group membership with local routers. Host registration is accomplished by using IGMP.
For a host to receive IP multicasts, a client application must inform the local router that the application will be receiving multicasts at a specified IP multicast address. If the network technology supports hardware-based multicasting, then the client application signals the network interface card to pass up packets for a specific multicast address. With Ethernet, the network interface card is programmed to respond to a multicast MAC address corresponding to the desired IP multicast address.
In order to facilitate IP multicast between subnets, the routers must be multicast aware. Routers maintain special routing tables that enable them to decide whether to forward multicast traffic to the specific network or not. Routers propagate routing information and create a router topology, known as a spanning tree, for each multicast session. The spanning tree is constructed so that a single path exists between any pair of participating routers, without any loops.
A range of multicast addresses and an associated TTL define a multicast scope. The scopes used for video conferences are retrieved from the scopes defined on the organization’s MADCAP servers. By using scopes in conjunction with configuration of routers, you can limit the reach of multicast packets on the network. You can apply additional restrictions by configuring boundary routers for specific multicast scopes.
The following table contains a partial list of Class D addresses reserved for IP multicasting and registered with the Internet Assigned Numbers Authority (IANA). These are the addresses of the permanent, well-known groups mentioned earlier.
| Multicast group | IP multicast address | Description |
| Base address | 224.0.0.0 | Reserved |
| All hosts | 224.0.0.1 | Contains all systems on the same network |
| All routers | 224.0.0.2 | Contains all routers on the same network |
| Network Time Protocol | 224.0.1.1 | Distributes time-clock data used to synchronize time on a group of computers |
| RIP version 2 | 224.0.0.9 | Distributes routing data between a group of routers that use the version 2 raster image processor (RIP) |
| WINS server | 224.0.1.24 | Supports auto-discovery and dynamic configuring of replication for WINS servers |
A multicast router does not forward multicast datagrams with destination addresses from 224.0.0.0 through 224.0.0.255 regardless of their TTL value. This address range is reserved for routing protocols and other low-level, topology discovery protocols or maintenance protocols. These include gateway discovery protocols and group membership reporting protocols.
Although MADCAP is packaged with the Dynamic Host Configuration Protocol (DHCP) service, DHCP and MADCAP are independent of each other. You can use a MADCAP server to provide multicast addresses and run DHCP on other servers on your network.
For networks using domains, you must authorize the DHCP service in the domain’s directory service database. This prevents users from setting up unauthorized DHCP services. This is not necessary if the server has been authorized already (for example, if it is already functioning as a DHCP server).
To have the DHCP server allocate multicast addresses using the MADCAP protocol, create a new multicast scope. After creating a new multicast scope, associate it with a TTL. For more information on configuring DHCP and MADCAP, see your Windows 2000 documentation.
To support and configure Video Conferencing Provider, you must have MADCAP installed on one or more servers. Configuring multiple MADCAP servers can improve server reliability and network efficiency; if one MADCAP server is down, another one can deliver the MADCAP service to your conferencing site.
If you have MADCAP installed on more than one server on your network, verify that the multicast IP scopes configured on the servers do not overlap. Because each of the IP scopes is also associated with a lease expiration period and advertising scope settings, configure each type of multicast IP scope you want on two or more MADCAP servers.
To use Video Conferencing Provider for multicast video conferences, your network needs to be multicast-enabled, and you need to configure multicast addresses. If this is the first IP multicast deployment in your enterprise, you may need to reconfigure some of your routers. However, if you have previously deployed multicast applications such as Windows Media Services, your network may already be ready to use multicast addresses.
If your network routers support Resource Reservation Protocol (RSVP), you can configure the quality of service (QoS) policy to allocate network bandwidth. You can apply the policy to the network, each subnet or individual users. Use QoS Admission Control in Windows 2000 to manage the policy. For further information on configuring QoS policy, see your Windows 2000 online documentation.
Before you decide on the maximum number of simultaneous connections allowed and configure the QoS policy, consider the bandwidth of your network and how you will use Video Conferencing Provider in your organization. Will you have conferences that require all participants to send video and audio? What percentage of conferences will be audio only?
Try to calculate the peak video and audio traffic on your network. Depending on the coder/decoders (codecs) used, audio streams consume from 21 kilobits per second (Kbps) (GSM 6.10 codec) to approximately 74.7 kilobits per second (Kbps) (G711). The video streams (aside from the codec) vary depending on the amount of movement in front of the camera. Expect 60 to 120 Kbps to be consumed by a video stream. As the number of attendees in a conference increases, the consumption of Kbps increases at a rate that is less than linear.
If you have routers on your network and you want to use multicast conferencing across the routers, you may have to configure the routers to handle multicast packets. Use the MCAST diagnostic tool included with the Windows 2000 Server Resource Kit to determine which parts of your network are enabled for transmission of IP multicast packets. Use the tool in send mode to set up multicast sources at different locations on your network. Use it in receive mode to determine where multicast traffic is being received. Windows 2000 also provides utilities to display the configuration of a multicast router (mrinfo), and to display multicast group tables and troubleshooting information for interfaces (routemon).
If the routers are not configured for multicast, you must create access lists specifying the range of multicast group addresses allowed to cross the routers, and associate these lists with specific interfaces on different routers. For more information, see your Windows 2000 documentation.
When a data and video conference resource is reserved for a conference, you can bridge the multicast video conference to H.323 NetMeeting clients. You can use the H.323 bridge in one of the following conditions:
When trying to join a conference, all clients check to see if they can establish a multicast connection to Conference Management Service by sending it a message. If a multicast connection can be established between Conference Management Service and the client, the client joins the multicast conference. If the client cannot connect to Conference Management Service, it connects to the MCU and the MCU requests an H.323 unicast bridge to the multicast video conference. Figure 4.6 shows a Windows 98 client participating in a multicast conference using the H.323 bridge.
Figure 4.6 Bridging Video Conferences
For other multicast conference participants, this H.323 client looks and sounds like any other multicast participant. The H.323 client hears each participant in the conference, but receives only a single video image of thespeaking participant.
Because only a single video stream is sent to and from the H.323 client, even users with slow links are able to participate in video conferences.
To improve performance, you can install more than one MCU on the portion of your network where you have many simultaneous users. The MCUs in this area may have the same scope mask restricting client access to the specific subnets or none at all, because the site’s Conference Management Service automatically balances the load among the MCUs.
To bridge video conferences, all MCUs that accept H.323 client connections must have multicast connectivity to the Conference Management Service on the server that is hosting the conference.
Video Conferencing Provider defines a resource size property based on the number of conference participants invited to online conferences at the same time. This maximum participant count defines the maximum number of audio and video streams that can be sent across the network at one time.
Each conference resource can also define the format of the video conference. You can configure the following properties on each Video Conferencing Provider conference resource:
For a conference in which all participants are directly connected to the multicast video conference, Video Conferencing Provider monitors the conference and prevents too many participants from joining.
When configuring IP address ranges for multicast scopes on the MADCAP server, there are two practices recommended by the Multicast Allocation working group, an Internet Engineering Task Force (IETF) team of industry volunteers who help set multicast address allocation standards.
Administrative scoping Use administrative scoping when you are using multicast IP addresses privately on your own network. You should start this scope in the 239.192.0.0 range. This range is known as the IPv4 Organization Local Scope and uses a subnet mask of 255.252.0.0 (14 bits in length).
Note Administrative scoping is fully discussed in RFC 2365, “Administratively Scoped IP Multicast.”
Global scoping Use global scoping when you are using multicast group IP addresses on a public network, such as the Internet.