CSc 461561 Multimedia Systems Part C 1 RTPRTCP

CSc 461/561 Multimedia Systems Part C: 1. RTP/RTCP CSc 461/561

Summary (1) (2) (3) (4) (5) (6) (7) CSc 461/561 Why RTP? Components of RTP Applications Mixer & Translator RTP Data Transfer Protocol RTP Control Protocol- RTCP SSRC Identifier Allocation

1. Why RTP? • Why not TCP? – TCP offers reliable, in-sequence data transfer – TCP embeds flow/error/congestion control • Why not UDP? – UDP offers datagram-like service • RTP: transport protocol for multimedia traffic – application level framing; integrated layer processing – usually RTP/UDP/IP, or RTP/IP – RTP does NOT guarantee real-time itself! CSc 461/561

2. Components of RTP • RTP Data Transfer Protocol: It carries realtime data. • RTP Control Protocol (RTCP): It monitors the quality of service and conveys information about the participants. CSc 461/561

3. RTP Applications (1) • Simple Multicast Audio Conference – The audio conferencing application used by each conference participant sends audio data in small chunks of, say, 20 ms duration. – Each chunk of audio data is preceded by an RTP header; RTP header and data are in turn contained in a UDP packet. – The RTP header indicates what type of audio encoding (such as PCM, ADPCM or LPC) is contained in each packet. CSc 461/561

3. RTP Applications (2) – RTP header contains timing information and a sequence number that allow the receivers to reconstruct the timing produced by the source. – The sequence number can also be used by the receiver to estimate how many packets are being lost. – the audio application in the conference periodically multicasts a reception report plus the name of its user on the RTCP port. The reception report indicates how well the current speaker is being received. – A site sends the RTCP BYE packet when it leaves the conference. CSc 461/561

3. RTP Applications (3) • Audio and Video Conference – Audio and video media are transmitted as separate RTP session and RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. – There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated. – Despite the separation, synchronized playback of a source's audio and video can be achieved using timing information carried in the RTP packets for both sessions. CSc 461/561

4. RTP Mixers and Translators (1) • Why Mixers and Translators? • Mixers CSc 461/561

4. RTP Mixers and Translators (2) • Translator CSc 461/561

5. RTP Data Transfer Protocol (1): • The Structure of a RTP packet: • Version=2; Padding; extension; Marker • Synchronization source: e. g. , source, mixer • Contributing source: e. g. , individual speaker CSc 461/561

5. RTP Data Transfer Protocol (2): Synchronization • Synchronization Source (SSRC) • Sequence number (packet count) – gap in sequence #: packet loss • Timestamp (sample count) – e. g. , audio@8 KHz, 20 ms samples/packet • timestamp increment per packet: 160 – 90 KHz used for video • a video frame may be encapsulated in a few packets – gap in timestamp: silence CSc 461/561

5. RTP Data Transfer Protocol (3): RTP profiles • Media specific (e. g. , audio) – Marker: e. g. , the start of a talk spurt – Payload Type: e. g. , specific audio codec • PT=0: u. PCM 64 Kbpz; PT=3: GSM 13 Kbps – timestamp: e. g. , sampling rate, 8 KHz PCM – packet size: e. g. , about 20 ms samples in PCM • packets independent as much as possible: ALF – other issues: e. g. , mixed audio channels CSc 461/561

6. RTCP (1) • RTCP: RTP’s control companion – purpose: feedback control information • for flow/error/congestion/quality control – two consecutive UDP ports for RTP and RTCP – sender report: offer sending/reception statistics – receiver report: offer reception statistics • RTCP common header: Version (2 -bit); Padding (1); RR count (5); Type (8); Length (16) CSc 461/561

6. RTCP (2): Types of RTCP Packets • Types of RTCP packets: – 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 CSc 461/561

6. RTCP (3) : SR • Sender report (SR) – SSRC of sender (32 -bit): source media – NTP timestamp (64 -bit): wall clock – RTP timestamp (32 -bit): sample count • for synchronization among media streams – packet count (32 -bit): total # of packets sent – byte count (32 -bit): total amount of data sent • receiver: rate/loss estimation CSc 461/561

6. RTCP (4): RR • Receiver report (RR) – SSRC of source (32 -bit): source media – fraction lost (8 -bit): binary fraction, short-term – cumulative lost (24 -bit): # of packets, long-term – extended highest sequence # received (32 -bit) – inter-arrival jitter (32 -bit) – LSR timestamp (32 -bit): last received SR – delay since last SR (32 -bit): in NTP ticks CSc 461/561

6. RTCP (5): Jitter and delay estimation • One-way jitter – V = (r 2 -r 1)-(s 2 -s 1) = (r 2 -s 2) - (r 1 -s 1) – EWMA: J = J + (V-J)/16 s 1 s 2 r 2 • Round-trip delay – R = (r 2 -s 1)-(s 2 -r 1) – (s 2 -r 1): DLSR – s 1: LSR s 1 r 2 CSc 461/561 r 1 s 2

6. RTCP packets (6): more • Source description (SDES) – CNAME (canonical name, user@host), NAME (real name), EMAIL, PHONE, LOC (location), TOOL, NOTE, PRIV (private extension) • Explicit leave (BYE) – optional string: reason for leaving • Application-specific (APP) – application-specific extensions CSc 461/561

6. RTCP (7): bandwidth scaling • Goal: limited control overhead – RTCP counts for 5% session bandwidth • sender RTCP counts for 25% • receiver RTCP counts for 75% • Approach: adjust RTCP interval adaptively – scale RTCP inter-packet time according to • amount of data traffic • # of senders and receivers CSc 461/561

7. SSRC Identifier Allocation • The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32 -bit number that is required to be globally unique within an RTP session. • All RTP implementations must be prepared to detect collisions and take the appropriate actions to resolve them. • If a source discovers at any time that another source is using the same SSRC identifier as its own, it must send an RTCP BYE packet for the old identifier and choose another random one. • If a receiver discovers that two other sources are colliding, it may keep the packets from one and discard the packets from the other. CSc 461/561