RTSP interaction process

Simple RTSP interaction process:
C Indicates the RTSP client, and s indicates the RTSP server.
1. C-> S: Options request // ask s which methods are available
1. S-> C: Options response // s the response information includes all available methods provided

2. C-> S: DESCRIBE request // obtain the media initialization description provided by S.
2. S-> C: Describe response // s response media initialization description, mainly SDP
 
3. C-> S: SETUP Request // sets the session attributes and transmission mode to remind s to establish a session
3. S-> C: setup response // s creates a session and returns the session identifier and session-related information.
 
4. C-> S: Play request // C request playback
4. S-> C: Play response // S: the requested information is returned.
 
S-> C: Send streaming media data
5. C-> S: teardown request // C request to close the session
5. S-> C: teardown response // s should request

 

Reprinted an article to provide detailed answers to the RTSP creation process:

Http://hi.baidu.com/yg_110/item/6ad422ebd6ae72b72e140b23

 

The content is as follows:

 

RTSP comprehension and Examples

RTSP is a Real Time Streaming Protocol. According to my understanding, it is a streaming media control protocol, the encoding types and addresses of both parties, and the control over stream media (play, pause, record ). do not mix with the RTCP protocol. RTCP is used to control RTP.

The following describes several methods of RTSP to describe the protocol.
1: Options
The client usually sends the server to ask about the methods supported by the server. Of course, it can also be used as a heartbeat in the application because it is State-independent. For example:
C-& gt; s: Options * RTSP/1.0
CSeq: 1
Require: Implicit-play
Proxy-require: gzipped-messages

S-> C: RTSP/1.0 200 OK
CSeq: 1
Public: Describe, setup, teardown, play, pause
The 200ok message sent by the server indicates that the server supports describe, setup, teardown, play, and pause.
Here we can see that the request and response CSeq are the same, corresponding to all the subsequent messages, the request and response CSeq are the same.

2: Describe
Literally, it is the description. What is the description? Of course, it is the information of streaming media. The returned response contains SDP. For example:
Describe rtsp: // server. Address: Port/object. sdp rtsp/1.0 \ r \ n
CSeq: 1 \ r \ n
\ R \ n

-----------------------------------------------------------------------
RTSP/1.0 200 OK \ n
Server: qtss (IFI)/v88 \ n
CSeq: 1 \ n
Content-Type: Application/SDP \ n
Content-base: rtsp: // bildeus. IfI. uio. No: 8000/12. SDP/\ n
Content-Length: 785 \ n
\ N
N = 2236805513 2236805513 932036356 224.2.127.254 9875 trusted \ n
V = 0 \ n
O = Yozo 3138827440 3138828177 in ip4 aohakobe.ipc.chiba-u.ac.jp \ n
S = places all over the world \ n
I = low bandwidth video (10kb/s) with views from all over the world. audio is primarily for feedback for the senders of video. (looks like there's some problem for the Session announcement from Sweden distributes to the whole mbone, I'm repeating the announcement
From Japan. -- Yozo.) \ n
E = Yozo Toda at IPC, Chiba University, and Japan <
P = + 81-43-290-3539 \ n
C = in ip4 224.2.213.113/127 \ n
T = 3138827400 3141246600 \ n
A = tool: SDR v2.6.1 \ n
A = type: Test \ n
M = audio 20154 RTP/AVP 0 \ n
C = in ip4 224.2.213.113/127 \ n
A = ptime: 40 \ n
A = control: trackID = 1 \ n
M = video 51482 RTP/AVP 31 \ n
C = in ip4 224.2.172.238/127 \ n
A = control: trackID = 2 \ n

