RTSP 很详细的英文文档

最新推荐文章于 2024-04-12 11:17:02 发布
最新推荐文章于 2024-04-12 11:17:02 发布
阅读量5k 收藏 2
点赞数 2
分类专栏： RTSP RTP RTCP

RTSP Specification

Published 2012-10-01 | Advanced Article about Audio/Video. (Compatible with SDK 4.5)

RTSP Specification

The Real Time Streaming Protocol (RTSP) is a network protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used for establishing and controlling media sessions between end points. RTP/RTSP is a necessary protocol for multimedia content transfer. The RTP/RTSP protocol is quite advantageous in less than ideal network condition. The protocol provides benefits like as buffer fullness control mechanism, better control of packet pacing and fast pre-roll for providing quicker streaming transfer. The protocol is best suited for streaming transfer of live content.

Due to the unreliable nature of UDP packet delivery, the quality of the received stream will be adversely affected by packet loss. It is important to calculate the actual delay experienced in the channel. By calculating the correct value chances of receiving maximum number of packets for a particular frame would increase. As part of this implementation effort would be utilized for estimating overall play out delay experienced and making the play out operation smooth by introducing a jitter buffer implementation.

In case a client cannot establish UDP communication with the server due to some network configuration, RTSP server provide an alternative approach to still stream media over to the client using RTP over TCP mechanism. This makes it imperative that RTP/RTSP client stack shall have a method of trying with TCP channel in case it fails to connect with UDP channel.

All the above mentioned items have been summarized below to give the features level list.

RTSP process

Samsung provides the following RTSP specifications:

RTSP Supported Features

RTSP has 11 methods to control entire RTSP Session. The following categories are based on the current SamsungRTSP Stack.

Supported RTSP Methods

OPTIONS

Client May use the OPTIONS Method to inquire about methods supported by the Server. The Server SHOULD list the methods it supports using the public response header.

Example

OPTIONS rtsp://107.108.89.116:554/ESPN2.ts RTSP/1.0
CSeq: 0

RTSP/1.0 200 OK
CSeq: 0
Date: Mon, Sep 12 2011 11:11:26 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER,
        SET_PARAMETER

Note

Ref RFC 2326 section 10.1

Based on Optional Command list from Server Side, Samsung DTV client will send different Keep-alive (KA) message. If server supports GET_PARAMETER, Samsung DTV will send Keep-alive using GET_PARAMETER, if not it will send OPTION command for KA message. The KA message default interval is 25sec. Server can control this default timeout for KA messages in Setup Command as follows.

Example

SETUP rtsp://90.191.254.125:554/test_shutter.mpg/ RTSP/1.0
CSeq: 2
Transport: RAW/RAW/UDP;unicast;client_port=54184-54185;mode=play RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 2
Session: 1078930203263467403;timeout=60
Transport: RAW/RAW/UDP;unicast;destination=221.163.253.140;client_port=54184;source=90.191.254.125;server_port=59056

The new line is “rn”. The characters “rn” is used to terminate a request line or header line of RTSP command. ‘rn’ is not to be taken literally, but as return and newline characters (Similar to printf in the C programming language).

DESCRIBE

The DESCRIBE method retrieves the description of a presentation or media object identified by the request URL from a server.

Example

DESCRIBE rtsp://107.108.89.116:554/ESPN2.ts RTSP/1.0
CSeq: 1
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 1
Date: Mon, Sep 12 2011 11:15:05 GMT
Content-Base: rtsp://107.108.89.116/ESPN2.ts/
Content-Type: application/sdp
Content-Length: 396

v=0
o=- 1315826105025616 1 IN IP4 107.108.89.116
s=MPEG Transport Stream, streamed by the LIVE555 Media Server
i=ESPN2.ts
t=0 0
a=tool:LIVE555 Streaming Media v2011.05.25
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:MPEG Transport Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:ESPN2.ts
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
b=AS:5000
a=control:track1

Note

Ref RFC 2326 Section 10.2

Samsung DTV requests “accept: application/sdp” only. SETUP command MUST be followed by OPTION and DESCRIBE responses. If server sends multiple media types, Samsung DTV selects first media only. (Samsung will support optional parameter for select other media types.)

SETUP

The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. A client can issue a SETUP request for a stream that is already playing to change transport parameters, which a server MAY allow. If it does not allow this, it MUST respond with error “455 Method Not Valid In This State”.

Samsung RTSP feature support following transport mode.

RTP/AVP/UDP
Default Mode
RTP/AVP/TCP
If it failed with RTP/AVP/UDP Mode, it will try again with this mode.
RAW/RAW/UDP
if server supports UDP mode only ( m=video 0 UDP 33 )

