1
POSTECH DP&NM Lab
Extending Real-time Streaming Protocol for Interoperability
Byungchul Park
DPNM Lab., CSE, POSTECH
Email: [email protected]
2008. 6. 24
2
POSTECH DP&NM Lab
Table of Contents
• RTSP Overview• Difference between RTSP and HTTP• Properties of RTSP• RTSP Methods• RTSP Implementations• Problems of Current Protocol• Proposal for State Transition Condition• Summary• Appendix• Q&A
3
POSTECH DP&NM Lab
RTSP Overview (1/2)
• IEFT standard RFC 2326 (April, 1998)– Multiparty Multimedia Session Control (MMUSIC) WG
• RTSP is an application level protocol– Control over the delivery of data with real-time properties– Network remote control– RTSP server can use any type of packet format for sending
media data to an RTSP client– Real Time Transport Protocol (RTP) over unicast UDP
4
POSTECH DP&NM Lab
RTSP Overview (2/2)
• RTSP client sets up three network channels with RTSP server
Control & negotiation
Media data delivery Synchronization & QoS Info.
5
POSTECH DP&NM Lab
Difference between RTSP and HTTP
• The RTSP is intentionally similar in syntax and operation to HTTP/1.1. However, it differs in a number of important aspects from HTTP– RTSP introduces a number of new methods and has a different
protocol identifier.
– An RTSP server needs to maintain state by default in almost all cases, as opposed to the stateless nature of HTTP.
– Both an RTSP server and client can issue requests.
– Data is carried out-of-band by a different protocol. (There is an exception to this.)
– RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1, consistent with current HTML internationalization efforts.
– The Request-URI always contains the absolute URI.
6
POSTECH DP&NM Lab
Properties of RTSP
• Extendable • Easy to parse • Secure • Transport-independent • Multi-server capable • Control of recording devices • Separation of stream control and conference initiation • Suitable for professional applications • Presentation description neutral • HTTP-friendly • Appropriate server control • Transport negotiation • Capability negotiation
New methods and parameters can be easily added to RTSPRTSP can be parsed by standard HTTP
parsersRTSP re-uses web security mechanisms:TLS, basic & digest authenticationAny protocol can be used for transport
media and delivery protocol (see appendix)Each media stream within a presentation can reside on a different server
Both playback and recording control is possible
7
POSTECH DP&NM Lab
RTSP - States
• RTSP-Methods play a central role in the allocation and usage of streaming resources on the streaming server
8
POSTECH DP&NM Lab
RTSP Methods
Method Direction Requirement Description
DESCRIBE C->S recommended Get description of media object
ANNOUNCE C->S, S->C optional Change description of media object
GET_PARAMETER C->S, S->C optional
OPTION C->S, S->C required Get available methods
PAUSE C->S recommended Halt delivery, but keep state
PLAY C->S required Start playback
RECORED C->S optional Start recording
REDIRECT S->C optional Redirect client to new server
SETUP C->S required Establish transport
SET_PARAMETER C->S, S->C optional Device or encoding control
TEARDOWN C->S required Remove state
9
POSTECH DP&NM Lab
Methods - OPTIONS
• The OPTIONS method represents a request for information about the communication options available on the request/response chain
10
POSTECH DP&NM Lab
Methods - DESCRIBE
• The DESCRIBE method retrieves the description of a presentation or media object identified by the request URL from a server. The DESCRIBE reply-response pair constitutes the media initialization phase of RTSP.
• This description can be implemented using the SDP protocol
11
POSTECH DP&NM Lab
Methods - ANNOUNCE
• When sent from client to server, ANNOUNCE posts the description of a presentation or media object identified by the request URL to a server. When sent from server to client, ANNOUNCE updates the session description in real-time.
12
POSTECH DP&NM Lab
Methods - SETUP
• The SETUP request for a URI specifies the transport mechanism to be used for the streamed media
• The Transport header specifies the transport parameters acceptable to the client for data transmission; the response will contain the transport parameters selected by the server
13
POSTECH DP&NM Lab
Methods - 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
• The PLAY request positions the normal play time to the beginning of the range specified and delivers stream data until the end of the range is reached
Plays the whole presentation starting at SMPTE time code
0:10:20 until the end of the clip.
The playback is tart at 15:36 on 23 Jan 1997.
14
POSTECH DP&NM Lab
Methods - PAUSE• The PAUSE request
causes the stream delivery to be interrupted temporarily. If the request URL names a stream, only playback and recording of that stream is halted.
• If the request URL names a group of streams, delivery of all currently active streams within the group is halted
• After resuming playback or recording, synchronization of the tracks must be maintained
15
POSTECH DP&NM Lab
Methods - TEARDOWN
• The TEARDOWN request stops the stream delivery for the given URI, freeing the resources associated with it. If the URI is the presentation URI for this presentation, any RTSP session identifier associated with the session is no longer valid. Unless all transport parameters are defined by the session description, a SETUP request has to be issued before the session can be played again.
16
POSTECH DP&NM Lab
Methods – GET_PARAMETER
• The GET_PARAMATER request retrieves the value of a parameter of a presentation or stream specified in the URI. The content of the reply and response is left to the implementation
• GET_PARAMETER with no entity body may be used to test client or server liveness (“ping”)
17
POSTECH DP&NM Lab
Methods – SET_PARAMETER
• This method requests to set the value of a parameter for a presentation or stream specified by the URI.
18
POSTECH DP&NM Lab
Methods - REDIRECT
• A redirect request informs the client that it must connect to another server location. It contains the mandatory header Location, which indicates that the client should issue requests for that URL. It may contain the parameter Range, which indicates when the redirection takes effect.
• If the client wants to continue to send or receive media for this URI, the client MUST issue a TEARDOWN request for the current session and a SETUP for the new session at the designated host.
• Useful for implementing server load balancing
19
POSTECH DP&NM Lab
Methods - RECORD
• This method initiates recording a range of media data according to the presentation description. The timestamp reflects start and end time (UTC). If no time range is given, use the start or end time provided in the presentation description. If the session has already started, commence recording immediately.
20
POSTECH DP&NM Lab
ImplementationsClients Server
RealPlayer Quick Time Streaming Server
VideoLAN Darwin Streaming Server
Mplayer pvServer
Windows Media Player Helix Mobile Server
QuickTime Live555 Media server
MPEG4IP VLC
Skype Windows Media Services
VLC media Player Feng
More information
21
POSTECH DP&NM Lab
Problems of Current Protocol
• NAT Traversal problem
• The RTSP protocol says nothing about the problems of recovering state over machine or software failure (no detail of states transition and response)
• Quality problem
• Insufficient functionalities (Recording Function)
• No billing infrastructure: pay-per-play?
22
POSTECH DP&NM Lab
Recovering State over Machine
• State Machine
PAUSE
??
23
POSTECH DP&NM Lab
Recovering State over Machine
• One possible solution is that let the server ignore the wrong method requests
• Interoperability is the real problem
• RFC 2326 does not explain about actual request-response pair of state transition
• Details of state transition condition and response message type is required for interoperability
24
POSTECH DP&NM Lab
Status Code of RTSPCode Description
Code
Description
100 Continue 452 reserved
200 OK 453 Not Enough Bandwidth
300 Multiple Choices 454 Session Not Found
301 Moved Permanently 455 Method Not Valid in This State
302 Found 456 Header Field Not Valid for Resource
303 See Other 457 Invalid Range
304 Not Modified 458 Parameter Is Read-Only
305 Use Proxy 459 Aggregate operation not allowed
400 Bad Request 460 Only aggregate operation allowed
401 Unauthorized 461 Unsupported Transport
402 Payment Required 462 Destination Unreachable
403 Forbidden 463 Destination Prohibited
404 Not Found 464 Data Transport Not Ready Yet
405 Method Not Allowed 470 Connection Authorization Required
406 Not Acceptable 471 Connection Credentials not accepted
407 Proxy Authentication Required 500 Internal Server Error
408 Request Time-out 501 Not Implemented
410 Gone 502 Bad Gateway
411 Length Required 503 Service Unavailable
412 Precondition Failed 504 Gateway Time-out
413 Request Entity Too Large 505 RTSP Version not supported
451 Parameter Not Understood 551 Option not supported
25
POSTECH DP&NM Lab
State Transition Design
• None state machine changing events
Event Prerequisite Response
DESCRIBE Need REDIRECT 3rr, Redirect
DESCRIBE 200, Session description
OPTIONS Session ID 200, Reset session
OPTIONS 200,
SETPARAMETER Valid parameter 200, Change value of parameter
GETPARAMETER Valid parameter 200, Return value of parameter
26
POSTECH DP&NM Lab
State Transition Design
• Init State: Initial state no session exist
• NRM: The number of media streams part of this session• RP: Resume point
Action Requisite New State Response
SETUP Ready NRM=1, RP=0
SETUP Needs Redirect Init 3rr Redirect
S->C : REDIRECT No Session header InitTerminate all sessions
27
POSTECH DP&NM Lab
State Transition Design• Ready State: Session is ready to start playing (recording)
• Prs: Presentation, the complete multimedia presentation
Action RequisiteNew State
Response
SETUP New URI Ready NRM +=1
SETUP Setten up URI Ready Change transport param
TEARDOWN Prs URI Init No session hdr, NRM = 0
TEARDOWN media URI, NRM=1 Init No session hdr, NRM = 0
TEARDOWN media URI, NRM>1 Ready Session hdr, NRM -=1
PLAY Prs URI, No range Play Play from RP
PLAY Prs URI, Range Play According to range
PAUSE Prs URI Ready Return PP
S->C : REDIRECT Range Header Ready Set Redirection Point
S->C : REDIRECT No Range Header Init Session is removed
Timeout Init Redirection Point reached
Init TEARDOWN of Session
28
POSTECH DP&NM Lab
State Transition Design• Play State: Session is playing (sending media stream data)
Action Requisite New State Response
PAUSE Prs URI Ready Set RP to present point
PP reached Ready RP = PP
End of media All media Play Set RP = End of media
End of media Play Set RP = End of range
PLAY Prs URI, No range Play Play from present point
PLAY Prs URI, Range Play According to range
SETUP New URI Play 455 (method not valid)
SETUP Setuped URI Play 455
TEARDOWN Prs URI Init No session hdr
TEARDOWN media URI, NRM=1 Init No Session hdr, NRM=0
TEARDOWN media URI Play 455
S->C:REDIRECT Range hdr Play Set Redirection Point
S->C:REDIRECT no range hdr Init Session is removed
Redirection Point reached
Init TEARDOWN of session
Timeout Init Stop Media playout
29
POSTECH DP&NM Lab
Summary
• RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data
• This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels, and provide a means for choosing delivery mechanisms based upon RTP
• There’s no security vulnerability
• No details of state transition is available– State transition conditions and proper responses were proposed
30
POSTECH DP&NM Lab
Future Work
• Open source RTSP server/client implementation
• Interoperability check
31
POSTECH DP&NM Lab
Media Transport Alternatives
• RTP [RFC3550]• AVP [RFC3551] : Audio-Video Protocol
– RTP Profile for Audio and Video Conferences with Minimal Control
• AVP/UDP• AVPF/UDP [RFC4584]
– Extended RTP Profile for RTCP-based Feedback
• SAVP/UDP [RFC3711]– RTP Profile for Secure Real-time Transport Protocol (SRTP)
• SAVPF/UDP– Extended RTP Profile for RTCP-based Feedback
• RTP over TCP
32
POSTECH DP&NM Lab
Question?
?