You can think of HTTP Streaming Protocol Extensions as Microsoft Media Server (MMS) streaming tunneled through HTTP. HTTP Streaming is a proprietary protocol with the following features:

• Supports TCP because it uses HTTP for all data transmission, and HTTP uses TCP only. This design has the following consequences:
  
• Packets are never lost. This means that if the network is unreliable, your client will stop, re-buffer and fall behind. This behavior is well-suited to transmissions that cannot tolerate data loss but poorly-suited to transmitting live events that are streamed in real-time.
  
• Forward error correction is not needed. As a result, overhead is lower, because packets are always sent over TCP and will not be lost.
  
• Works across all firewalls, because the streaming traffic uses HTTP.
  
• With HTTP Streaming Protocol Extensions, streaming can start after transmitting fewer protocol messages than when using RTSP. For example, if using HTTP Streaming, streaming can start with only two HTTP GET requests. In contrast, Windows Media Player using RTSP may send five or six RTSP request messages before streaming can start.
  RTSP requests are all sent on the same TCP connection. In contrast, Windows Media Player using HTTP will typically send each request on a separate TCP connection, each of which incurs the overhead of TCP three-way handshake.
  
• The protocol has two modes:
  
  • The simple mode requires two HTTP connections initially, plus one more every time the client pauses and resumes, or seeks. The simple mode causes problems with load balancers, which are designed for stateless HTTP traffic and therefore might send each of these connections to a different server. The streaming protocol is statefull, and requires consistent connection to one server, so simple mode can incur streaming errors when the client retrieves content through a load balancer.
    
  • The pipelined mode of the protocol uses the HTTP 1.1 pipelining feature to send all requests on a single connection. This greatly reduces the load balancer problem, but does not completely eliminate it. Most HTTP proxy servers do not support HTTP 1.1 pipelining, and in those cases Windows Media Player (WMP) reverts to the non-pipelined simple mode.
    

RTSP supports the following features:

• RTP packets can stream over UDP or over TCP. If the client can tolerate packet loss, streaming over UDP can be more efficient than TCP because UDP does not incur the overhead of retransmitting lost packets.
  
• The encapsulation of Advanced Streaming Format (ASF) packets in RTP is proprietary.
  
• The description of the ASF file, called ASF encapsulated in SDP, is proprietary.
  
• WMS supports retransmission of lost RTP packets sent over UDP. This behavior allows a client to give up on expired RTP packets, which in turn helps the client avoid falling behind after losing packets.
  
• WMS supports a forward error correction (FEC) scheme for RTP packets.
  
• Streaming with RTSP fails if a firewall separates the client and server, and the firewall blocks the ports and protocols that RTSP uses. This problem is especially common with home Internet gateways. Even if the gateway has a built-in RTSP NAT, streaming might fail at times.
  
• RTSP has the overhead of requiring multiple requests before playback can begin. However, the client can pipeline many of these requests and send them over a single TCP connection, in which case WMP does not need to block waiting for a response.
  

If you want to stream pre-encoded content and you don’t care about end-to-end delay, or if you need to stream to a Windows Embedded CE powered device, then use the HTTP Streaming Protocol Extensions or use a simple HTTP progressive download from a web server.

If you want to stream content to a client that runs a desktop operating system, and the content is a live broadcast or you want to reduce the end-to-end delay, then RTSP might be the best choice.

Concepts