A data transfer protocol is a standardized format for transmitting data between two devices. The type of protocol used can determine such variables as the error checking method, the data compression method, and end-of-file acknowledgements. The protocols used to stream Windows Media-based content are RTSP and HTTP
Windows Media Services manages the use of these protocols by using control protocol plug-ins:
WMS RTSP Server Control Protocol plug-in and the WMS HTTP Server Control Protocol plug-in.
While the control protocol plug-ins handle the high-level exchange of data, basic networking protocols such as UDP and TCP are used to manage more fundamental tasks such as network connectivity and packet error correction. The RTSP protocol is used in combination with both the UDP or TCP protocols.
Networking Standards :
It seems everyone's heard of "TCP/IP". You probably know that "IP" stands for "Internet Protocol". The "TCP" stands for "Transmission Control Protocol". Here is the deal: to ensure a packet arrives without errors, the sender of a packet keeps an extra copy and waits for the receiver to say "I got it okay". If the sender hears this from the receiver, the sender can discard that extra copy. If the receiver says "I didn't get it" or says nothing at all after awhile, the sender resends it. As you can see, this makes for reliable delivery but takes time. It also adds a great deal of overhead because there is a dialog between the sender and receiver. Practically all email, web pages, and other Internet traffic is sent using TCP/IP.
TCP is a key reason why your web traffic or email "slows down" but does not "break". When there is too much traffic, your packets may be discarded or lost somewhere...but not to worry! Without you even knowing it, your packets are being resent until they finally get through (and you thought you just had a "good" connection).
Analogy: TCP is like a telephone call. If you didn't hear what the other person said, you say "What?"
UDP stands for "User Datagram Protocol". It is sometimes called "send and pray" because there is no dialog between the sender and receiver. If the receiver does not get a packet, the sender will never know. "When the heck would I want that!" you may ask. Well, UDP is very efficient when there is little chance of errors (like in your LAN), or when TCP would provide "too late" delivery.
All VBrick video is sent via UDP. Hey, we are sending live video, right? If I send you video frame #1, #2, #3 .... #1000 and you display the video frames in real time as you receive them, and you didn't get frame #500, what would you do with new frame #500 if I resent it to you? Display it after frame #1000? That wouldn't look too good, would it?
Video is normally send via UDP. But there is trouble with UDP now-adays. Many corporate firewalls block all UDP packets, making it impossible for streaming video to reach desktops. This is done to prevent hackers from getting access to the network, and is also sometimes done to prevent excessive use of bandwidth. More on this later.
Analogy: UDP is like a public address system. If you didn't hear what was announced, you can't hear it again.
RTP stands for Real-time Transport Protocol. It is normally sent via UDP. It does not ensure "real time" but is a protocol that enhances the control and synchronization of real time stuff (like streaming video). Here is where it gets interesting: with MPEG-1 and MPEG-2, RTP is unnecessary because MPEG itself provides synchronization (see White Paper). Like so many standards, there are several ways to implement it. For example, you can split apart the MPEG-1 stream and send audio on one IP address and video on another, or you can send both audio & video on the same address. RTP provides timestamps that will provide audio/video sync. VBrick has long supported RTP in the VB3000 for interoperability with other vendors.
In the case of MPEG-4, the only meaningful way to send audio/video is via RTP (there is nothing like a "MPEG-1 System Stream" nor a "MPEG-2 Transport Stream"). In other words, for MPEG-4, a/v sync is provided via RTP.
Analogy: RTP is like an orchestra leader, keeping all the musicians in sync.
RTSP stands for Real Time Streaming Protocol. RTSP is control protocol, not to be confused with IP, TCP, or UDP. However, RTP and RTSP are linked. You could find RTP without RTSP, but you would not find RTSP without RTP.
A good way to position RTSP in your mind is to think of it the same way you think of "http" and "ftp". You know, if you want to see a web page, you will enter "http://something". If you want to view a video in a player, you will enter "rtsp://something". This is only true for unicast streams, where each viewer receives their own stream from the server (i.e. from the VBrick). RTSP is not used for multicast.
Analogy: RTSP is like a "touch tone" telephone vs. the old rotary dial telephone. It is merely a method of signaling.
The Hyper Text Transfer Protocol is often confused with the Hyper Text Markup Language. Its description is beyond the scope of this page, and on the surface seems out of place here. However, because virtually all firewalls allow the default http port (port 80) to pass, streaming video can be sent via http "tunneling". There is a severe penalty, since http is sent via TCP which increases the overhead by some 30% and magnifies the delay.
Data (or video) can be sent via UDP or TCP, with RTP and RTSP, and can be sent via Unicast. So, Unicast is a method, not a protocol.
Unicast streaming is the default method by which a Windows Media server delivers content. A unicast stream is a one-to-one connection between the server and a client, which means that each client receives a distinct stream and only those clients that request the stream receive it.
Unicast streaming offers the benefits of interactivity between the player and server, easier setup, and multiple-bit-rate streaming capability. However, the number of users that are able to receive unicast streams is limited by the bitrate of the content and the speed of the server network. A large unicast audience can quickly overwhelm a network or server.
Multicast streaming is a one-to-many relationship between a Windows Media server and the clients receiving the stream. With a multicast stream, the server streams to a multicast IP address on the network, and all clients receive the same stream by subscribing to the IP address.
This is different from Unicasting, and different from broadcasting (where everyone gets the data whether they want it or not). You normally have a one-way connection, ruling out TCP, so Multicast is done via UDP. There are methods in use where a receiver can signal a sender that it has received a bad packet using a different 'reverse channel'. This is called "reliable multicast" and has little value for live video transmission.
Analogy: Distributing brochures with a sign that says "Take One". Only those who want it take it.
The Session Description Protocol, for our purposes, is a file that describes a MPEG-4 stream. SDP files are uniquely created for each stream, whether the stream is multicast or unicast. SDP files are put on servers to allow them to identify a stream and replicate it to viewers.
MPEG-1 and MPEG-2 both combine audio and video into a series of 1's and 0's. Exactly how those 1's and 0's are created is defined by the MPEG standards. So, when we say "MPEG-2 Transport Stream", we can look at a document and agree on what we mean. MPEG-1 and MPEG-2 are self sufficient, but they do little to specify exactly how they might be transmitted over IP.
MPEG-4 is also self-sufficient, but rather than defining unique "MPEG" ways of sending video, it specifies sending the video using existing standards.
Among those standards are IP, RTP and RTSP.
You can send MPEG-4 video by wrapping the video steam in a RTP packet, wrapping the audio stream in another RTP packet, then wrapping each RTP packet in a UDP packet, then controlling the stream using RTSP. You can encapsulate the RTP in http if necessary (via an external server).You can send MPEG-1 System and MPEG-2 Transport streams via raw UDP (this is what we normally do in LANs). You can send MPEG-1 System Streams and MPEG-2 transport streams via RTP over UDP , e.g. stored video on demand.