Example

SETUP rtsp://107.108.89.116:554/ESPN2.ts/track1 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/UDP;unicast;client_port=51962-51963;mode=play
RTSP/1.0 200 OK
CSeq: 2
Date: Mon, Sep 12 2011 11:29:07 GMT
Transport:RTP/AVP;unicast;destination=107.108.89.116;source=107.108.89.116;client_port=51962-51963;server_port=6970-6971
Session: 00007689

Note

Ref RFC 2326 Section 10.4

To use TCP mode by default, URL should have “|TCP” parameter.

Example

rtsp://107.108.89.116:554/ESPN2.ts|TCP
PLAY

The PLAY method tells the server to start sending data via the mechanism specified in SETUP. A client MUST NOT issue a PLAY request until any outstanding SETUP requests have been acknowledged as successful.

Example

PLAY rtsp://107.108.89.116:554/ESPN2.ts RTSP/1.0
CSeq: 3
Session: 00007689
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 3
Date: Mon, Sep 12 2011 11:33:07 GMT
Range: npt=0.000-
Session: 00007689
RTP-Info: url=rtsp://107.108.89.116/ESPN2.ts/track1;seq=8539;rtptime=13709

Note

RFC 2326 Section 10.5

More Detailed Trick Play/Seek Play Guidance will be covered in next sections. Trick play: Supports “Scale” value. (Not support 0.X or -0.X [slow play]). It does not support “Speed” value. Seek: support by “Range” value. If Samsung DTV doesn’t send npt value, Server must use current npt value.

Example

PLAY rtsp://107.108.89.116:554/ESPN2.ts RTSP/1.0
CSeq: 3
Session: 00007689
Scale: 4.0

RTSP/1.0 200 OK
CSeq: 3
Date: Mon, Sep 12 2011 11:33:07 GMT
Scale: 4
Range: npt=5.100-
Session: 00007689
RTP-Info: url=rtsp://107.108.89.116/ESPN2.ts/track1;seq=8539;rtptime=13709
PAUSE

The PAUSE request causes the stream delivery to be interrupted (halted) temporarily.

Example

PAUSE rtsp://107.108.89.116:554/ESPN2.ts RTSP/1.0
CSeq: 4
Session: 00007689
RTSP/1.0 200 OK
CSeq: 4
Date: Mon, Sep 12 2011 11:35:10 GMT

Note

RFC 2326 Section 10.6

GET_PARAMETER

The GET_PARAMETER used for Keep-Alive message.

Important

Keep-Alive interval is defined in the “timeout” value of SETUP command. (Default value is 25 seconds).

TEARDOWN

The TEARDOWN request stops the stream delivery for the given URI, freeing the resources associated with it.

Example

TEARDOWN rtsp://107.108.89.116:554/sampleTS.ts RTSP/1.0
CSeq: 5
Session: 00007689
RTSP/1.0 200 OK
CSeq: 5
Date: Mon, Sep 12 2011 11:44:45 GMT

Note

RFC 2326 Section 10.7

To be supported RTSP Methods

The following methods will be supported in future releases:

  • ANNOUNCE
  • SET_PARAMETER
  • REDIRECT

Unsupported RTSP Methods

The following methods are not supported:

  • RECORD

Header Definition Table

The following Table summarizes the header fields used by RTSP. Interpret these abbreviated short form as given below.

“g”
designates general request headers to be found in both requests and Responses
“R”
designates request headers
“r”
designates response headers
“e”
designates entity header fields
“req.”
designates  MUST be implemented
“opt.”
designates Optional field
“entity”
refers to all methods that return a message body
Header Type Support Method SamsungRTSP Support
Accept R opt. entity Yes
Accept-Encoding R opt. entity No
Accept-Language R opt. all No
Allow r opt. all No
Authorization R opt. all No
Bandwidth R opt. all No
Blocksize R opt. all but OPTIONS, TEARDOWN No
Cache-Control g opt. SETUP No
Conference R opt. SETUP No
Connection g req. all No
Content-Base e opt. entity No
Content-Encoding e req. SET_PARAMETER No
Content-Encoding e req. DESCRIBE, ANNOUNCE No
Content-Language e req. DESCRIBE, ANNOUNCE No
Content-Length e req. SET_PARAMETER, ANNOUNCE Yes
Content-Length e req. entity Yes
Content-Location e opt. entity No
Content-Type e req. SET_PARAMETER, ANNOUNCE No
Content-Type r req. entity No
CSeq g req. all Yes
Date g opt. all Yes
Expires e opt. DESCRIBE, ANNOUNCE No
From R opt. all No
If-Modified-Since R opt. DESCRIBE, SETUP No
Last-Modified e opt. entity No
Proxy-Authenticate R req. all No
Proxy-Require R req. all No
Public r opt. All Yes
Range R opt. PLAY, PAUSE, RECORD Yes
Range r opt. PLAY, PAUSE, RECORD Yes
Referer R opt. all No
Require R req. All No
Retry-After r opt. all No
RTP-Info r req. PLAY Yes
Scale Rr opt. PLAY, RECORD No
Session Rr req. all but SETUP, OPTIONS Yes
Server r opt. all No
Speed Rr opt. PLAY No
Transport Rr req. SETUP Yes
Unsupported r req. all No
User-Agent R opt. All No
Via g opt. all No
WWW-Authenticate r opt. all No