In the response, we focus on the SDP field. in SDP, we can see that streaming media contains two resources (m rows): audio and video. Row A is the attribute description of M (media. in line m, the number in the middle is the port recommended by the server client. If the server does not want to do so, you can set the port to 0. in SDP, there is also the = control field. In rfc2326, its interpretation is as follows:

The "A = control:" attribute is used to convey the control URL. This
Attribute is used both for the session and media descriptions. If
Used for individual media, it indicates the URL to be used
Controlling that participates media stream. If found at the session
Level, the attribute indicates the URL for aggregate control.

Example:
A = control: rtsp: // example.com/foo

This attribute may contain in either relative and absolute URLs,
Following the rules and conventions set out in RFC 1808 [25].
Implementations shoshould look for a base URL in the following order:

1. the RTSP content-base field
2. the RTSP content-location field
3. the RTSP request URL

If this attribute contains only an asterisk (*), then the URL is
Treated as if it were an empty embedded URL, and thus inherits
Entire base URL.

Here we describe aggregate control. when the server supports set control, for example, for an audio video stream, it does not need to create two sessions. If not, it is OK to combine them into one session. If not, two sessions must be created separately. in my understanding, A = control indicates the ID of the media. For example, track1 indicates the video and track2 indicates the audio. this can be seen in subsequent setup.
With these parameters, we can know the encoding format of streaming media.

3: Setup
Create a session. If set control is supported, the session field will be included in setup. The following message is an example that supports set operation.

Setup rtsp: // server. Address: Port/object. SDP/trackID = 1 RTSP/1.0 \ r \ n
CSeq: 2 \ r \ n
Transport: RTP/AVP; unicast; client_port = 9000-9001 \ r \ n
\ R \ n
-------------------------------------------------------------------------

RTSP/1.0 200 OK \ n
Server: qtss (IFI)/v88 \ n
CSeq: 2 \ n
Session: 1234567890; timeout = 60
Transport: RTP/AVP; Source = 129.240.65.208; server_port = 9000-9001; client_port = 9000-9001 \ n
\ N
--------------------------------------------------------------------------
Setup rtsp: // server. Address: Port/object. SDP/trackID = 2 RTSP/1.0 \ r \ n
CSeq: 3 \ r \ n
Session: 1234567890 \ r \ n
Transport: RTP/AVP; unicast; client_port = 9000-9001 \ r \ n
\ R \ n

In the example, we can see that a streaming media session is established through the setup response. the subsequent setup must contain the session field. Through the above message, we can see that the client has sent two Setup messages, representing track1 of video and track2. if the server does not support set operations, the session field in setup is invalid. in the message, we see the transport field, which indicates the port for the client to receive streaming media and the encoding format. in this example, RTP is transmitted using UDP. If RTP is transmitted using TCP, the transport field may be: Transport:
RTP/AVP/tcp; unicast; interleaved = 0-1. Here, interleaved is explained. Because TCP transmission is used, the RTP and RTCP packets transmitted are on the same link, yes, so interleaved, 0 indicates the RTP channel, and 1 indicates the RTCP channel. it is embodied in RTP on the package, and an interleaved frame is encapsulated on the rtcp package. The format is as follows:
Magic: 0x24
Channel: 0x01 (indicating RTCP)
Length: 84

4: Play
Play is the instruction for playing streaming media:
Play rtsp: // server. Address: Port/object. sdp rtsp/1.0 \ r \ n
CSeq: 4 \ r \ n
Session: 1234567890 \ r \ n
\ R \ n
The range field is usually included in play, but is not required. This field indicates the range of streaming media.

5: teardown
The teardown command ends streaming media.
Whether a session must be included in teardown is discussed. if a session corresponds to a link, it does not need to correspond to the session. However, in our applications, teardown basically carries teardown. speaking of this, let's talk about several RTSP connection types:
* Persistent transport connections used for several request-response transactions
* One connection per request/response transaction;
* Connectionless mode.

Here is an introduction to several basic messages. Let's talk about the RTSP state machine. in fact, the RTSP state machine is very simple, not as complicated as the SIP protocol. it corresponds to many messages and is state-independent. here we will only introduce the server-related state machines:
State message received Ed next state
Init setup ready
Teardown init
Ready play playing
Setup ready
Teardown init
Record recording
Playing play playing
Pause ready
Teardown init
Setup playing
Recording record recording
Pause ready
Teardown init
Setup recording
Through the above table, we can know that messages must be sent in an orderly manner. For example, if no setup is sent, play cannot be sent. there are two consecutive pause operations that are definitely incorrect. in this state machine, there is no end. We usually end the next session after teardown, or even close the link. however, I have returned to the init state in the middle. I am confused about this. Here I want to talk about the topic we discussed above: whether teardown should bring session. In this state machine, teardown can be received at any stage, such as the init stage, which has no session.

PS: This is a summary written after the end of the last Dr Project (Global eye. Now it seems that some do not even understand themselves.