What is the protocol?
Received data, after packaging by a fixed send to others, others by decapsulation fixed manner, necessary data can be obtained. Here fixed way involved packing and unpacking is a kind of agreement.
Agreement is rule-bound, so you can understand, in the constant practice of the agreement will be based on existing requirements or to demand, continuous iterative upgrade. No matter who, as long as the protocol, you can add support environment of the agreement.
RTSP
Real time streaming protocol (Real Time Streaming Protocol, RTSP) is a network application protocol, designed for use with entertainment and communication systems to control the streaming media server. This protocol is used to create and control the media session between terminals. The client media server publishing VCR commands such as play, record and pause, in order to control the real-time media stream from the server to the client (video on demand) or from the client to the server (voice recording) is.
Method definition
Description: direction (C S client server) object (P S represents a media stream)
| method | direction | Objects | Claim |
|---|---|---|---|
| OPTIONS | C->S, S->C | P,S | Required (S-> C: Optional) |
| DESCRIBE | C->S | P,S | recommend |
| ANNOUNCE | C->S, S->C | P,S | Optional |
| GET_PARAMETER | C->S, S->C | P,S | Optional |
| PAUSE | C->S | P,S | recommend |
| PLAY | C->S | P,S | required |
| RECORD | C->S | P,S | Optional |
| REDIRECT | S->C | P,S | Optional |
| SETUP | C->S | S | required |
| SET_PARAMETER | C->S, S->C | P,S | Optional |
| TEARDOWN | C->S | P,S | required |
1 OPTIONS
option request back to the server accepted the request typeC->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, PAUSE2 DESCRIBE
method described retrieve the presentation description or media object identified by the URL requested from the server. It may use the Accept header, which specifies the format description supported by the client. Description server in response to the requested resource. DESCRIBE reply - response constitutes the media initialization phase of RTSP.Media initialization is any RTSP-based system requirements, but the RTSP specification does not require to be done by the DESCRIBE method.
There are three ways RTSP client initialization information- By the RTSP DESCRIBE method;
- Through some other protocols (HTTP, email attachments, etc.);
- Via the command line or standard input (and therefore use the SDP file or other media to start initialization format as a helper application browser work).
For practical interoperability it is strongly recommended to achieve.
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg S->C: RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 376 v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 m=whiteboard 32416 UDP WB a=orient:portrait- 3 ANNOUNCE
release method has two purposes:- When sent from client to server, ANNOUNCE request a presentation description or media object identified by the URL is published to the server. When sent from the server to the client, ANNOUNCE updates the session description in real time.
- If the new media stream is added to the presentation of the components (for example, in real-time demo), you should send your entire presentation again described, not just added, so that you can remove components.
C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0 CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Session: 47112344 Content-Type: application/sdp Content-Length: 332 v=0 o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 S->C: RTSP/1.0 200 OK CSeq: 312 4 SETUP
setup request specifies how to transmit a single media stream. This must be done before sending PLAY request. Request contains the media stream URL and transport specifier. The specifier typically includes a local port for receiving RTP data (audio or video), and another for RTCP data (meta information). Server replies generally confirm the selected parameters, and fill in the missing part, such as port server of choice. Before sending the polymerization must play request, using the SETUP configure each media stream.C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port=4588-4589 S->C: RTSP/1.0 200 OK CSeq: 302 Date: 23 Jan 1997 15:35:06 GMT Session: 47112344 Transport: RTP/AVP;unicast; client_port=4588-4589;server_port=6256-62575 PLAY
play request will result in a player or all media streams. You may play request by transmitting a plurality of stacked playing request. URL can be polymerized URL (play all media streams), or a single media stream URL (play only that stream). You can specify a range. If you do not specify a range, the stream will start playing from the beginning, and play to the end, or if the stream pause, then resume playback pause point.C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0 CSeq: 833 Session: 12345678 Range: smpte=0:10:20-;time=19970123T153600Z S->C: RTSP/1.0 200 OK CSeq: 833 Date: 23 Jan 1997 15:35:06 GMT Range: smpte=0:10:22-;time=19970123T153600Z6 PAUSE
pause request to temporarily stop one or all media streams, so you can resume playback by request later. Request media streams comprising polymeric or URL. When the range parameter specifies the pause PAUSE request. When the range parameter is omitted occurs immediately suspended indefinitely.C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 834 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 834 Date: 23 Jan 1997 15:35:06 GMT7 TEARDOWN
stop publishing flow request to terminate the session. It stops all media streams, and release all related to the session data on the server.C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 892 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 8928 GET_PARAMETER
acquisition request parameter retrieval or presentation stream parameter values specified in the URI. The replies and replies left to implement.
`` `
-S-> C: RTSP GET_PARAMETER: //example.com/fizzle/foo the RTSP / 1.0
CSeq: 431
the Content-the Type: text / Parameters
the Session: 12345678
the Content-the Length: 15
packets_received
JitterC->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
packets_received: 10
jitter: 0.3838
```9 SET_PARAMETER
setting parameter request parameter values or the presentation stream designated by the URI is provided.
`` `
The C-> S: SETPARAMETER RTSP: //example.com/fizzle/foo the RTSP / 1.0
CSeq: 421
the Content-length: 20 is
the Content-type: text / Parameters
barparam: barstuffS->C: RTSP/1.0 451 Invalid Parameter
CSeq: 421
Content-length: 10
Content-type: text/parameters
barparam
```10 REDIRECT
redirects the request to notify the client that it must connect to another server location. It contains a mandatory header file location, indicates the URL of a client request should be issued. It may contain parameters Range, which indicates when the redirection effect. If the client wants to continue to send or receive media for this URI, the client must request a new session and the current session for TEARDOWN SETUP to the specified host.S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0 CSeq: 732 Location: rtsp://bigserver.com:8001 Range: clock=19960213T143205Z-11 RECORD
recording request to start recording a series of data according to the media presentation description. Timestamp reflects start and end time (UTC). If there is no given time frame, use the Start presentation provided in the description or the end time. If the session has started, please start recording immediately. URI in the request URI or other records to determine whether the server data storage. If the server does not use the URI request, the response should be 201, and the status of the request and containing the description refer to the entity and the Location header new resources.C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0 CSeq: 954 Session: 12345678 Conference: 128.16.64.19/3249237412 Embedded (Interleaved) Binary Data
Embedded (interlaced) binary data , some firewalls design and other circumstances may force the server to cross RTSP methods and stream data. Unless it is necessary, it should normally be staggered to avoid this, because it will make the client and server operating complicates and adds additional overhead. CROSS binary data can only be used by a TCP transmission RTSP. RTP data packet stream data such as the like of ASCII code symbol (24 hex) package, followed by a channel identifier byte, followed by the length of the binary data encapsulated in binary bytes, words to the network section order. Followed by the data stream, there is no CRLF, but comprising an upper layer protocol header. Each block contains only a $ upper layer protocol data unit, such as a RTP packet.C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0 CSeq: 2 Transport: RTP/AVP/TCP;interleaved=0-1 S->C: RTSP/1.0 200 OK CSeq: 2 Date: 05 Jun 1997 18:57:18 GMT Transport: RTP/AVP/TCP;interleaved=0-1 Session: 12345678 C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0 CSeq: 3 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 Session: 12345678 Date: 05 Jun 1997 18:59:15 GMT RTP-Info: url=rtsp://foo.com/bar.file; seq=232433;rtptime=972948234 S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\000{2 byte length}{"length" bytes data, w/RTP header} S->C: $\001{2 byte length}{"length" bytes RTCP packet}
Status code definition
1xx : Information - receive the request, continue processing
2xx : Success - The action was successfully received, understood, and accepted
3xx : Redirection - Further action must be taken to complete the request
4xx : Client Error - The request contains incorrect syntax or can not be completed
5xx : server error - The server failed to complete a valid request
| status code | definition |
|---|---|
| 100 | carry on |
| 200 | success |
| 201 | create |
| 250 | not enough storage space |
| 300 | multiple choices |
| 301 | Moved Permanently |
| 302 | Moved Temporarily |
| 303 | See other |
| 304 | Not modified |
| 305 | Use a proxy server |
| 400 | bad Request |
| 401 | unauthorized |
| 402 | Payment required |
| 403 | Prohibited |
| 404 | Not found |
| 405 | Method Not Allowed |
| 406 | unacceptable |
| 407 | Require proxy authentication |
| 408 | Request timed out |
| 410 | Out |
| 411 | Length requirements |
| 412 | Precondition failed |
| 413 | Entity Too Large request |
| 414 | Request URI too large |
| 415 | Unsupported media type |
| 451 | Parameter not understood |
| 452 | Conference Not Found |
| 453 | There is not enough bandwidth |
| 454 | Unable to find session |
| 455 | In this state does not work |
| 456 | Invalid header fields of resources |
| 457 | Invalid range |
| 458 | Parameter is read-only |
| 459 | Polymerization operation is not allowed |
| 460 | Polymerization operation only |
| 461 | Does not support transport |
| 462 | Target inaccessible |
| 500 | internal server error |
| 501 | 未实现 |
| 502 | 错误的网关 |
| 503 | 暂停服务 |
| 504 | 网关超时 |
| 505 | 不支持RTSP版本 |
| 551 | 选项不受支持 |
WEB：www.liveqing.com