SDP Supported Feature

SDP provides a standard representation for session description. Following are table contains SDP fields.

SDP Example

v=0
o=- 1315908999736260 1 IN IP4 107.108.89.116
s=MPEG Transport Stream, streamed by the LIVE555 Media Server
i=ESPN2.ts
t=0 0
a=tool:LIVE555 Streaming Media v2011.05.25
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:MPEG Transport Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:ESPN2.ts
m=video 0 RTP/AVP 33
c=IN IP4 0.0.0.0
b=AS:5000
a=control:track1

Session Level description (Ref- RFC 4566 Section 5)

SDP Field Description SamsungRTSP stack Supported
v Version Yes
o originator and session identifier Yes
s session name Yes
i session information Yes
u URI of description Yes
e email address Yes
p phone number Yes
c connection information Yes
b bandwidth information Yes
z time zone adjustments Yes
k encryption key Yes
a session attribute Yes
t time the session is active Yes
r repeat times Yes
m media name and transport address Yes
Protocol Version (“v=”)

The “v=” field gives the version of the Session Description Protocol.

Syntax

v=0

SamsungRTSP Stack Support: Supported

Origin (“o=”)

The “o=” field gives the originator of the session

Syntax

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

SamsungRTSP Stack Support: Support all options

Session Name (“s=”)

The “s=” field is the textual session name. There MUST be one and only one “s=” field per session description.

Syntax

s=<session name>

SamsungRTSP Stack Support: Support

Session Information (“i=”)

The “i=” field provides textual information about the session. There MUST be at most one session-level “i=” field per session description, and at most one “i=” field per media.

Syntax

i=<session description>

SamsungRTSP Stack Support: Support

URI (“u=”)

A URI is a Uniform Resource Identifier as used by WWW clients.

Syntax

u=<uri>

SamsungRTSP Stack Support: Support

Email Address and Phone Number (“e=” and “p”)

The “e=” and “p=” lines specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement.

Syntax

e=<email-address> and p=<phone-number>

SamsungRTSP Stack Support: Support

Connection Data (“c=”)

A session description MUST contain either at least one “c=” field in each media description or a single “c=” field at the session level.

Syntax

c=<nettype> <addrtype> <connection-address>

SamsungRTSP Stack Support: Support all options

Bandwidth (“b=”)

This OPTIONAL field denotes the proposed bandwidth to be used by the session or media.

Syntax

b=<bwtype>:<bandwidth>

SamsungRTSP Stack Support: Support all options

Timing (“t=”)

The “t=” lines specify the start and stop times for a session.

Syntax

t=<start-time> <stop-time>

SamsungRTSP Stack Support: Support all options

Repeat Times (“r=”)

“r=” fields specify repeat times for a session.

Syntax

r=<repeat interval> <active duration> <offsets from start-time>

SamsungRTSP Stack Support: Support all options

Time Zones (“z=”)

To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify offsets from the base time.

Syntax

z=<adjustment time> <offset> <adjustment time> <offset> ....

SamsungRTSP Stack Support: Support all options

Encryption Keys (“k=”)

If transported over a secure and trusted channel, the Session Description Protocol MAY be used to convey encryption keys. A simple mechanism for key exchange is provided by the key field (“k=”)

Syntax

k=<method> and  k=<method>:<encryption key>

Available Method: clear, base64, uri, prompt

SamsungRTSP Stack Support: Support all options and methods

Attributes (“a=”)

Attributes are the primary means for extending SDP.

Syntax

a=<attribute> and a=<attribute>:<value>

SamsungRTSP Stack Support: Support all options

Media Level Description (Ref- RFC 4566 Section 5)

SDP Field Description SamsungRTSP StackSupported
i media title Yes
c connection information Yes
b bandwidth information Yes
k encryption key Yes
a media attribute Yes
Media Descriptions (“m=”)

