Transcript RTSP . ppt

RTSP
Real Time Streaming Protocol
Presented by
Group NEO
-Jitin Keith
-Prashant Morgaonkar
RTSP
Real Time Streaming Protocol
IETF RFC 2326
RTSP
RTSP is a signaling protocol which acts as a
“Remote Control” for controlling a IP media
server.
Very similar to HTTP /1.1
RTSP can request

Server to send media

Server invited to join a conference

Server announces that additional media
available
Overall Function




A presentation description file defines the type
of media streams and its properties such as
encoding language etc.
A presentation may contain several media
streams
RTSP can use TCP, UDP or MUDP
Popular RTSP clients:
Windows Media Player
Real Player
RTSP Typical Method Types




Setup: Causes the server to allocate resources
for a stream and start an RTSP session
Play-Record: Starts data transmission on a
stream allocated via SETUP
Pause: Temporarily halts a stream without
freeing server resources.
Teardown: Frees resources associated with the
stream. The RTSP session ceases to exist on the
server.
RTSP Status Codes



Success 2XX
Redirect 3XX
Client Error 4XX
RTSP Method types

OPTIONS


DESCRIBE


A client can issue a SETUP request for a stream that is already playing to
change transport parameters
SETUP,


The DESCRIBE method retrieves the description of a presentation
ANNOUNCE


If the client is about to try a nonstandard request
A client can issue a SETUP request for a stream that is already playing to
change transport parameters
PLAY,

The PLAY method tells the server to start sending data via the
mechanism specified in SETUP
RTSP Method types

PAUSE


TEARDOWN


The GET_PARAMETER request retrieves the value of a parameter of a
presentation or stream
REDIRECT


The TEARDOWN request stops the stream
GET_PARAMETER, SET_PARAMETER


The PAUSE request causes the stream delivery to be interrupted (halted)
temporarily
A redirect request informs the client that it must connect to another
server location
RECORD

Start recording the media
RTSP Client FSM
state
Init
message sent next state after response
SETUP
Ready
TEARDOWN
Init
Ready PLAY
Playing
RECORD
Recording
TEARDOWN
Init
SETUP
Ready
Playing PAUSE
Ready
TEARDOWN
Init
PLAY
Playing
SETUP
Playing (changed transport)
Recording PAUSE
Ready
TEARDOWN
Init
RECORD
Recording
SETUP
Recording (changed transport)
RTSP Server FSM
state
Init
message received next state
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
The "next state" column indicates the state assumed after sending a success response (2xx). If a request results in a
status code of 3xx, the state becomes Init. A status code of 4xx results in no change
Security issues



Denial of service: Flood any arbitrary machine
on the Internet with unrequested RTSP streams
Session hijacking
Authentication
Streaming Stored Multimedia (1/2)
Streaming Stored Multimedia (2/2)
Stored media streaming

Internet multimedia: simplest approach
Internet
multimedia: simplest
approach
files
files transferred
transferred as
as HTTP
HTTP object
received in entirety at client
then passed to player
audio,
video not streamed:
 no, “pipelining,” long delays until playout!
Streaming vs. Download of Stored
Multimedia
Download: Receive entire
content before playback begins
High “start-up” delay as media
file can be large
~ 4GB for a 2 hour MPEG II
movie
Streaming: Play the media file while it is being received
Reasonable “start-up” delays
Reception Rate >= playback rate.
Progressive Download
browser GETs metafile
browser launches player, passing metafile
player contacts server
server downloads audio/video to player
RTSP Example

Scenario:
metafile communicated to web browser
browser launches player
player sets up an RTSP control connection, data
connection to streaming server
RTSP Operation
Client Buffering
Client-side buffering, playout delay compensate
for network-added delay, delay jitter
Client Buffering
Client-side buffering, playout delay compensate
for network-added delay, delay jitter
Streaming Multimedia: UDP or TCP?

UDP
server sends at rate appropriate for client (oblivious to
network congestion !)
often send rate = encoding rate = constant rate
then, fill rate = constant rate - packet loss
short playout delay (2-5 seconds) to compensate for network
delay jitter
error recover: time permitting

TCP
send at maximum possible rate under TCP
fill rate fluctuates due to TCP congestion control
larger playout delay: smooth TCP delivery rate
HTTP/TCP passes more easily through firewalls
Packet Loss

network loss: IP datagram lost due to network
congestion (router buffer overflow)

delay loss: IP datagram arrives too late for
playout at receiver
Forward Error Correction (FEC)
For every group of n packets generate k redundant
packets
Send out n+k packets, increasing the bandwidth by factor
k/n.
Can reconstruct the original n packets provided at most k
Packets are lost from the group
Works well at high loss rate (for a proper choice of k)
Handles “bursty” packet losses
Cost: increase in transmission cost (bandwidth)
Another FEC Example
• “Piggyback lower
quality stream”
• Example: send
lower resolution
audio stream as
the redundant
information
Whenever there is non-consecutive loss, thereceiver can conceal the loss.
Can also append (n-1)st and (n-2)nd low-bit ratechun
Interleaving
Interleaving
Re-sequence packets before transmission
Better handling of “burst” losses
Results in increased playout delay
Multimedia Networking

Exciting, industry relevant research topic

Multimedia is everywhere

Tons of open problems
References
[1]www.wikipedia.com
[2]http://www.ietf.org/rfc/rfc2326.txt
[3] http://tesys.cres.it/jsp/activities/rtsp/rtsp.jsp
[4]http://www.csee.umbc.edu/~pmundur/courses
/CMSC691C/lab5-kurose-ross.html