Simple Multicast Audio Conference
Initially the owner of the conference (say the leader of a group) through some allocation mechanism obtains a multicast group address and pair of ports. One port is used for audio data, and the other is used for control (RTCP) packets. This address and port information is distributed to the intended participants. If privacy is desired, the data and control packets may be encrypted, in which case an encryption key must also be generated and distributed.
Each participant sends the audio data in small chunks (say 20ms) or packets. The structure of the packets will be discussed later.
Each instance of the audio application (i.e. each participant) in the conference periodically multicasts a reception report plus the name of its user on the RTCP (control) port. This helps to monitor quality of transmission and also determine who the present participants are.
Audio and Video Conference
If both audio and video media are used in a conference, they are transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. The canonical name or CNAME of individual participants are used to match the audio and video sessions. We will CANME when discuss functions of RTCP.
The sessions are divided so that a participant may choose only one of them. If there is lecture going on, you can just listen to the professor without having to see his face -:).
Mixers and Translators
So far, we have assumed that all sites want to receive media data in the same format. However, this may not always be appropriate. For users having connections of different bandwidth or those working behind a firewall which won't allow IP packets to pass will need some extra processing. This is done in the form of mixers and translators. We will discuss them briefly in the next two pages.