A session description may contain a number of media descriptions. Each media description starts with an “m=” field and is terminated by either the next “m=” field or by the end of the session description.

Syntax

m=<media> port> <proto> <fmt> ...

SamsungRTSP Stack Support: Support all options

SDP Attributes at Media level (“a=”)

The following attributes are defined.

SamsungRTSP Not Supported:

  • a=inactive

SamsungRTSP Supported:

  • a=cat:<category>
  • a=maxptime:<maximum packet time>
  • a=recvonly
  • a=sendrecv
  • a=sendonly
  • a=orient:<orientation>
  • a=type:<conference type>
  • a=charset:<character set>
  • a=sdplang:<language tag>
  • a=lang:<language tag>
  • a=framerate:<frame rate>
  • a=keywds:<keywords>
  • a=tool:<name and version of tool>
  • a=ptime:<packet time>
  • a=quality:<quality>
  • a=fmtp:<format> <format specific parameters>
  • a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encodingparameters>]

RTP Supported Feature

RTP is used to parse RTP Packet to extract RTP header field and extract data from packet.

After extracting data goes for depacketization. SamsungRTSP Stack support following depacketizers:

  • H264 H264 depacketization using RFC 3984.
  • H263 H263 depacketization using RFC 4629.
  • Mpeg 4 MPEG4 depacketization using RFC 3640..
  • WMV WMV depacketization using RTP Payload Format for Windows Media Audio and Video, v1.0
  • Fragmented Frame mode SamsungRTSP Stack: Support
  • Non - Fragmented Frame mode SamsungRTSP Stack: Support
  • Mpeg1 MPEG1 depacketization using for RFC 2250.
  • Mpeg 2 MPEG2 depacketization using for RFC 2250.
  • Vorbis Audio
    • Fragmented Frame mode SamsungRTSP Stack: Support
    • Non - Fragmented Frame mode SamsungRTSP Stack: Support
  • Mpeg Audio MpegAudio depacketization using RFC 1890
  • AAC AAC depacketization using RFC 3640
  • AC3 AC3 depacketization using RFC 4184
  • WMA WMA depacketization using RTP Payload Format for Windows Media Audio and Video, v1.0
    • Fragmented Frame mode SamsungRTSP Stack: Support
    • Non - Fragmented Frame mode SamsungRTSP Stack: Support
  • LPCM LPCM depacketiation using RFC 1890
  • AAC-LATM Non Fragmented LATM depacketization using RFC 3016
  • XASF XASF depacketization using [MS-RTSP]: Real-Time Streaming Protocol (RTSP) Windows Media Extensions (Section 2.2.1 RTP Payload Format for ASF Data Packets)

RTCP Supported Feature

RTCP is used to control data channel based on TCP Reports. The following RTCP packet types to carry a variety of control information:

  • Sender Report (SR) Sender report, for transmission and reception statistics from participants that are active Senders. SamsungRTSP Stack: Stack support only parsing of SR it does not create SR.
  • Receiver Report (RR) Receiver report, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources.
  • SamsungRTSP Stack Stack Only Create RR it does not Parse.
  • Source description (SDES) Source description items, including CNAME. SamsungRTSP Stack: Stack does not support SDES.
  • BYE Indicates end of participation. SamsungRTSP Stack: Stack support BYE Packet.
  • APP Application-specific functions. SamsungRTSP Stack: Stack does not support APP.

More Feature Supported

RTP over TCP

By default, RTP data comes over UDP, if data does not come on UDP, Samsung DTV Client will try RTP over TCP.

To support TCP mode by default, application should provide option in url with following format:

rtsp://154.214.97.134:554/rtsp/sd.ts|TCP

Pre-rolling Buffer

Default size is 1 Mbyte, but application can set optimized buffer size using time value.

rtsp://154.214.97.134:554/rtsp/sd.ts|caching=300

Player will set pre-rolling buffer size as 300ms.

Keep-Alive

Samsung RTSP Client does not send Keep-Alive message in TCP mode. It sends OPTION or GET_PARAMETER command for Keep-Alive message in UDP mode only.

Trick play Feature

The Samsung RTSP client supports requesting the trick play operation to the server. The server side processes and generates the trick play effect by altering the stream while transmitting it to the client. The server side typically achieves the trick speed effect by skipping and sending the video frames with adjusted timestamps. But some servers may not adjust the time stamps even though they do skip and send video frames. To support such servers Samsung RTSP client adjusts the timestamps based on the trick speed on the client side. Given below the RTSP command sequences for trick play:

RTSP PLAY command when switching to 2X trick speed

PLAY rtsp://107.108.175.185:554/18M.ts RTSP/1.0
CSeq: 5
Session: 000006EB
Scale: 2.0
RTSP/1.0 200 OK
CSeq: 5
Date: Fri, Aug 24 2012 10:59:14 GMT
Scale: 2.000000
Range: npt=55.543-
Session: 000006EB
RTP-Info: url=rtsp://107.108.175.185/18M.ts/track1;seq=34759;rtptime=2310955996

RTSP PLAY command when switching back to the normal speed

PLAY rtsp://107.108.175.185:554/18M.ts RTSP/1.0
CSeq: 9
Session: 000006EB
Scale: 1.0
RTSP/1.0 200 OK
CSeq: 9
Date: Fri, Aug 24 2012 10:59:17 GMT
Scale: 1.000000
Range: npt=45.568-
Session: 000006EB
RTP-Info: url=rtsp://107.108.175.185/18M.ts/track1;seq=38942;rtptime=2474414767

Samsung RTSP Client doesn’t send npt time for trick. Server has to use current playing npt time for start of frame.

RTSP SEEK Support

Samsung RTSP client supports requesting the SEEK operation to the server. The Samsung RTSP client issues RTSP PAUSE request to the RTSP server and then issues the RTSP PLAY request to the server with the Range parameter mentioning start from the seek timestamp.

The sequence is shown below:

PAUSE rtsp://107.108.175.185:554/18M.ts RTSP/1.0
CSeq: 4
Session: 000071EA
RTSP/1.0 200 OK
CSeq: 4
Date: Fri, Aug 24 2012 11:07:42 GMT
Session: 000071EA
PLAY rtsp://107.108.175.185:554/18M.ts RTSP/1.0
CSeq: 5
Session: 000071EA
Range: npt=13.000-
Scale: 1.0
RTSP/1.0 200 OK
CSeq: 5
Date: Fri, Aug 24 2012 11:07:42 GMT
Scale: 1.000000
Range: npt=13.000-
Session: 000071EA
RTP-Info: url=rtsp://107.108.175.185/18M.ts/track1;seq=44168;rtptime=675442

Samsung RTSP Client doesn’t support seek while trick mode.

Support using GET_PARAMETER RTSP request

Samsung RTSP client supports the Keep Alive method by following two methods:

  1. By issuing RTSP OPTIONS request to the server at the periodic interval

    OPTIONS rtsp://107.108.175.185:554/18M.ts RTSP/1.0
CSeq: 4
Session: 00007FDD
RTSP/1.0 200 OK
CSeq: 4
Date: Fri, Aug 24 2012 11:32:54 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

  2. By issuing RTSP GET_PARAMETER request to the server at the periodic interval

    GET_PARAMETER rtsp://107.108.175.185:554/18M.ts RTSP/1.0
CSeq: 4
Session: 00000106
RTSP/1.0 200 OK
CSeq: 4
Date: Fri, Aug 24 2012 11:30:09 GMT
Session: 00000106

Live IPTV

Samsung RTSP Client support RTP Multicasting.

IGMP Version

Samsung support IGMP Version 2.0 only. Any other version will not be supported.

Retransmission (Future Plan)

Losses may also be recovered if the receivers send feedback to the sender asking it to retransmit the lost packet. Samsung RTSP client supports sending such feedback report to retrieve any missing or lost RTP packets from the server in case the server supports the retransmission methodology. Retransmission is one of the techniques used for providing error correction over the loss prone UDP channel. Samsung RTSP client composes and sends the NACK RTCP report to the server. NACK RTCP report refers to the RTCP Feedback Negative Acknowledgement. Samsung RTSP client does not send the RTCP ACK report. Samsung RTSP client follows the timing rule for sending the RTCP NACK reports as per the RFC 4588. The NACK RTCP reports can be sent as per immediate, early and regular timing interval. This is decided based on the available or decided bandwidth for the retransmission purpose. Samsung RTSP client supports retransmission using both SSRC multiplexing and session multiplexing.

SDP snippet from server using session multiplexing for retransmission

a=group:FID 1 2
m=video 0/1 RTP/AVPF 33
a=control:track1
a=mid:1
a=rtcp-fb:33 nack
c=IN IP4 0.0.0.0
m=video 0/1 RTP/AVPF 100
a=rtpmap:100 rtx/0/0
a=fmtp:100 apt=33;rtx-time=500
a=control:track2
a=mid:2

SDP snippet from server using SSRC multiplexing for retransmission

