Extending Real-time Streaming Protocol for Interoperability

1. Extending Real-time Streaming Protocol for Interoperability Byungchul Park DPNM Lab., CSE, POSTECH Email: fates@postech.ac.kr 2008. 6. 24

2. 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. 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. RTSP Overview (2/2) • RTSP client sets up three network channels with RTSP server Control & negotiation Media data delivery Synchronization & QoS Info.

5. 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. New methods and parameters can be easily added to RTSP Properties of RTSP RTSP can be parsed by standard HTTP parsers RTSP re-uses web security mechanisms: TLS, basic & digest authentication Any protocol can be used for transport media and delivery protocol (see appendix) • 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 Each media stream within a presentation can reside on a different server Both playback and recording control is possible

7. RTSP - States • RTSP-Methods play a central role in the allocation and usage of streaming resources on the streaming server

8. RTSP Methods

9. Methods - OPTIONS • The OPTIONS method represents a request for information about the communication options available on the request/response chain

10. 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. 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. 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. Methods - PLAY 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. • 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

14. 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. 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. 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. Methods – SET_PARAMETER • This method requests to set the value of a parameter for a presentation or stream specified by the URI.

18. 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. 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. Implementations More information

21. 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. Recovering State over Machine • State Machine ?? PAUSE

23. 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. Status Code of RTSP

25. State Transition Design • None state machine changing events

26. State Transition Design • Init State: Initial state no session exist • NRM: The number of media streams part of this session • RP: Resume point

27. State Transition Design • Ready State: Session is ready to start playing (recording) • Prs: Presentation, the complete multimedia presentation

28. State Transition Design • Play State: Session is playing (sending media stream data)

29. 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. Future Work • Open source RTSP server/client implementation • Interoperability check

31. 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. Question? ?