1. RTP/RTCP multimedia protocols for the Internet Center for Software Development CSD, BITS - Pilani CopyRight: IPv6@BITS

2. 1. The RTP Protocol CopyRight: IPv6@BITS 1.1 Overview1.1 Overview 1.2 RTP generalities1.2 RTP generalities 1.3 RTP Use Scenarios1.3 RTP Use Scenarios 1.4 RTP Header Format1.4 RTP Header Format 1.5 Mixers and Translators1.5 Mixers and Translators 1.6 RTP: Potential Problems1.6 RTP: Potential Problems

3. 1.1 RTP Overview Real-Time Protocol (RTP)Real-Time Protocol (RTP) –a protocol for real-time applications like video, etc. –does not define any QoS mechanism for real-time delivery! Applications typically run RTP on top of UDP to make use of its multiplexing and checksum servicesApplications typically run RTP on top of UDP to make use of its multiplexing and checksum services CopyRight: IPv6@BITS

4. 1.2 RTP generalities carry data that has real-time properties –Simple Multicast Audio Conference –Audio and Video Conference Scalable:unicast, multicast, from 2 to Scalable:unicast, multicast, from 2 to  TimingTiming –intra-media synchronization: remove jitter with playout buffers –inter-media synchronization: lip - synchro between audio-video CopyRight: IPv6@BITS

5. 1.3 RTP Use Scenarios Simple Multicast Audio Conference – –Each participant uses two ports. One for audio data and the other for control (RTCP) packets – –Each participant sends audio data in small chunks of say 20 mS duration – –A RTP header is added which contains the timing field that ensures that the chunks of data are continuously played for every 20mS CopyRight: IPv6@BITS

6. 1.3 RTP Use Scenarios Audio and Video Conference –Both audio and video are transmitted as two separate RTP sessions. – –separate RTP and RTCP packets are transmitted for each medium using two UDP port pairs and multicast addresses. – –no direct coupling at the RTP level between the audio and video sessions CopyRight: IPv6@BITS

7. 1.4 RTP Header Format Sequence number fieldSequence number field –incremented for each RTP packet Synchronization SouRCe (SSRC) fieldSynchronization SouRCe (SSRC) field –uniquely identifies the source in the session –chosen randomly Contributing SouRCe (CSRC) and CC fieldsContributing SouRCe (CSRC) and CC fields –used by a mixer to identify the contributing sources –size of the list given by the CSRC Count (CC) field CopyRight: IPv6@BITS

8. 1.5 Mixers MixersMixers –Helps in resynchronizing the incoming audio packets and forward it to the low speed link. –Also combines several flows in a single new one –appears as a new source CopyRight: IPv6@BITS

9. 1.5 Mixers MixersMixers –a mixer may change the data format (coding) and combine the streams in any manner –example: video mixer end system 1 end system 2 mixer end system 3 from ES1: SSRC=6 from ES2: SSRC=23 from M: SSRC=52 CSRC list={6, 23} CopyRight: IPv6@BITS

10. 1.5 Translators Two translators are installed, on either side of the firewall, with the outside one tunneling all multicast packets received through a secure connection to the translator inside the firewall. e.g. protocol translation, firewalle.g. protocol translation, firewall CopyRight: IPv6@BITS

11. 1.5 Translators data may pass through the translator intact or may be encoded differentlydata may pass through the translator intact or may be encoded differently the identity of individual flows remains intact!the identity of individual flows remains intact! example: going through a firewallexample: going through a firewall end system 1 end system 2 transl.1 from ES1: SSRC=6 from ES2: SSRC=23 transl.2 from ES2: SSRC=23 from ES1: SSRC=6 authorized tunnel firewall from ES2: SSRC=23 from ES1: SSRC=6 CopyRight: IPv6@BITS

12. 1.6 RTP: Potential Problems Potential problems over standard Internet packets may bePotential problems over standard Internet packets may be –Lost –Reordered –fragmented by IP if size > std. Max size CopyRight: IPv6@BITS

13. 2. The RTCP Protocol 2.1 RTCP generalities2.1 RTCP generalities 2.2 Distribution of RTCP Packets2.2 Distribution of RTCP Packets 2.3 Scalability2.3 Scalability 2.4 RTCP Packet Format2.4 RTCP Packet Format CopyRight: IPv6@BITS

14. 2.1 RTCP generalities periodic transmission of control packetsperiodic transmission of control packets Functions:Functions: –feedback on the quality of data distribution –Permits everybody evaluate the number of participants –persistant transport-level canonical name for a source, CNAME usually: user@hostusually: user@host will not change, even if SSRC does!will not change, even if SSRC does! provides binding across multiple media tools for a single userprovides binding across multiple media tools for a single user CopyRight: IPv6@BITS

15. 2.2 Distribution of RTCP Packets DistributionDistribution –use same distribution mechanisms as data packets –Underlying protocol should provide multiplexing for data and control packets (in this case UDP) –multiple RTCP packets can be concatenated by translators/mixers  compound RTCP packet CopyRight: IPv6@BITS

16. 2.3 Scalability scalability with session sizescalability with session size –RTCP traffic should not exceed 5% of total session bandwidth requires an evaluation of number of participants RTCP tx interval = f(number of participants) –let new receivers quickly know CNAME of sources! CopyRight: IPv6@BITS

17. 2.4 RTCP Packet Format SR: Sender report, for transmission and reception statistics from participants that are active senders RR: Receiver report, for reception statistics from participants that are not active senders SDES: Source description items, including CNAME BYE: Indicates end of participation APP: Application-specific functions CopyRight: IPv6@BITS

18. Bibliography 1.Request for Comments: 3550 H. Schulzrinne, Columbia University; S. Casner Track Packet Designer. FrederickBlue Coat Systems Inc. Jacobson, Packet Design, July 2003 2.Request for Comments: 1889 CopyRight: IPv6@BITS

19. Thanx