The relationship between the multimedia protocols is documented here. The protocols are demonstrated using Real Networks software described further HERE. Some background information is provided on the individual protocols before describing their relationship.

• Protocols in themselves
• Relationship between protocols

This is an overview of the individual protocols. Detailed information is provided by the request for comment (RFC) documents. 
 
 

Name	Request for Comment (RFC)	Type	TCP/UDP
RTSP (Real Time Streaming Protocol)	rfc 2326	Text based like HTTP	TCP
RTCP (Real Time Control Protocol)	rfc 1889	Byte stream	UDP
RTP (Real Time Protocol)	rfc 1889	Byte stream	UDP
SDP (Session Description Protocol)	rfc 2327	Text based	used in RTSP

Streaming multimedia is a transaction between the server and client. Specifically, the client an individual user application that views the media, such as Real Player. The server application provides all the client applications with the multimedia content. The multimedia protocols define the transaction that is used to establish a connection and transmit the media from the server and client. The big picture is that RTSP is used to establish the client/server connection. RTCP and RTP are used in parallel to transmit the actual media data. Through RTSP the server will provide the client with information to synchronize the RTSP and RTCP/RTP protocols.

RTSP is the highest level protocol. It is the initial connect for the client to request a selected media file from the server. The server will return information necessary for the client to render the media. A typical RTSP transaction can be viewed in detail HERE. Only transactions of interest to RTCP and RTP are explained further. The "describe" reply sent by the server contains key information. In particular, the replay contains the SDP description (session description protocol); for instance, the following SDP that the described file is a 22KHz sampled mono recorded WAV file (rtpmap:101 L8/22050/1). In addition, there is information that will be used in the later protocols. 
 
 

Server response to DESCRIBE

RTSP/1.0 200 OK  CSeq: 2  Date: Sun, 06 May 2001 21:48:44 GMT  X-TSPort: 7802  Last-Modified: Thu, 24 Jul 1997 23:05:42 GMT  Content-base: rtsp://hires16-cs:554/rtsp.wav/  Content-type: application/sdp  Content-length: 514  v=0  o=- 989194305 989194305 IN IP4 152.2.142.144  s=<No title>  i=<No author> <No copyright>  c=IN IP4 0.0.0.0  t=0 0  a=SdpplinVersion:1610642970  a=Flags:integer;1  a=StreamCount:integer;1  a=range:npt=0-7.263000  m=audio 0 RTP/AVP 101  b=AS:176  a=control:streamid=0  a=range:npt=0-7.263000  a=length:npt=7.263000  a=rtpmap:101 L8/22050/1  a=mimetype:string;"audio/L8"  a=StartTime:integer;0  a=AvgBitRate:integer;176400  a=AvgPacketSize:integer;441 a=Preroll:integer;2000  a=MaxPacketSize:integer;441 a=MaxBitRate:integer;176400

The "setup" reply from the client establishes the protocol that should be used to transmit the media data. Real Networks uses their proprietary RDP protocol to transmit their file types. The open standard protocol RTP is also an option. In addition, to the protocol is the port number the client has made available to receive the media data.
 
 

Client SETUP request

SETUP rtsp://hires16-cs:554/rtsp.wav/streamid=0 RTSP/1.0  CSeq: 3  Transport: rtp/avp;unicast;client_port=6970-6971

 

Server response to SETUP

RTSP/1.0 200 OK  CSeq: 3  Date: Sun, 06 May 2001 21:48:44 GMT  Session: 9978-3  Transport: rtp/avp;unicast;client_port=6970-6971;server_port=10620-10621

 

The server replies with the selected protocol and acknowledgement of the client's port numbers. In addition, the server provides port numbers for feedback sent by the client.

The last part of the initialization is for the client to send a "play" request, specifying the requested start and stop time. In response the server will send an OK and the key information that will allow the client to synchronize itself with the following RTCP and RTP transaction. The key information is the RTP timestamp of the start of the RTCP/RTP transaction. The client requires the start time to verify that the initial packets have not been lost, in which case it would attempt to recover them. 
 
 

Client PLAY request

PLAY rtsp://hires16-cs:554/rtsp.wav RTSP/1.0  CSeq: 4  Session: 9978-3  Range: npt=0-7.263000

 

Server PLAY response

RTSP/1.0 200 OK  CSeq: 4  Date: Sun, 06 May 2001 21:48:56 GMT  RTP-Info: url=rtsp://hires16-cs:554/rtsp.wav/streamid=0;seq=0;rtptime=0

One note should be given to the RTSP transaction before continuing. The RTSP connection will be connect for the entire streaming of the media. The server will oblige to the client's request to play a different segment, pause and stop. These will also effect the RTCP/RTP transaction. 

Finally to the actual transmission of the media. RTCP and RTP are intended to work together. RTCP is the control protocol for RTP. The RTCP information is sent to the odd numbered port specified in the client's RTSP "setup" request. The first two standard RTCP packets are the "source description" and "sender report", which identifies the source and reports some initial state like the RTP timestamp (same as sent in "start" of RTSP server reply). The source's identifier known as SSRC will be a random number. The RTCP transactions between the client and server are used to periodically report the progress of the RTP transaction. The client is able to report delay and lost packets, which the server will use to change parameters to improve matters. RTP and RTCP are well documented in the class notes (links: class homepage, RTP,RTCP).

The RTP protocol is the actual packetization of the media data. Every data type has its format that the client will interpret and reconstruct for play back.