m=video 0/1 RTP/AVPF 33 100
a=rtpmap:100 rtx/0/0
a=fmtp:100 apt=100;rtx-time=500
a=control:track1
a=rtcp-fb:33 nack

Forward Error Correction (FEC) (Future Plan)

Forward Error Correction (FEC) algorithm transforms a bit stream to make it more robust for transmission. The transformation generates the larger bit stream intended for transmission over a loss prone medium or network. The additional information in the transformed bit stream allows receivers to exactly reconstruct the original bit stream in the presence of the transmission errors. There are multiple schemes available.

Samsung RTSP client supports the parity FEC scheme (XOR). Samsung RTSP client has been implemented following the RFC 5109 for FEC and RFC 5956 for SDP related specifications for FEC. Given below is the sample how the details regarding the FEC can be shared by the server to the Samsung RTSP client. The below snippet of SDP is using SSRC multiplexing doe FEC and using the XOR algorithm.

m=video 0/1 RTP/AVPF 33 105
a=rtpmap:105 parityfec/90000/0
a=ssrc:1000
a=ssrc:1001
a=ssrc-group:FEC-FR 1000 1001
a=control:track1
c=IN IP4 0.0.0.0

Commands from Sample pcap files

From OPTION to TEARDOWN

OPTIONS rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER

DESCRIBE rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 1
Accept: application/sdp
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER
Content-Type: application/sdp
Content-Length: 178
v=0
o=- 284233 0 IN IP4 84.50.149.208
s=RTSP Session
t=0 0
c=IN IP4 84.50.149.208
b=AS:4247.000
a=type:vod
a=range:npt=0-5547
m=video 0 UDP 33
m=video 0 RTP/AVP/UDP 33

SETUP rtsp://90.191.254.125:554/test_shutter.mpg/ RTSP/1.0
CSeq: 2
Transport: RAW/RAW/UDP;unicast;client_port=53750-53751;mode=play
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 2
Session: 3141362059465100490;timeout=60
Transport: RAW/RAW/UDP;unicast;destination=221.163.253.140;client_port=53750;source=90.191.254.125;server_port=58496

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 3
Session: 3141362059465100490

Range: npt=0.000-
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 3
Session: 3141362059465100490
Scale: 1.00
Range: npt=0-

GET_PARAMETER rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 4
Session: 3141362059465100490
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 4
Session: 3141362059465100490

TEARDOWN rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 5
Session: 3141362059465100490
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 5
Session: 3141362059465100490
Range: npt=29-

Trick Play

OPTIONS rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER

DESCRIBE rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 1
Accept: application/sdp
RTSP/1.0 200 OK
Server: Orbit2x

CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER
Content-Type: application/sdp
Content-Length: 178
v=0
o=- 284254 0 IN IP4 84.50.149.208
s=RTSP Session
t=0 0
c=IN IP4 84.50.149.208
b=AS:4247.000
a=type:vod
a=range:npt=0-5547
m=video 0 UDP 33
m=video 0 RTP/AVP/UDP 33



SETUP rtsp://90.191.254.125:554/test_shutter.mpg/ RTSP/1.0
CSeq: 2
Transport: RAW/RAW/UDP;unicast;client_port=54184-54185;mode=play
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 2
Session: 1399219722667561750;timeout=60
Transport: RAW/RAW/UDP;unicast;destination=221.163.253.140;client_port=54184;source=90.191.254.125;server_port=58694

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 3
Session: 1399219722667561750
Range: npt=0.000-
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 3
Session: 1399219722667561750
Scale: 1.00
Range: npt=0-

GET_PARAMETER rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 4
Session: 1399219722667561750
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 4
Session: 1399219722667561750

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 5
Session: 1399219722667561750
Scale: 4.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 5
Session: 1399219722667561750
Scale: 3.58
Range: npt=28-

GET_PARAMETER rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 6
Session: 1399219722667561750
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 6
Session: 1399219722667561750

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 7
Session: 1399219722667561750
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 7
Session: 1399219722667561750
Scale: 1.00
Range: npt=226-

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 8
Session: 1399219722667561750
Scale: 16.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 8
Session: 1399219722667561750
Scale: 14.32
Range: npt=240-

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 9
Session: 1399219722667561750
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 9
Session: 1399219722667561750
Scale: 1.00
Range: npt=381-

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 10
Session: 1399219722667561750
Scale: 4.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 10
Session: 1399219722667561750
Scale: 3.58
Range: npt=392-

TEARDOWN rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 11
Session: 1399219722667561750
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 11
Session: 1399219722667561750
Range: npt=421-

Seek Play

OPTIONS rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER

