1. RTP/RTCP – Real Time Transport
Protocol/ Real Time Control Protocol

2. Motivation
• TCP/IP
– Not suitable for real-time
• Retransmissions can lead to high delay and cause delay jitter
– Does not support multicast
– Congestion control mechanism (slow start) not suitable for AV
media
• UDP/IP
– No defined technique for synchronizing
– Streams from different servers may collide
– A feedback channel must be defined for quality control

3. RTP/RTCP
• A session consists of an RTP/RTCP pair of
channels
• Usually works over UDP/IP
• End-to-end protocol

4. RTP/RTCP
• RTP Features
– Multicasting
– Payload type identification
– Time shaping
– Sequencing
– Delivery monitoring

5. RTP/RTCP
• RTP Issues
– No QoS guarantees
– No guarantee of packet delivery
• RTP Timestamp (TS) and Sequence Number (SN)
– TS used to order packets in correct timing order
– SN to detect packet loss
– For a video frame that spans multiple packets – TS is
same but SN is different

6. RTP/RTCP
• RTCP
– Synchronize across different media streams
– Provide feedback on the quality of data using
lost packet counts
– Identify and keep track of participants
– Retransmission requests

7. RTP/RTCP
Media Application
RTCP
RTP
UDP
IP

8. RTP/RTCP(RFC 1889)
• Real-time transport protocol (RTP) is the de
facto standard media transport protocol in
the Internet
– Media transport: audio, vedio, etc. How is it
different from data transport?
– RTP: media transport.
– RTCP: end-to-end monitoring and data delivery
and QoS.

9. • RTP and RTCP are commonly built on top
on UDP.
• RTP provides some functionality for media
transport. RTP does not:
– Guarantee QoS
– address resource reservation
– Perform signaling (negotiate the media format)
• RTP/RTCP are usually implemented within
applications --- not as clean cut as TCP.

10. • RTP use scenarios
– A working group obtains an IP multicast address and a pair of
ports through some allocation mechanism.
– One port for audio, one for control
– The address and the ports are distributed to intended participants.
– The participants send audio data in small chucks, 20ms duration.
Each chuck of audio data is preceded with a RTP header, which
indicates the type of encoding.
– The Internet may occasionally lose or reorder packets or delay the
packet in variable amount time. To help the receiver reconstruct
the timing produced by the sender, RTP header also include timing
and sequence number information.
– Since the member may join and leave a group dynamically, it is
useful to know who is participating and the audio quality at a given
time. This task is done through RTCP.

11. • RTP packet format:
V=2 p x cc m PT sequence number
timestamp
synchronization source identifier (SSRC)
contributing source identifiers (CSRC)
p: Padding (1 bit), data content is less than the size of the packet.
x: extension(1 bit), fixed header is followed by 1 variable sized header
extension.
cc: CSRC count: number of CSRC identifiers.
m: marker, identify significant events.
PT: payload type (PCM, ADPCM, etc)

12. • RTP packet format:
V=2 p x cc m PT sequence number
timestamp
synchronization source identifier (SSRC)
contributing source identifiers (CSRC)
Timestamp: sampling instant of the first octet in the RTP data packet
SSRC: sender
CSRC list: contributing sources for the payload contained in the
packet. (needed for mixers)

13. • RTCP
– A companion control protocol to RTP.
– RTCP is not a signaling protocol
– RTCP is used to collect end-to-end information
about the quality of the session to each
participant.
– RTCP packet types:
• SR: sender report
• RR: receiver report
• SDES: Source DEScription
• BYE: Hangs up from a session
• APP: Application-Sprcific packet

14. • SR: sender report
– Carry statistics from the active senders.
V=2 p rc PT=SR=200 length
SSRC of sender
NTP timestamp, MSW
NTP timestamp, LSW
RTP timestamp
Sender’s packet count
Sender’s octet count
SSRC_1 (SSRC of first source), block 1
Sender’s packet count
fraction lost cumulative number of packets lost
extended highest sequence number received
interarrival jitter
last SR (LSR)
delay since last SR (DLSR)
SSRC_2 (SSRC of second source), begin block 2
….
profile-specific extensions

15. • RR: receiver report
– Statistics from active receivers
V=2 p rc PR=RR=201 length
SSRC of sender
SSRC of first source, begin block 1
Fraction lost (FL) cumlative number of packets lost
extended highest sequence number received
interarrival jitter
last SR (LSR)
delay since last SR (DLSR)
SSRC of second source, begin block 2
…….
profile-specific extensions

16. • SDES: Source Description packet
– Allow the binding of SSRC value with an
actual identification of the user.
– End points need to send an SDES packet at the
beginning of the session
• BYE: ends a user’s participation in a call.
• APP: Application-specific RTP packet.

17. • Some issues in RTP and RTCP:
– How often should RTCP reports to exchanges.
• Must be able to provide real time and with enough
resolution for QoS interpretation.
• Fix bandwidth
• Proportion to channel bandwidth
– How to use the RTCP reports?
• Reroute
– End-to-end QoS information may not be sufficient.
• Application adaptation.