Proposed Audio Conferencing Protocol

The Mutualcast mentioned above is our basic audio conferencing protocol.

Although the media path of Figure 3.1 is separated from the main architecture, it still plays a substantial role as a whole. And our proposed conferencing control protocol is directly compatible with the media path module of Figure 3.1. There are some problems which the author of Mutualcast audio conferencing protocol did not address definitely. We focus on the most important problem－Packet loss rate and propose an enhanced protocol.

The problems and their improvements are addressed in the following:

z Packet may get lost before mixers receive it.

z Packet may get lost after mixers delivered it.

Packet get lost before mixers receive it

The compressed audio is split into frames by the encoder and these frames are cut into pieces to match the appropriate size of the packet. Then the audio media stream would be delivered through RTP [19] (Real-time Transport Protocol). As a result of RTP on the top of UDP, packets delivered between peers who are participants

nodes failure of routing path, traffic congestion, and packet collisions. And packets loss could be worse if the number of peers increase and number of packets exponentially boosted in the Mutualcast conferencing control protocol.

Unlike TCP, UDP used by RTP will do nothing on packets loss and it looks the same as in the Mutualcast. It will be grisly if there are packets lost in the Mutualcast, because one lost packet means that the other packets in the mixer would be discarded likely. If the mixer discards all packets in the buffer queued for only one packet loss, the quality of voice will become worse due to the increased participants of the audio conference.

In order to solve this problem, it is suggested to force the mixers to mix the appropriate frames in the buffer queue and skip to receive remaining frames considered as packets lost for a limited period. The period is difficult to demarcate because the packets probably delay too long or transship by too many steps.

Nevertheless, it is well known that in order to allow natural conversation, the mouth-to-ear latency of a voice-communication should not exceed 300 ms [20]. Thus we assume that if all appropriate packets are not collected in time, the mixers should buffer frames until the timer clocks exceed 200ms for eliminating the packet propagation time between participants of the audio conference and improving the quality of voice.

Packet gets lost after mixers delivered it

After the mixers send out packets of mixed frames, it is still unreliable for delivering on the network according to the properties of UDP and the increased traffic load results in packet loss of mixed frames. For more robust delivery rate, the relay nodes we mentioned in Section 3.1.1 are introduced to achieve our purpose.

The network structure is shown in Figure 3.5 which is similar to the Mutualcast

conferencing control protocol except relay node and backup node. Let us explain how this method operates by taking Figure 3.5 as an example. The improved Mutualcast will form a clique connection of 5 nodes including 4 participants of the audio conference and 1 relay node, and schedule the mixer order of 4 participants (bottom of the figure 3.5). At first all participants except user A will send their first packet (frame) to user A (the first mixer), and when user A receives all first packets from other participants, he will mix the frames by his decoder and copy the mixed frame to send to relay node. The mixed frames will include all the participants’ first frame (such as the first mixed packet: P_a,1+P _b,1+P _c,1+P _d,1) and be redelivered by relay node to all of the participants except the mixer who sends the packet to relay node.

Participants use their decoders to eliminate their echo in the mixed packets (user C should eliminate P c,1 in Pa,1+P b,1+P c,1+P d,1).

Figure 3.5 Improved Mutualcast conferencing media stream control protocol.

The backup node will be operating only when the relay node failed. The founder should be aware of the failure of the relay node by checking RTCP [19] report for the relay node in a regular period. Moreover the number of the relay nodes will be up to 3 for alleviating the traffic load to the relay node.

In Chapter 4, simulation results demonstrate the improvement of our proposed system and packet loss is reduced as well.

Silence suppression

Silence suppression is an important functionality in VoIP, because a person will not speak from beginning to end in the audio conference or two party communications.

When a participant stops delivering his voice frame after he finishes his speech, it turns to the other participants to talk. In Mutualcast, we can assume that the functionality of silence suppression is not used at all in order to deliver the sequentially numbered packets which are marked by each peer respectively.

For this scenario, we use a blank packet to substitute the original unknown approach and the packet will just inform the mixer that participant is silent and no need to decode the voice frame in packet for that participant.