1 / 20

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

CSc 461/561 Multimedia Systems Part C: 1. RTP/RTCP. Summary. Why RTP? Components of RTP 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

carrington
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Summary • Why RTP? • Components of RTP • RTP Applications • Mixer & Translator • RTP Data Transfer Protocol • RTP Control Protocol- RTCP • SSRC Identifier Allocation

  3. 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!

  4. 2. Components of RTP • RTP Data Transfer Protocol: It carries real-time data. • RTP Control Protocol (RTCP): It monitors the quality of service and conveys information about the participants.

  5. 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.

  6. 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.

  7. 3. RTP Applications (3) • Audio and Video Conference • Audio and video media are 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.

  8. 4. RTP Mixers and Translators (1) • Why Mixers and Translators? • Mixers

  9. 4. RTP Mixers and Translators (2) • Translator

  10. 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

  11. 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@8KHz, 20ms samples/packet • timestamp increment per packet: 160 • 90KHz used for video • a video frame may be encapsulated in a few packets • gap in timestamp: silence

  12. 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: uPCM 64Kbpz; PT=3: GSM 13Kbps • timestamp: e.g., sampling rate, 8KHz PCM • packet size: e.g., about 20ms samples in PCM • packets independent as much as possible: ALF • other issues: e.g., mixed audio channels

  13. 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)

  14. 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

  15. 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

  16. 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

  17. 6. RTCP (5): Jitter and delay estimation • One-way jitter • V = (r2-r1)-(s2-s1) = (r2-s2) - (r1-s1) • EWMA: J = J + (V-J)/16 • Round-trip delay • R = (r2-s1)-(s2-r1) • (s2-r1): DLSR • s1: LSR s1 s2 r1 r2 s1 r1 s2 r2

  18. 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

  19. 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

  20. 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.

More Related