DESCRIBE rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 1
Accept: application/sdp
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER
Content-Type: application/sdp
Content-Length: 178
v=0
o=- 284292 0 IN IP4 84.50.149.208
s=RTSP Session
t=0 0
c=IN IP4 84.50.149.208
b=AS:4247.000
a=type:vod
a=range:npt=0-5547
m=video 0 UDP 33
m=video 0 RTP/AVP/UDP 33
SETUP rtsp://90.191.254.125:554/test_shutter.mpg/ RTSP/1.0
CSeq: 2
Transport: RAW/RAW/UDP;unicast;client_port=54184-54185;mode=play
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 2
Session: 1078930203263467403;timeout=60
Transport: RAW/RAW/UDP;unicast;destination=221.163.253.140;client_port=54184;source=90.191.254.125;server_port=59056

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 3
Session: 1078930203263467403
Range: npt=0.000-
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 3
Session: 1078930203263467403
Scale: 1.00
Range: npt=0-

PAUSE rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 4
Session: 1078930203263467403
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 4
Session: 1078930203263467403
Range: npt=19-

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 5
Session: 1078930203263467403
Range: npt=508.000-
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 5
Session: 1078930203263467403
Scale: 1.00
Range: npt=508-

TEARDOWN rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 6
Session: 1078930203263467403
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 6
Session: 1078930203263467403
Range: npt=517-

Get Parameter

OPTIONS rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER

DESCRIBE rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 1
Accept: application/sdp
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 1
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER
Content-Type: application/sdp
Content-Length: 178
v=0
o=- 284233 0 IN IP4 84.50.149.208
s=RTSP Session
t=0 0
c=IN IP4 84.50.149.208
b=AS:4247.000
a=type:vod
a=range:npt=0-5547
m=video 0 UDP 33
m=video 0 RTP/AVP/UDP 33

SETUP rtsp://90.191.254.125:554/test_shutter.mpg/ RTSP/1.0
CSeq: 2
Transport: RAW/RAW/UDP;unicast;client_port=53750-53751;mode=play
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 2
Session: 3141362059465100490;timeout=60
Transport: RAW/RAW/UDP;unicast;destination=221.163.253.140;client_port=53750;source=90.191.254.125;server_port=58496

PLAY rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 3
Session: 3141362059465100490
Range: npt=0.000-
Scale: 1.0
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 3
Session: 3141362059465100490
Scale: 1.00
Range: npt=0-

GET_PARAMETER rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 4
Session: 3141362059465100490
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 4
Session: 3141362059465100490

TEARDOWN rtsp://90.191.254.125:554/test_shutter.mpg RTSP/1.0
CSeq: 5
Session: 3141362059465100490
RTSP/1.0 200 OK
Server: Orbit2x
CSeq: 5
Session: 3141362059465100490
Range: npt=29-

Terminology / Abbreviations

