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 conditions. 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.
If 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.

Samsung provides the following RTSP specifications:
RTSP has 11 methods to control entire RTSP Session. The following categories are based on the current SamsungRTSP Stack.
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
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
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".
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
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
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
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
The following methods will be supported in future releases:
The following methods are not supported:
The following Table summarizes the header fields used by RTSP. Interpret these abbreviated short form as given below.
|
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 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
|
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 |
The "v=" field gives the version of the Session Description Protocol.
Syntax:
v=0
SamsungRTSP Stack Support: Supported
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
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
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
A URI is a Uniform Resource Identifier as used by WWW clients.
Syntax:
u=<uri>
SamsungRTSP Stack Support: Support
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
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
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
The "t=" lines specify the start and stop times for a session.
Syntax:
t=<start-time> <stop-time>
SamsungRTSP Stack Support: Support all options
"r=" fields specify repeat times for a session.
Syntax:
r=<repeat interval> <active duration> <offsets from start-time>
SamsungRTSP Stack Support: Support all options
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
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 are the primary means for extending SDP.
Syntax:
a=<attribute> and a=<attribute>:<value>
SamsungRTSP Stack Support: Support all options
|
SDP Field |
Description |
SamsungRTSP stack Supported |
|
i |
media title |
Yes |
|
c |
connection information |
Yes |
|
b |
bandwidth information |
Yes |
|
k |
encryption key |
Yes |
|
a |
media attribute |
Yes |
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
The following attributes are defined.
SamsungRTSP Not Supported:
SamsungRTSP Supported:
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 depacketization using RFC 3984.
H263 depacketization using RFC 4629.
MPEG4 depacketization using RFC 3640..
WMV depacketization using RTP Payload Format for Windows Media Audio and Video, v1.0
SamsungRTSP Stack: Support
SamsungRTSP Stack: Support
MPEG1 depacketization using for RFC 2250.
MPEG2 depacketization using for RFC 2250.
SamsungRTSP Stack: Support
SamsungRTSP Stack: Support
MpegAudio depacketization using RFC 1890
AAC depacketization using RFC 3640
AC3 depacketization using RFC 4184
WMA depacketization using RTP Payload Format for Windows Media Audio and Video, v1.0
SamsungRTSP Stack: Support
SamsungRTSP Stack: Support
LPCM depacketiation using RFC 1890
Non Fragmented
LATM depacketization using RFC 3016
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 is used to control data channel based on TCP Reports.
The following RTCP packet types to carry a variety of control information:
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, for reception statistics from participants that are not active senders and in combination with SR for active senders reporting on more than 31 sources.
Stack Only Create RR it does not Parse.
Source description items, including CNAME.
SamsungRTSP Stack: Stack does not support SDES.
Indicates end of participation.
SamsungRTSP Stack: Stack support BYE Packet.
Application-specific functions.
SamsungRTSP Stack: Stack does not support APP.
Additional supported features include:
Some time it is mentioned that RTP data will come on TCP port and sometimes if data is not coming on UDP SamsungRTSP stack gives try on TCP for RTP data.
SamsungRTSP Stack support RTP Multicasting.