RTSP flow between a server and client.

RTSP call-flow

A typical RTSP streaming session, where the RTP payload is streamed over UDP, uses a workflow described in the following client-to-server and server-to-client message exchanges:

OPTIONS:

• The client initiates the session with the server by sending an OPTIONS request. The server replies to this request with information about what it supports and what kind of requests it can receive from the client.

Client-to-Server: Request

OPTIONS rtsp://184.72.239.149/vod/mp4:sample.mp4 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)

 Server-to-Client: Response

RTSP/1.0 200 OK
Supported: play.basic, con.persistent
CSeq: 2
Server: Wowza Streaming Engine 4.1.0 build12602
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER
Cache-Control: no-cache

DESCRIBE:

• The client sends a DESCRIBE message and the server responds with an SDP file that the client can use to get more information about the content that will be sent by the server. The SDP file contains information about the video/audio codecs used, clip duration, trackIDs, profile level, and so on. In the following example, the audio track is trackID=1 and the video track is trackID=2.

Client-to-Server

DESCRIBE rtsp://184.72.239.149/vod/mp4:sample.mp4 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Accept: application/sdp

 Server-to-Client

RTSP/1.0 200 OK
Content-Base: rtsp://184.72.239.149/vod/mp4:sample.mp4/
Date: Tue, 23 Apr 2013 14:19:15 UTC
Content-Length: 576
Session: 408754851;timeout=60
Expires: Tue, 23 Apr 2013 14:19:15 UTC
CSeq: 3
Content-Type: application/sdp
Server: Wowza Streaming Engine 4.1.0 build12602
Cache-Control: no-cache
v=0
o=- 408754851 408754851 IN IP4 127.0.0.1
s=sample.mp4
c=IN IP4 0.0.0.0
t=0 0
a=sdplang:en
a=range:npt=0- 596.458
a=control:*
m=audio 0 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1190
a=control:trackID=1
m=video 0 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=42C01E;sprop-parameter-sets=Z0LAHtkDxWhAAAADAEAAAAwDxYuS,aMuMsg==
a=cliprect:0,0,160,240
a=framesize:97 240-160
a=framerate:24.0
a=control:trackID=2

SETUP:

• The client sends two SETUP requests to the server, one for the video track and one for the audio track. The track IDs are received during the previous DESCRIBE message response. During the SETUP message exchange, the clinet informs the server about which UDP ports it will use for the RTP and RTCP communication for both video and audio tracks. The server will respond with an acknowledgement of the client ports to be used for the RTP/RTCP communication and inform the client about the UDP server ports that will be used for this session.

In the following example, the client will use the following ports:

Audio

• The server will send RTP packets from UDP source port 7066 to the client UDP destination port 57780
• The server will send RTCP sender reports from UDP source port 7067 to the client UDP destination port 57781
• The client will send receiver reports from UDP source port 57781 to the server UDP destination port 7067

Video

• The server will send RTP packets from UDP source port 7064 to the client UDP destination port 57782
• The server will send RTCP sender reports from UDP source port 7065 to the client UDP destination port 57783
• The client will send receiver reports from UDP source port 57783 to the server UDP destination port 7065

Client-to-Server: SETUP request for audio track

SETUP rtsp://184.72.239.149/vod/mp4:sample.mp4/trackID=1 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Transport: RTP/AVP;unicast;client_port=57780-57781

 Server-to-Client

RTSP/1.0 200 OK
Date: Tue, 23 Apr 2013 14:19:15 UTC
Transport: RTP/AVP;unicast;client_port=57780-57781;source=184.72.239.149;server_port=7066-7067;ssrc=07938AE3
Session: 408754851;timeout=60
Expires: Tue, 23 Apr 2013 14:19:15 UTC
CSeq: 4
Server: Wowza Streaming Engine 4.1.0 build12602
Cache-Control: no-cache

 Client-to-Server: SETUP request for video track

SETUP rtsp://184.72.239.149/vod/mp4:sample.mp4/trackID=2 RTSP/1.0
CSeq: 5
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Transport: RTP/AVP;unicast;client_port=57782-57783
Session: 408754851

Server-to-Client

RTSP/1.0 200 OK
Date: Tue, 23 Apr 2013 14:19:15 UTC
Transport: RTP/AVP;unicast;client_port=57782-57783;source=184.72.239.149;server_port=7064-7065;ssrc=1206BD1C
Session: 408754851;timeout=60
Expires: Tue, 23 Apr 2013 14:19:15 UTC
CSeq: 5
Server: Wowza Streaming Engine 4.1.0 build12602
Cache-Control: no-cache

PLAY:

• After the communication ports are established, the client will send a PLAY request that informs the server that it's ready to receive the RTP data flow. After acknowledging the request, the server starts sending the RTP payload and the periodic sender reports. The server will also receive the receiver reports from the client. Since the RTP data stream is flowing from the server to the client, the receiver reports from the client are the only feedback received by the server about the status of the communication, and confirms that the client is receiving the RTP packets. 
• If no receiver reports come from the client, it means that there's no client to receive the RTP packets and the RTP stream can be stopped.
  
  During RTSP troubleshooting, you can use the Wireshark packet analyzer to follow the entire communication between the server and a particular client, having information about the ports used for the RTP/RTCP communication and filtering only the source and destination IP addresses.
  
  The RTP packets should arrive client-side in the correct sequence. You can analyze the server sender reports to see which packet was last sent by the server and compare with the received packets client-side.
  
  If a Wireshark trace is taken server-side, you can check to see if receiver reports are present in the trace and get information about the latest packets received by the client. You can also get additional information about the packet loss rate, latest packet sequence received by the client, and so on. 

Client-to-Server

PLAY rtsp://184.72.239.149/vod/mp4:sample.mp4/ RTSP/1.0
CSeq: 6
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Session: 408754851
Range: npt=0.000-

Server-to-Client

RTSP/1.0 200 OK
Range: npt=0.0-596.458
Session: 408754851;timeout=60
CSeq: 6
RTP-Info: url=rtsp://184.72.239.149/vod/mp4:sample.mp4/trackID=1;seq=1;rtptime=0,url=rtsp://184.72.239.149/vod/mp4:sample.mp4/trackID=2;seq=1;rtptime=0
Server: Wowza Streaming Engine 4.1.0 build12602
Cache-Control: no-cache

TEARDOWN:

• When the user presses the Stop button, or closes the player, a TEARDOWN request is sent to the server to inform it that playback has stopped. The server will then stop sending RTP data to the client and stop the streaming session. 

Client-to-Server

TEARDOWN rtsp://184.72.239.149/vod/mp4:sample.mp4/ RTSP/1.0
CSeq: 7
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Session: 408754851