1

POSTECH DP&NM Lab

Extending Real-time Streaming Protocol for Interoperability

Byungchul Park

DPNM Lab., CSE, POSTECH

Email: fates@postech.ac.kr

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?

?