Rapid Synchronization of RTP Multicast Sessions
Total Page:16
File Type:pdf, Size:1020Kb
42 IJCSNS International Journal of Computer Science and Network Security, VOL.10 No.9, September 2010 Rapid Synchronization of RTP Multicast Sessions Zlatan Begić† and Mladen Kos†† † BH Telecom Joint Stock Company Sarajevo, Directorate Tuzla, Tuzla, Bosnia and Herzegovina †† Faculty of Electrical Engineering and Computing, University of Zagreb, Zagreb, Croatia Summary canonical end-point identifier (CNAME) item included in Quality of Service (QoS) is an important, and admittedly the RTCP Source Description (SDES) packets generated overloaded, concept for emerging services based on the by the sender or signaled out of band [1]. According to [1], Real-Time Transport Protocol (RTP) to deliver multimedia in the absence of any packet loss, RTCP SR intervals content. In the context of the Internet Protocol Television (IPTV) sufficient for lip-synchronization of multicast RTP services, the synchronization of multimedia components plays an sessions without excessive delay are well defined. important role. In order to synchronize audio and video components of multimedia content, RTP timestamps have to be Recently [2], concern has been expressed that related. Periodic Real-Time Transport Control Protocol (RTCP) synchronization delay is problematic in case of network Sender Report (SR) packets, which associate the RTP timestamps congestion. in the stream with a common clock at the transmitter, are In order to overcome problems concerning associated with each stream. Thus, the frequency and the timing synchronization delay, prior proposals [3] were based on of the RTCP SR packets often contribute to the delay before idea to isolate RTCP SR packets from the RTP data stream audio and video are rendered, not just to their synchronization, by assigning them to higher priority class in Differentiated because many clients will not render anything before the Services (DiffServ) architecture which ensures the average synchronization has been established. Whereas the reduced minimum RTCP SR interval according to IETF synchronization delay is problematic in case of network congestion, the retransmission technique is used for the RTP RFC 3550, regardless of network congestion. This is receiver to request the rapid synchronization of RTP multicast feasible when it is not possible to offer an upstream sessions from the retransmission server (RS). This paper channel of RTCP receiver reports (RR). Accordingly, investigates the concept of isolation of the RTCP from the RTP since RTP and RTCP are sent using different ports, any retransmission packets by assigning them to higher priority class flow classification based upon port number that leads to a which ensures the synchronization delay of the multicast differentiation between RTP and RTCP flows could multimedia sessions sufficient for lip-synchronization without disrupt the statistics because RTCP flows (SR in excessive delay regardless of network congestion, with accurate conjunction with RR) are used to measure, infer and statistics measured by RTCP. A primary use case for this concept convey information about the performance of an RTP is to reduce the channel-change times in IPTV networks where compressed video streams are multicast in different Source media stream. Specific Multicast (SSM) sessions and viewers randomly join In this paper, a proposal is given to assign a higher priority these sessions. to RTCP than to RTP retransmission packets by using the Key words: DiffServ QoS techniques. Accordingly, the RTCP DiffServ, multicast, retransmission, RTP, RTCP, synchronization retransmission packets with a higher priority are less likely to be lost than the packets with a lower priority. Since RS sends a relatively small number of RTP retransmission 1. Introduction packets before receiver starts to receive the primary multicast stream, statistics measured by RTCP cannot be When using RTP to deliver multimedia content, it is often disrupted [4]. necessary to synchronize playout of the audio and video Extensive simulations are performed using the Network components of a presentation. This is achieved by using Simulator version 2 (ns-2) to determine if intentional the information contained in the RTCP SR packets. These prioritization of RTCP over RTP retransmission packets are sent periodically, and the components of a multimedia can guarantee the average reduced minimum RTCP SR session cannot be synchronized until sufficient RTCP SR interval according to IETF RFC 3550, sufficient for packets have been received for each RTP flow to allow the inter-media lip-synchronization of the RTP multicast receiver to establish mappings between the media clock sessions regardless of network congestion without used for each RTP flow, and the common (Network Time disruption of statistics measured by RTCP. This is the null Protocol (NTP) format) reference clock used to establish hypothesis (H0). Statistical calculations were carried out synchronization. RTP flows are identified by means of the using Analyse-it add-in software for Microsoft Excel. Manuscript received September 5, 2010. Manuscript revised September 20, 2010. IJCSNS International Journal of Computer Science and Network Security, VOL.10 No.9, September 2010 43 Section II describes the retransmission method for rapid synchronization of RTP multicast sessions. Section III introduces a simulation environment, a used simulator, simulation results and statistical analysis. Section IV concludes this paper. 2. RTP Retransmission Method The difference between the time an RTP receiver joins the multicast multimedia session and the time when visual lip movements of a speaker match the sound of the spoken words is referred to as lip-synchronization delay or simply synchronization delay. The synchronization delay may not be the same for different receivers. It usually varies depending on the join time, length of the RTCP SR interval, size of the synchronization information as well as the application and transport properties. The varying Fig. 1 RTP retransmission method with an intermediary network nature of the synchronization delay adversely affects the element. receivers that frequently switch among multicast sessions. In this section, a retransmission method for rapid 3. Model Analysis and Simulation Results synchronization of RTP multicast sessions that uses the fundamental tools offered by the existing RTP and RTCP The main objective of the following simulation study is to protocols [1] is described. In this method, either the provide recommendations concerning how to implement multicast source (or the distribution source) retains RTP an adequate RTP/RTCP packet classification scheme packets for a period after transmission, or an intermediary based on the DiffServ QoS techniques in order to avoid network element (RS) joins the multicast session and negative effects of network congestion on synchronization continuously caches RTP packets as they are sent in the of multicast RTP sessions. Accordingly, the average session and acts as a feedback target [5] for the session. reduced minimum RTCP SR interval according to IETF When an RTP receiver wishes to join the same multicast RFC 3550, sufficient for inter-media lip-synchronization session it sends a request to the feedback target for the without excessive delay regardless of network congestion, session and asks for the RTP retransmission session. The will be guaranteed. RS starts a new unicast RTP retransmission session and sends RTP retransmission packets to the RTP receiver 3.1 Simulation Setup and Protocols over that session. If there is spare bandwidth, the RS may burst RTP retransmission packets faster than their natural The following simulations are performed using Network rate. As soon as the receiver acquires the synchronization Simulator version 2 (ns-2) with adaptations concerning information, it can join the multicast session and start RTP/RTCP protocols [8]. processing the multicast data. A simplified network The default implementation of RTP/RTCP in ns-2 is very diagram showing this method through an intermediary poor and it is not working according to [1]. In order to network element is depicted in Fig. 1. achieve the expected timing rules, certain changes are The described method potentially reduces the applied in session-rtp.tcl as presented in Fig. 2. The synchronization delay [6]. A principle design goal in this minimum RTCP interval is set to 5 seconds, the fraction of solution is to use the existing tools in the RTP/RTCP the session bandwidth added for RTCP is fixed at 5%, the protocol family. This improves the versatility of the timing rules are updated according to [1] and the existing implementations, and promotes faster deployment randomization option is turned on. and better interoperability. To this effect, the unicast The simulations are based on common network topology retransmission support of RTP [7] and the capabilities of consisting of eight routers (A, B, C, D, E, F, G, H) with RTCP are recommended to handle the signaling needed to three user domains (D1, D2, D3) attached to them. There accomplish the acquisition. However, it is beyond the are also four servers (A/V streaming server, FTP server, scope of this paper. VoD server, RS) attached to routers E, F, G and H. The network topology is shown in Fig. 3. 44 IJCSNS International Journal of Computer Science and Network Security, VOL.10 No.9, September 2010 # set minimum interval to 5 seconds set min_rpt_time_ 5 # update fraction of the session bandwidth added # for RTCP to be fixed at 5% set inv_sender_bw_fraction_ [expr