Terminology / Abbreviations Description
KA Keep-alive
RR Receiver Report
FEC Forward Error Correction
SDES Source Description
APP Application
FrankieWang008
关注
  • 2
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
RTSP.rar RTSP协议文档，包括中文版和英文版，1.0版本的。
07-28
RTSP协议文档，包括中文版和英文版，1.0版本的。RTSP协议是音视频传输协议中重要的协议。比较常用的场景为IPC和NVR之间的码率传输。
公共rtsp_RTSP_协议中文版.pdf
weixin_42393272的博客
12-29 376
RTSP 协议中文版Network Working Group H. SchulzrinneRequest for Comments: 2326 Columbia U.Category: Standards Track ...
实时流协议---RTSP【详解】
热门推荐
王木木
01-28 2万+
一、RTSP协议介绍 RTSP（Real Time Streaming Protocol 实时流协议）是一个有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如开始、暂停、快进、停止等控制，RTSP的作用相当于流媒体服务器的远程控制，而它本身并不传输数据。 官方指导文档参考：RFC 2326 - Real Time Streaming Protocol (RTSP) 它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。 RTSP具有重新导...
RTSP协议文档摘录（一）
最新发布
weixin_49621395的博客
04-12 560
RFC 2326 RTSP协议文档翻译摘录
RtspProxy RTSP 重定向 Redirect 的实现
Langeldep的专栏
03-07 8513
当 流媒体服务器有上百台， 需要动态的选择一台均衡负载最小的服务器， 或者选择一台离客户端机器最近的一台服务器提供流服务的时候，我们可以利用 rtsp协议的redirect 机制进行重定向，这样的话， 我们可以通过入口机进行分发重定向。实现原理很简单：client -> server   发出 rtsp请求服务器收到请求后, 取出 客户端的 IP 地址， 根据客户端的IP地址， 判断客户端所在的地区， 在客户端所在地的服务器中选择一台负载最小的服务器。通过 redirect 协议 的Location  ，
RTSP协议简要介绍
infi
12-19 2450
参考：RFC文档 https://www.rfc-editor.org/rfc/rfc2326.html 目录 1、RTSP方法定义 1.1、OPTIONS 1.2、DESCRIBE 1.3、ANNOUNCE 1.4、SETUP 1.5、PLAY 1.6、PAUSE 1.7、TEARDOWN 1.8、GET_PARAMETER 1.9、SET_PARAMETER 1...
华为RTSP协议文档
03-05
华为的RTSP文档，内容详细，示例讲解全面，适合不喜欢看英文文档的童鞋！
rtsp协议英文版全文
11-23
rtsp协议英文版全文，流媒体会话控制协议
RTSP协议文档-RFC2326
08-01
标准流媒体协议,RFC2326 - Real Time Streaming Protocol (RTSP)，详细的英文版本，开发流媒体必备资料。
rtsp、rtp、rtcp、rtmp中英文协议
02-28
压缩包所包含的流媒体协议有rtmp中英文协议文档，rtsp、rtp、rtcp英文协议文档，介意着勿下。
RTSP规范（中文版）
03-20
实时流协议（RTSP）是应用层协议，控制实时数据的传送 。RTSP提供了一个可扩展框架，使受控、按需传输实时数据（如音频与视频）成为可能。数据源包括现场数据与存储在剪辑中的数据。
RTSP 协议中文版(可链接目录)
02-15
RTSP 协议中文版 RTSP 全称 Real Time Streaming Protocol (RTSP) Status of this Memo 本文档目录完成，支持左侧导航栏和链接跳转 This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
RTSP开发相关文档汇集
11-07
学习和开发RTSP过程中搜集到的一些标准文档资料，比上一份上传的资源更加齐全，有些是中文版的，对做RTSP开发很有帮助。
RTSP相关的RFC文档资料汇集
10-14
近期实现RTSP过程中搜集到的一些标准的文档资料 对学习RTSP流媒体技术有很大帮助 如RTSP（RFC2326） RTP（RFC3550 JPEG（RFC2345 音频视频的RTP打包传输等 有部分已经被翻译为中文 希望与大家共享
rtsp 协议文档（RFC2326）
05-14
rtsp 协议标准，有助于视频流的开发！ rtsp是应用层上一种控制协议，最终的视频数据是由RTP和RTCP来实现的~
RTSP协议分析
linux嵌入式驱动软件开发
05-12 2363
Network Working Group H. SchulzrinneRequest for Comments: 2326 Columbia U.Category: Standards Track A. RaoNetscapeR. LanphierRealNetworksApril 1998翻译： radium 2005.1实时流协议(RTSP) ( Real Time Streaming Pr
RTSP协议文档翻译
wsb19871010的专栏
09-05 1860
RTSP部分翻译整理 1        RTSP简介 建立和控制一路或多路连续媒体流的协议，比如视频流、音频流。其不能通过本身递送连续的媒体流。具有易扩展性及易解析性等特点。 1.1      RTSP和HTTP的区别 RTSP的描述和HTTP基本一致，但还是有些区别，比如： Ø  RTSP重新定义了方法类型，以及自己的协议描述 Ø  RTSP通常是有状态的，而HTTP是无状态的
rtsp流程讲详细一些
03-14
RTSP（Real Time Streaming Protocol）是一种用于实时数据传输的协议，它可以用于音频、视频等多媒体数据的传输。RTSP协议的流程如下： 1. 客户端向服务器发送一个RTSP请求，请求打开一个流媒体。 2. 服务器接收到请求后，会返回一个RTSP响应，其中包含了流媒体的相关信息，如媒体类型、编码方式、传输协议等。 3. 客户端根据服务器返回的信息，选择合适的传输协议（如UDP、TCP等），并向服务器发送一个SETUP请求，请求建立传输通道。 4. 服务器接收到SETUP请求后，会返回一个RTSP响应，其中包含了传输通道的相关信息，如端口号、传输方式等。 5. 客户端向服务器发送一个PLAY请求，请求开始播放流媒体。 6. 服务器接收到PLAY请求后，会返回一个RTSP响应，表示开始播放流媒体。 7. 客户端接收到服务器的响应后，开始接收流媒体数据，并进行解码、播放等操作。 总的来说，RTSP协议的流程就是客户端向服务器发送请求，服务器返回响应，客户端根据响应信息建立传输通道，最后开始播放流媒体。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值