Speech Case

In order to test this control mechanism, we used an RTP/RTCP stack that we upgraded with the EB-TFRC implementation [5]. The network topology prepared for the tests is composed of a sender implementing TCP-Friendly, a router, and receiver. We used only one parameter (the codec type) to illustrate the interest of our control mechanism. Adding other parameters is of course possible; we think that the relevance will generally depend on the nature of the application. A local development (``bypass'' software developed at INRIA Sophia Antipolis) in the router simulates a bottleneck that happens after a minute of normal operation. In addition to the bottleneck, a delay is applied to packets going through the router. In Figure 8.2, we plot the behavior of the calculated bandwidth as suggested by TFRC and the saved bandwidth when the receiver decides to change from PCM (64Kbps) to GSM (13.2Kbps) codec based on a decision taken by the sender to maintain a good quality. We can see that when the bottleneck is detected, the sender adapts its rate to even less than the available bandwidth. In Figure 8.3, we compare the two measured MOS values at the receiver side for the case when the sender follows our control mechanism by changing the codec and the case when the sender blindly follows what TFRC suggests and hence continues using the PCM codec in the bottleneck periods. Clearly, the MOS is improved even in presence of congestion. The decision to change the codec, that is usually taken manually by an expert user (he/she has to understand all ``advanced features'' of the conferencing software) when he/she starts to suffer from the network conditions, is here taken automatically by our controller. Moreover, our control mechanism may also be helpful in the absence of congestion by deciding the best combination of the parameters by which the end-user will receive the best quality. Finally, by using this control mechanism, and to maintain a certain level of quality, the sender can decide to use the exact bandwidth required by the application in the absence of congestion and not to give only an upper bound. This is shown in the first part in Figure 8.2.

Figure 8.2: Rates suggested by TCP-friendly and the saving using control rules when changing the codec in the case of Speech

Figure 8.3: MOS values with and without our control when changing the codec in the case of Speech (CM stands for Control Mechanism)