Catra Streaming Platform
(ISMA and 3GPP streaming, off-line and
live)
(on sourceforge)
1 Overview of Catra Streaming Platform (CSP)
The Catra Streaming Platform includes an open, extensible multimedia streaming server, a GUI to handle all the servers distributed in sites and some MP4 tools to handle the media files.
The Catra Streaming Platform is easy to install and manage, allowing customers to focus on creating and providing value-added content and services to their users.
Unfortunately, there are players (Real and Windows Media) that can only play certain types of proprietary streams. These players require servers that stream these proprietary formats to them. CSP does not interoperate with these proprietary clients or formats.
Here is an article about the Catra Streaming Platform published by the ‘Red Hat Magazine’ in March 2004.
For any questions/bugs/messages, please use the Public Forum inside the sourceforge site.
This project is looking for Developers. Here is a list of job positions available for it:
· Implementation of the new 3GPP Release 6 Specification
· Implementation of an algorithm to adapt the stream to the available bandwidth
· Implementation of the streaming of new codecs according the ISMA and 3GPP standard
1 Interoperability
1.1 Players compliant
The Catra Streaming Server is a streaming server compliant with 3GPP and ISMA standards and is able to interoperate with any standards-based media players.
The Catra Streaming Server, actually, has been tested with the following players:
·
Philips
ISMA and 3GPP player
· Any 3GPP player installed in the current commercialized UMTS phones
Remark: The Catra Streaming Server uses the extension of the clip to select the standard to be used (ISMA or 3GPP).
The Catra Streaming Server selects:
· 3GPP for the ‘.3gp’ extension
· ISMA for the ‘.mp4’ extension
Basically, if we are sending a streaming request from an ISMA player, the RTSP URL must refer to a ‘.mp4’ clip:
rtsp://<IP address>/<file name>.mp4
if we are sending a streaming request from a 3GPP player, the RTSP URL must refer to a ‘.3gp’ clip:
rtsp:// <IP address>/<file
name>.3gp
Since the syntax of the file format for both the standards ISMA and 3GPP is the same, the file could be also the same and just renamed according the standard to be applied.
1.2 Terminals compliant
The Catra Streaming Server is a streaming server compliant with 3GPP standards and is able to interoperate with any standards-based media players.
The Catra Streaming Server, actually, has been tested with the following terminals:
· Motorola A925
· Motorola A1000
· Motorola E1000
· Motorola A835
· LG 8130
· LG 8138
· Sony Ericsson Z1010
· NEC e616V
· NEC e338
1.3 Live encoders compliant
The Catra Streaming Server is compliant with any live encoder able to push RTP packets for audio and video. In this case the Catra Streaming Server will receive an RTSP request referring a SDP file including all the information about the live session.
Generally the SDP file is generated by the live encoder itself but can be also written manually.
Actually, the Catra Streaming Server has been tested with the following live encoders:
·
Helix
· Nextreaming live encoder
· Popwire Live engine 2.0 and 3.0
· Popwire Broadcaster (Mac) 1.0
· mp4live encoder from the MPEG4IP open project
· Mpegable Broadcaster encoder
Remark: In case of live request, the extension of the SDP file must be “.sdp” because the Catra Streaming Server uses the extension of the file to understand if it receives a live request. The RTSP request should be something like:
rtsp:// <IP address>/<SDP file name>.sdp
1.4 Off-line encoders compliant
The Catra Streaming Server is compliant with any off-line encoder generating 3GPP or ISMA file.
Actually, the Catra Streaming Server has been tested with the MP4 file generated by the following off-line encoders:
· Quicktime
· Philips Platform IV
· Nextreaming
· ffmpeg
·
Helix
2 Technical specifications
2.1 High level architecture
The Catra Streaming Server is based completely upon standards and open architectures. It relies on numerous Internet and 3GPP standard protocols such as RTSP, RTP/RTCP, SDP. These standards are described in the Streaming technology background paragraph.
When the Catra Streaming Server (CSS) is launched, it reads a configuration file to obtain numerous configuration parameters including the location of the media files and log files. It starts the Streaming Servers Manager process and a number of streaming server processes according the ServersNumber configuration parameter. The Streaming Servers Manager is a software load balancer for the streaming servers. It choices the best streaming server to handle a request. It also handles the communication with the Catra Streaming GUI. The player application initiates a streaming session with the server by giving the RTSP URL of a piece of content to stream. The player connects to the server over TCP/IP and then requests and controls the media stream through RTSP methods, such as SETUP and PLAY and PAUSE. While streaming, the server and client communicate periodically through RTCP, updating each other with statistics about the streaming session. Also during streaming, the Catra Streaming Server will update request and connection log files with information regarding RTSP requests and network connections that are being handled. It also manages the log files, ensuring proper sizing and rotation. When the streaming session is over, the client disconnects from CSS or alternatively, CSS will disconnect after a configured time-out period.
The Catra Streaming Server uses the following protocols:
· RTSP to control presentation sessions with commands such as PLAY and PAUSE.
· SDP to give clients information about a requested piece of media
· RTP to deliver actual stream data to clients, regardless of the client type or media encoding
· RTCP to communicate and monitor individual stream information between clients and servers
The Catra Streaming GUI is a java applet, it takes in input a configuration file where it finds all the information about the sites and the Catra Streaming Servers. The Catra Streaming GUI communicates with the servers using CORBA.
The Catra Streaming Server and the Web Server can also reside in the same machine.
The below diagram describes the Catra Streaming Platform Overall Architecture:
2.2 Catra Streaming Server
The Catra Streaming Server can deliver stored content to any open standards RTSP/RTP clients.
Catra Streaming Server accepts the following audio codecs: AAC, GSMAMR, AMR-WB.
The video codecs accepted are: MPEG-4 and H263.
Catra Streaming Server is compliant with the following standards:
· 3GPP TS 26.234 – PSS Protocols and codecs (Release 5)
· rfc2326: Real-Time Streaming Protocol (RTSP)
·
rfc2327:
Session Description Protocol (SDP)
· rfc1889: A Transport Protocol for Real-Time Applications (RTP)
· rfc2429: RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
· rfc3016: RTP Payload Format for MPEG-4 Audio/Visual Streams
· rfc3267: Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
· rfcisma
Specific technical features of Catra Streaming Server are:
· Streaming of both off-line and live request
· Use of a configurable cache to prefetch the RTP packets.
· Use of a configurable cache for the content.
· Handle of three timeouts
o RTSP and RTCP timeout to avoid maintaining active a RTSP session when it does not receive any RTSP command and RTCP packets
o PAUSE timeout to avoid maintaining active a RTSP session when it remains in PAUSE for a long time.
o Session timeout in order to drop the streaming session after a specified period of time
· Ability to configure the interval between two RTCP sender report packets.
· Ability to distribute the RTSP, RTP and RTCP traffic on different network cards.
· Generation of log files ensuring proper sizing, rotation and trace levels through configurable parameters.
General technical features of the Catra Streaming Platform are:
·
· C++ the language used to implement the server
· CORBA used for the communication between Server and GUI. MICO (MICO Is CORBA: free available and fully compliant implementation of the CORBA standard) is used by Catra Streaming Server.
· Use of the catralibraries (including the MP4File library)
The figure 1.1 shows the Philips player during a streaming session.
Figure 1.1
2.3 Catra Streaming GUI
The GUI is a centralized place where to handle all the servers distributed in sites. It is written in Java and communicates with the streaming servers by CORBA. JacORB, the free Java implementation of the OMG's CORBA standard, is used.
The main functionalities of the GUI are:
· configuration of the system
· content management
· monitoring
· reporting
· logging viewer
Specific technical features of the Catra Streaming GUI are:
· Configuration functionalities
o Ability to handle the configuration of each Catra Streaming Server
o Ability to handle the configuration of each site containing the Catra Streaming Servers
o Ability to propagate a change in a server for all the servers inside the same site
o Ability to propagate a change in a server for all the servers
· Content functionalities
o Management of the content root path to create and delete directories and to add and delete content
o Ability to run the MP4 tools (mp4Dump, mp4TracksInfo, mp4CreateHintTracks, …) on the MP4 files contained in the content root path
· Monitor functionalities
o Ability to monitor all the requests in all the Catra Streaming Server
o Ability to monitor all the requests in all the Catra Streaming Server of a specific site
o Ability to monitor the requests in a specific Catra Streaming Server
· Report functionalities
The figure 1.2
describes the configuration of the system. The sites, servers and their
configuration is described by a tree structure. Every site includes a set of
streaming servers and every streaming server contains his configuration. The
figure 1.2, you can find the ‘Piazza Fiera’ streaming server with his
configuration inside the ‘
Figure 1.2
The figure 1.3 describes the system monitoring window. On the left you can see the same site and streaming server of the previous configuration system window. From this window you can monitor information like memory and CPU usage, the connected users, the bandwidth used, and so on.
Figure 1.3
2.4 MP4/3GPP tools
This section describes the MP4 tools included in the Catra Streaming Platform:
· mp4FileDump – It writes on the standard output the structure of a MP4 file describing all the atoms and the relative attributes (example of this dump).
· mp4TracksInfo – It analyzes each track inside the MP4 file and produces:
o a textual file with all the information about each track and the samples that compose the track (example of this file)
o a separate file for each track with the relative payload
· mp4Player – It implements the behavior of a 3GPP player but it does not render the tracks. It can be used to test the performance of a server, in fact the main functionalities of this tool are:
o implement the RTSP and RTP communication with the streaming server
o handle multiple requests to the server
o save the received RTP packets creating a file for each track
o create a statistics file to be used to generate graphics
· mp4CreateHintTracks – It adds the hint tracks to a MP4 file
· mp4AddAtom – It adds an atom to a MP4 file
· mp4DeleteAtom – It deletes an atom to a MP4 file
2.5 Streaming library
Streaming Libraries are the core library of the Catra Streaming Server. Follow the link if you want a detailed description about it or if you want to download and use it.
3 Platform configuration
The Catra Streaming Platform is configured via the following files:
· GUIConfiguration.xml (example of this file)
· GUIContent.xml (example of this file)
· GUIMonitor.xml (example of this file)
· CatraStreamingServer.cfg (example of this file)
The first three files are used by the Catra Streaming GUI and reside in the Web Server machine. They do not need any changes because they are handled by the Catra Streaming GUI itself.
The CatraStreamingServer.cfg configuration file is also handled by the Catra Streaming GUI and but in any case you can change it with a textual editor. In this case the GUI will update itself to the new configuration automatically when it starts.
It resides in the Catra Streaming Server machine and must be changed using a textual editor in case you do not have installed the Catra Streaming GUI.
4 Download
4.1 Catra Streaming Platform
Refer to sourceforge to download the Catra Streaming Platform.
4.1.1 Documentation
· Catra Streaming Platform Manual (draft)
· Refer the doc directory inside the package to have more information
· Refer the doc/API directory inside the package to have all the API of the implementation of the platform (both in html and in latex format)
4.2 3GPP samples
This paragraph provides a lot of samples to be downloaded and tested with the Catra Streaming Platform.
4.2.1 Audio only
· 01_AAC_BR_32000_VID_Trailer1.3gp
o Audio codec: AAC
o Audio bit rate: 32Kbps
o Does not include hint tracks
· 01_AAC_BR_32000_VID_Trailer1_Hinted.3gp
o Audio codec: AAC
o Audio bit rate: 32Kbps
o Include hint tracks
· 02_GSMAMR_BR_32000_VID_Trailer1.3gp
o Audio codec: GSMAMR
o Audio bit rate: 32Kbps
o Does not include hint tracks
· 02_GSMAMR_BR_32000_VID_Trailer1_Hinted.3gp
o Audio codec: GSMAMR
o Audio bit rate: 32Kbps
o Include hint tracks
· 03_WBAMR_BR_32000_VID_Trailer1.3gp
o Audio codec: WBAMR
o Audio bit rate: 32Kbps
o Does not include hint tracks
· 03_WBAMR_BR_32000_VID_Trailer1_Hinted.3gp
o Audio codec: WBAMR
o Audio bit rate: 32Kbps
o Include hint tracks
o Audio codec: GSMAMR
o Audio bit rate: 8Kbps
o Does not include hint tracks
4.2.2 Video only
· 04_H263_BR_64000_FR_3_VID_Trailer1.3gp
o Video codec: H263
o Video bit rate: 64Kbps
o Video frame rate: 3
o Does not include hint tracks
· 04_H263_BR_64000_FR_3_VID_Trailer1_Hinted.3gp
o Video codec: H263
o Video bit rate: 64Kbps
o Video frame rate: 3
o Include hint tracks
· 05_MP4_BR_64000_FR_3_VID_Trailer1.3gp
o Video codec: MPEG-4
o Video bit rate: 64Kbps
o Video frame rate: 3
o Does not include hint tracks
· 05_MP4_BR_64000_FR_3_VID_Trailer1_Hinted.3gp
o Video codec: MPEG-4
o Video bit rate: 64Kbps
o Video frame rate: 3
o Include hint tracks
· 13_H263_BR_48000_FR_15_VID.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 15
o Does not include hint tracks
4.2.3 Audio & Video
· 06_H263_BR_48000_FR_3_AAC_BR_16000_VID_Trailer1.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: AAC
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 06_H263_BR_48000_FR_3_AAC_BR_16000_VID_Trailer1_Hinted.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: AAC
o Audio bit rate: 16Kbps
o Include hint tracks
· 07_H263_BR_48000_FR_3_GSMAMR_BR_16000_VID_Trailer1.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: GSMAMR
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 07_H263_BR_48000_FR_3_GSMAMR_BR_16000_VID_Trailer1_Hinted.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: GSMAMR
o Audio bit rate: 16Kbps
o Include hint tracks
· 08_H263_BR_48000_FR_3_WBAMR_BR_16000_VID_Trailer1.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: WBAMR
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 08_H263_BR_48000_FR_3_WBAMR_BR_16000_VID_Trailer1.3gp
o Video codec: H263
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: WBAMR
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 09_MP4_BR_48000_FR_3_AAC_BR_16000_VID_Trailer1.3gp
o Video codec: MPEG-4
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: AAC
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 09_MP4_BR_48000_FR_3_AAC_BR_16000_VID_Trailer1_Hinted.3gp
o Video codec: MPEG-4
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: AAC
o Audio bit rate: 16Kbps
o Include hint tracks
· 10_MP4_BR_48000_FR_3_AMR_BR_16000_VID_Trailer1.3gp
o Video codec: MPEG-4
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: AMR
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 10_MP4_BR_48000_FR_3_AMR_BR_16000_VID_Trailer1_Hinted.3gp
o Video codec: MPEG-4
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: AMR
o Audio bit rate: 16Kbps
o Include hint tracks
· 11_MP4_BR_48000_FR_3_WBAMR_BR_16000_VID_Trailer1.3gp
o Video codec: MPEG-4
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: WBAMR
o Audio bit rate: 16Kbps
o Does not include hint tracks
· 11_MP4_BR_48000_FR_3_WBAMR_BR_16000_VID_Trailer1_Hinted.3gp
o Video codec: MPEG-4
o Video bit rate: 48Kbps
o Video frame rate: 3
o Audio codec: WBAMR
o Audio bit rate: 16Kbps
o Include hint tracks
· 12_MP4_BR_42000_FR_8_3_GSMAMR_BR_8000_VID_TomJerry.3gp
o Video codec: MPEG-4
o Video bit rate: 42Kbps
o Video frame rate: 8.3
o Audio codec: GSMAMR
o Audio bit rate: 8Kbps
o Does not include hint tracks
5 Installing & Running
See the Readme file inside the catrastreaming package and the ‘Installation’, ‘Configuration’ and ‘Operations’ chapters of the Catra Streaming Platform Manual to know how to install, configure and run the CatraStreaming Platform.
6 Changes history
Refer to the ChangeLog file inside the package.
7 New features to implement
This paragraph describes all the features that will be implemented in the next releases of the Catra Streaming Platform.
The next releases will implement the following features:
· Catra Streaming Server
o Implement some command line tools to monitor the platform. The goal of this tools is to implement almost the same functionalities realized by the Catra Streaming GUI but just with some command line tools.
o Change of the configuration parameters, through the Catra Streaming GUI, without stopping the processes. Currently, the configuration parameters changed through the Catra Streaming GUI, needs a restart of the processes to become active
o Introduce the concept of the ‘alias’ for a content or a URL in order to hide the real URL to the player
o Specify in the configuration files the content that do not need to be cached
o Implementation of an algorithm to adapt the stream to the available bandwidth
o …
· Tools
o muxer and de-muxer to join or to split tracks in a MP4 file
· Catra Streaming GUI
o Implementation of the windows for reports and log functionalities
o Implementation the concept of user and group
8 Streaming technology background
The Streaming Server serves digital media somewhat analogous to how a web server serves web pages. It breaks digital media files into packets and sends them to the client. The client reassembles (or reconstructs) the packets and presents the media as the packets are received.
8.1 What is File-Based Streaming?
The Streaming Server software supports the streaming of MP4 files that are available to the server to a local or network file system. The client can send a request to the Streaming Server to stream a file by given the URL of the file through appropriate RTSP requests such as SETUP and PLAY. Since a MP4 file can have multiple tracks, the client must request each track separately (this is done by client programs by issuing a separate SETUP command for each track. The user only need to know the name of the file). When a client makes a request to stream a file, the server identifies the file by using the ‘ContentRootPath’ parameter of the configuration file. It parses the identified file to obtain information for each of the tracks that is to be streamed. For each track in the file, the server reads data data from the file system and sends a stream of RTP packet to the client. Also for each track, the server communicates regularly with the client by sending and receiving RTCP packets describing the quality of the stream. The RTP stream lasts for the duration of the media, unless the client interrupts the stream with a PAUSE or TEARDOWN request. The RTCP communication ceases when the client issues a TEARDOWN request.
The below diagram describes the File-Based Streaming:
In the above diagram, the MP4 files are loaded into the Streaming Server. When a client makes a request, the server established a one-to-one RTSP connection with each client. After establishing the ports to use for RTP and RTCP data transfer, the server composes RTP packets from the media file data and sends the packets over to the client-specific port. The server also sends an RTCP sender report to the client. The client reconstructs media data from the RTP packets and sends periodic RTCP receiver reports back to the server.
8.2 Real-Time Transport Protocol (RTP)
The Streaming Server uses the RTP protocol to deliver media streams to the clients.
Using the track information of a MP4 file, the Streaming Server breaks up the media data of each track into RTP packets. The Streaming Server then transmits the RTP packets to the client over an UDP socket.
Each RTP packet transmitted by the server includes the following information:
· RTP header
· RTP payload header
· RTP payload data
The RTP header, among other things, includes:
· RTP version information
· Sequence number
· Timestamp
· Synchronization Source Identifier (SSRC)
The server uses the RTP version 2. The sequence number for the initial packet of a RTP session is generated randomly by the server. Each consecutive packet then containing a monotonically increasing sequence number. Sequence numbers are important parts of the RTP packets because they allow the clients to deal properly with out-of-order as well as lost packets in the sequence. Each packet contains time stamp that indicates the time of the packet data within a movie. The server also generates and adds a random offset to the RTP timestamp of each packet.
The SSRC is randomly generated by the server and is included in each RTP packet that is being streamed. The SSRC uniquely identifies the server as the originator of the packet.
The RTP payload header and data are obtained for the MP4 file and are appended to the packet.
While initiating an RTP session, the server ensures that two ports are established for each RTP stream (one for RTP and one for RTCP). The RTP port always has an even port number and the RTCP port has the next higher odd port number. For example, 13240 and 13241.
The server constructs and sends RTP packets as they come due over the duration of a presentation. To improve the quality of the stream, the server prefetches and buffers ahead a configurable amount of RTP data.
When all the data for a track has been streamed, the server pauses the RTP stream waiting for the RTSP session to timeout before cleaning up the RTP streams.
8.3 Real-Time Transport Control Protocol (RTCP)
The Streaming Server uses RTCP (Real-Time Control Protocol) to communicate individual stream information between clients and servers.
For file-based streaming
· RTCP sender reports (from the server) provide clients with quality and per stream information (such as information for intra and inter stream synchronization).
· RTCP receiver reports (from the clients) provide feedback on quality of reception from the client perspective, which the server may use to improve stream quality. The server maintains active RTCP communication with the clients that requested the streams. The server sends RTCP sender reports and receives RTCP receiver reports.
8.4 Real-Time Streaming Protocol (RTSP)
The Streaming Server accepts Real-Time Streaming Protocol (RTSP) requests over a TCP socket. The control of the transfer of media involves several different RTSP requests. The Streaming Server uses RTSP requests such as DESCRIBE, OPTIONS, SETUP, PAUSE, PLAY, and TEARDOWN to enable clients communicate data transfer information and request new RTP sessions for various pieces of media.
When a client makes a request for streaming, an RTSP connection over TCP is established between the client and the server. An RTSP session is created and manipulated using the RTSP connection.
By default, the server listens for RTSP connections on TCP port 554. This is reconfigurable.
When a new RTSP connection is made, the server ensures that configurable connection limits have not been exceeded. The server accepts the new RTSP connection and listens for RTSP requests.
The following is a list of requests between the server and the client for streaming:
· OPTIONS – The server responds with the list of commands currently supported by the server. These commands are OPTIONS, DESCRIBE, SETUP, PLAY, and TEARDOWN.
· DESCRIBE – The server parses the file referred to by the given URL and responds to the DESCRIBE request with information about the media to be described. This information will be presented through SDP, which is contained within the response to the RTSP DESCRIBE.
· SETUP – The client identifies which tracks of the media in question it wants to receive (each track would typically correspond to a different form of media, e.g., video, audio, and so on). The server first attempts to tie the request to an existing RTSP session. Otherwise, it creates a new RTSP session with a unique session ID. It then proceeds to some initialization necessary for streaming the track. Finally, it returns the status of the SETUP operation as success or failure, along with the session ID if the operation was successful.
· PLAY – This request actually begins transferring the data for each of the tracks specified by the client in the preceding SETUP request. The server prefetches a configurable amount of RTP data for each track in the current RTSP session. It then starts streaming each of the tracks as separate RTP stream and returns an RTSP response that include the sequence number and timestamps of the initial packet of each RTP stream.
· PAUSE – This request tell the server to stop transferring the data for streaming temporary, but it still keeps the session alive so that play back may resume in the future.
· TEADOWN – This request ends streaming a particular movie. The server halts all the RTP streams and cleans up the RTP and RTSP sessions for the given session ID. Once a client issues a PLAY request, data is delivered to the client on a set of UDP sockets (typically a different socket for each track) via RTP (Real-Time Transport Protocol). Each RTP socket is paired with an RTCP (Real-Time Transport Control Protocol) that the server uses to send periodic sender status reports to the client, and that the client uses to send receiver status reports back to the server.
To stream a specific presentation, the following steps of interactions typically occur between the client and the server:
1. A Real-Time Streaming Protocol (RTSP) connection over TCP is established
2. The client makes the RTSP DESCRIBE request and the server responds with Session Description Protocol (SDP). This information describes the content and tracks available in the presentation.
3. The client makes an RTSP SETUP request for each track that it wants streamed. The server then initiates an RTP session for each track and sets up one RTP and one RTCP (Real-Time Transport Control Protocol) port for each track that is to be streamed.
4. The client then controls the presentation by using the PLAY, PAUSE, or TEARDOWN commands. When the client issues
· PLAY, the server starts sending the RTP packets and RTCP sender reports.
· PAUSE, the server stops sending RTP packets but continues sending RTCP reports.
· TEARDOWN, the server stops all RTP and RTCP transactions, cleans up the RTP session, and then closes its connection with the client.
8.5 Session Description Protocol (SDP)
The Streaming Server uses Session Description Protocol (SDP) to provide information to clients about a requested piece of media, such as content encoding, length, availability, transport. When the client makes an RTSP DESCRIBE request, the server constructs and transmits SDP information for data in the media file and returns this information as the response to the DESCRIBE command. This information enables the client to know the contents to the presentation. For example, the SDP information tells the clients the number of tracks that are available for streaming. The client can use this information and request for a specific track.
Typically, SDP provides the following information to clients:
· Session name and purpose if the requested session has already been setup.
· Description of the presentation.
· Media such as type format and codecs that comprise the presentation.
· Network information (such as address, ports, transport protocol, remote address for media) for receiving the media
· Information about the bandwidth to be used for the session
· Information on all the tracks available for streaming
8.6 What are Hint Tracks?
A specific type of track inside the MP4 file can be the hint track. The Catra Streaming Server does not need that the file contains the hint track to perform the streaming. In any case the Catra Streaming Server uses the hint tracks in case it finds them into the file. Hint track are data about the media that tell the Catra Streaming Server how to stream the media. For example, the hint track indicates that for a given time in a movie, the associated RTP data is at a certain location within the file. The Catra Streaming Server then finds the data at that location, puts the data into RTP packets, and then streams the packets. This enables the server to be codec independent because it does not have to know the characteristic of the data. That is, the Catra Streaming Server will stream content encoded in any codec as long as a valid hint track is available for that type of codec.