Managing streaming protocols on your network can be a problem. You do not want your users to consume bandwidth watching replays from last night's game, but you know that an increasing number of useful applications also rely on these same protocols. To monitor activity on your network and detect undesired activity, you need to understand which protocols are used to deliver streaming media.
 |
| Too busy to read? |
| Listen to this tip in MP3 format, and find more podcasts on our Networking Audiocast page. |
|
|
|
|
Most streaming media on the Web is available via Real Networks' RealPlayer, Apple QuickTime or Microsoft Media Player. Each application relies on multiple protocols to deliver the data packets and control the flow of data. Some of these protocols have been developed by the Internet Engineering Task Force (IETF), and specifications are publicly available. Other protocols are proprietary.
How protocols deliver streaming media
The Real-time Streaming Protocol (RTSP), Real-time Transport Protocol (RTP) and the Real-time Transport Control Protocol (RTCP) are used by several streaming applications. These protocols were developed by the IETF.
RTSP, defined by RFC 2326, controls the flow of audio or video data. It can be used to control access to both multicast and unicast streams. RTSP provides a set of commands that resemble the controls on a VCR. These commands include "play," "pause" and "teardown," which is equivalent to "stop." RTSP can run over either TCP or UDP. Its default port is 554.
When RTSP runs over TCP, it does not maintain a TCP connection for the duration of the stream. A client application may initiate and terminate many TCP connections over the course of a single session. To maintain a session between the client and server, RTSP uses a session identifier to specify the stream to which a command applies. The session identifier remains constant over the duration of the stream. The session identifier is used in the same way when RTSP runs over UDP.
RTSP is not used to carry the actual data packets that make up the audio or video stream. Instead, the "setup" command specifies which transport protocol will carry the stream. In many cases, RTP and its companion protocol RTCP are the transport protocols chosen.
RTP and RTCP are both defined by RFC 3550. RTP carries the data packets; RTCP provides feedback from the client to the server concerning the number of packets lost, round trip delay, and variations in the arrival rate of packets.
RTP and RTCP can run over TCP or any other transport layer protocol, but UDP is generally used. The delivery guarantees provided by TCP are not needed by audio and video streams. RTP and RTCP do not have default port numbers. The port numbers used by a session usually range from 16,384 to 32,767. RTP will use an even-numbered port in this range, and RTCP will use the next odd-numbered port.
The port numbers to use for a given stream are determined by RTSP when it initiates the session. For a unicast session, client RTSP specifies to the server the set of port numbers to use. For a multicast session, all of the participants must use the same ports, so RTSP on the server specifies the port numbers to the client.
Streaming applications and the protocols they prefer
Real Networks' RealPlayer uses RTSP to set up sessions. Earlier RealPlayer versions used a proprietary protocol called PNA for this function. The default port number for PNA is 1090. RealPlayer can use RTP and RTCP to carry stream data but can also use the proprietary RDT transport protocol. When using RTP and RTCP, and when using RDT, the RealPlayer application will attempt to use UDP, but will switch to TCP if UDP is blocked.
Apple uses only IETF protocols to implement QuickTime. RTSP is used to set up sessions, and RTP and RTCP carry the data.
Microsoft uses RTSP along with RTP and RTCP in its most recent releases of Media Player. Versions released prior to Windows XP Service Pack 2 used MSB, a proprietary protocol.
MSB provides the functions of RTSP, RTP and RTCP. It connects with the server using TCP port 1755 to set up connections. It then attempts to switch to UDP to transfer data. If UDP is blocked by a firewall, it switches to TCP.
Blocking access may not be enough
The number and variety of protocols used and their ability to switch to an alternative protocol when blocked adds to the difficulty of managing streaming media. Removing the applications from user workstations can block access to some media, but other media can be viewed directly in a Web browser.
Since it is difficult or impossible to block access to unwanted media, other methods must be used. Monitor network traffic carefully to spot excessive use by specific users. If necessary, configure your firewall to block access to sites that should not be accessed from the workplace. Finally, set a clear policy, and let your users know that you are monitoring network use.
About the author:
David B. Jacobs of The Jacobs Group has more than 20 years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies, as well as software startups.
