acket with timestamp 160 is actually generated at employ the retransmission of erroneous data [56-60]. time 10:20:30.725, assuming that a 8000-Hz clock is used Unlike FEC schemes, ARQ intrinsically adapts to the for audio timestamping. Similarly, for video packets, the varying channel conditions and tends to be more efficient in receiver can also calculate when each video frame is sam- transmission. However, for real-time communication and pled. In this way, the receiver can easily find out which part low-latency streaming, the latency introduced by ARQ is of audio data and video data should be played back at the a major concern. In addition, like all feedback-based error same time. control schemes, ARQ is not appropriate for multicasting. 3.6.4 Summary and further reading 3.6.3.3 Adapting to the available bandwidth In this chapter, we have described the system and ar- chitecture for real-time communication, including two Due to the lack of a QoS guarantee over most com- categories of the most important protocols, signaling and mercially deployed networks, it is expected that the transport, respectively. We have also addressed the QoS condition, as well as the available bandwidth of the issues, especially on minimizing latency, combating network, varies during a real-time communication ses- losses, adapting to available bandwidth, and audio-video sion. It is beneficial to employ bandwidth adaptation synchronization. Real-time communication over networks CHAPTER 3.6 RTP Sender RTP Receiver Audio RTCP SR control packet packet S=160 for audio RTP session control sent at 10:20:30.730 packet 10:20:30.730, audio session Audio RTP packet with TS=200 TS=160 was sampled at 10:20:30.725 Video RTCP SR control packet packet TS=3000 for video RTP session control sent at 10:20:30.750 packet 10:20:30.750, video session TS=4800 Video RTP packet with TS=3000 was sampled at 10:20:30.730 Figure 3.6-10 An example of audio and video synchronization. References [1] J. Rosenberg, H. Schulzrinne, G. [11] I. Dalgic and H. Fang. "Comparis