Project Specifications for

CS400 Advance Windows Network Programming

School of Computing, Communication University of China
December 14, 2011. Due February 13, 2012
Tools and Platform
The following tools and platforms are to be used in the projects:
Operating System: Microsoft Windows
Language: C++
Development Tools: Microsoft Visual Studio 2008/2010
Winsock 2.2
Project 10 RTSP Windows Client: RFC 2326
A. Overview
1. Introduction of RTSP
The Real Time Streaming Protocol (RTSP, RFC 2326) is a network control 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.
Clients of media servers issue VCR-like commands, such as play and pause, to facilitate real-time
control of playback of media files from the server.
The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP
servers use the Real-time Transport Protocol (RTP, RFC 3550, 3551) for media stream delivery;
however some vendors implement proprietary transport protocols.
While similar in some ways to HTTP, RTSP defines control sequences useful in controlling
multimedia playback. While HTTP is stateless, RTSP has state; an identifier is used when needed
to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection
and, while most RTSP control messages are sent by the client to the server, some commands
travel in the other direction (i.e. from server to client).
Presented here are the basic RTSP requests. Some typical HTTP requests, like the
OPTIONS request, are also available. The default transport layer port number is 554.
OPTIONS
An OPTIONS request returns the request types the server will accept.
DESCRIBE
A DESCRIBE request includes an RTSP URL (rtsp://...), and the type of reply data
that can be handled. The default port for the RTSP protocol is 554 for both UDP and TCP
transports. This reply includes the presentation description, typically in Session Description
Protocol (SDP) format. Among other things, the presentation description lists the media
streams controlled with the aggregate URL. In the typical case, there is one media stream
each for audio and video.
SETUP
A SETUP request specifies how a single media stream must be transported. This must
be done before a PLAY request is sent. The request contains the media stream URL and a
transport specifier. This specifier typically includes a local port for receiving RTP data (audio
or video), and another for RTCP data (meta information). The server reply usually confirms
the chosen parameters, and fills in the missing parts, such as the server's chosen ports. Each
media stream must be configured using SETUP before an aggregate play request may be
sent.
PLAY
A PLAY request will cause one or all media streams to be played. Play requests can be
stacked by sending multiple PLAY requests. The URL may be the aggregate URL (to play all
media streams), or a single media stream URL (to play only that stream). A range can be
specified. If no range is specified, the stream is played from the beginning and plays to the
end, or, if the stream is paused, it is resumed at the point it was paused.
PAUSE
A PAUSE request temporarily halts one or all media streams, so it can later be resumed
with a PLAY request. The request contains an aggregate or media stream URL. A range
parameter on a PAUSE request specifies when to pause. When the range parameter is
omitted, the pause occurs immediately and indefinitely.
TEARDOWN
A TEARDOWN request is used to terminate the session. It stops all media streams
and frees all session related data on the server.

2. Introduction of LIVE555
We will use LIVE555 as the streaming server for testing your RTSP Windows client player.
LIVE555 is an open source (LGPL) C++ library for multimedia streaming. This code
forms a set of C++ libraries for multimedia streaming, using open standard protocols
(RTP/RTCP, RTSP, SIP). The libraries are already being used to implement applications such as
"the LIVE555 Media Server" (a RTSP server application), "liveCaster" and "playRTPMPEG"
(for streaming MP3 audio using RTP/RTCP), and "vobStreamer" (for streaming DVD content
using RTP/RTCP/RTSP). The libraries can also be used to stream, receive, and process MPEG,
H.264, H.263+, DV or JPEG video, and several audio codecs. They can easily be extended to
support additional (audio and/or video) codecs, and can also be used to build basic RTSP or SIP
clients and servers, and have been used to add streaming support to existing media player
applications, such as "VLC" and "MPlayer".

B. Specification
Your assignment is to write an RTSP Client which should work with LIVE555 Media Server.
Your implementation should follow the specification in the Real Time Streaming
Protocol (RTSP, RFC 2326), so that your version of RTSP Client is able to work
together with the LIVE555 MediaServer.
Your implementation may use JRDPLIB to handle received RTP packets at the
client side (you can also refer to a programming instruction in Chinese) or just use
a tiny RTP library introduced by http://70565912.blog.51cto.com. The JRDPLIB
is an open-source project for packetizing/de-packetizing video/audio data over
RTP. (The JRTPLIB has routines for RTCP, but RTCP is not needed in your
implementation because you are not required to encode/decode the audio/video
stream data dynamically.)
The example version RTSP Client (openRTSP) is a linux command-line program
that can be used to open, stream, receive, and (optionally) record media streams
that are specified by a RTSP URL - i.e., an URL that begins with rtsp://. Your
newly developed application should be a MFC application on Windows
platform, but you are free to choose any mechanisms for socket I/O
multiplexing (Blocking with Multi-threading, the select() system call, asynchronous
programming with WSAAsyncSelect or any other models). It is important that
you should implement the RTSP client to be independent of the LIVE555
libraries.
Your RTSP Client can accomplish basic and advanced functions:
I. Basic function: Visit the on-demand file stream from the
Live555MediaServer with URL:rtsp://127.0.0.1:8554/mp3AudioTest
(Windows version) or rtsp://127.0.0.1:554/test.mp3 (Linux version).
The file test.mp3 will be ready for your RTSP request. The basic task of
your RTSP Client is that it can record the steam as a local media file.
II. Advanced function: The advanced task of your RTSP Client is that it can
play the media file (mp3 only) from the on-demand streaming server. You
can do this by taking advantage of the Windows Media Player Control.
(you can refer to Using the Windows Media Player Control in Visual
C++ 2008 )
Implementations that do not use Object-Oriented Programming will not be
accepted. That also means it is not acceptable to write this project in a single
function (or even just a couple of functions).

Notes:
You can download the live555 on the course website. There are two versions (Linux and
Windows), both include source and executable files. You can use the source code to analyze the RTSP
protocol, and run the executable file to test your client.

If you choose the Linux version, you can find the server (live555MediaServer) under
live/mediaServer/, and if you choose the Windows version, you can find the server (server.exe)
under live/bin/.

And you can use live/testProgs/testMp3Receiver.cpp as the demo of the client. But a more
sophisticated version of multimedia player, "VLC" can be used for a clear demonstration.
1) Download and setup VLC.
2) Open the Open Media Dialog by click menu [Media] -> [Open Network Stream]




3) In the blank, type rtsp://cloud.cuc.edu.cn/test.mp3 for a test run.








C. Grading
Your project will be tested to make sure it works properly with the live555 media server.
Here is a rough breakdown of the grading:
Basic function goes well 50%
Advanced function goes well 20%
Dealing with impolite requests, unexpected messages 10%
Error handling, Style/Code structure, etc. 20%
Extra credits:
Well defined project report +5 p
Elegant GUI interface +5 p
Note: 20% of your project grade depends on the how "well your code is written". These points
include the following:
Error handling (check every system call for an error!).
Safe code (avoiding buffer overflow, etc).
How well we can understand your code. There is no required format for your code; there is
no requirement like "you must have one comment for every 2.35 lines of code". Feel free to
provide whatever level of commenting you believe is appropriate to make sure that other
competent programmers could easily understand and make changes to your code.

Note:
All functions will be tested on different machines.
Submissions that do not use Object Oriented Programming with C++will not
be accepted.
If the submitted source code cannot be compiled by Visual Studio 2008/2010,
your grade will be deducted.
Late submission will be punished with grade deductions.