Streaming Media Protocols

A protocol is a set of rules and procedures that determine how data is transferred between devices or computer programs. Protocols contain important information to ensure data is delivered properly. Depending on the protocol, this information can include the IP addresses of the sending and receiving computers, port numbers, error-checking methods, end-of-file indicators, and so on.

There is not one protocol that suits all purposes. Rather, protocols have different tasks depending on their position in the Open System Interconnection (OSI) model. According to this model, protocols are implemented in seven layers. The lower layers define how to connect devices to one another. The upper layers specify rules for conducting communications or interpreting applications. The higher they are in the stack, the more sophisticated the tasks and their associated protocols become. Figure 3.4 shows the seven layers of the OSI model.

Figure 3.4: The seven layers of the OSI protocol model.

When streaming, you will use protocols from the network, transport, and application layers. Some protocols are standard Internet protocols that you are probably already familiar with, and others are streaming protocols that might be new to you.

Standard Internet Protocols

A few of the protocols used by Windows Media 9 Series for streaming are standards of networking and the Internet. They should be familiar to anyone who has worked on networking computers or building Web sites. These protocols include TCP/IP, UDP, HTTP, RTP, and IPv6.

Transmission Control Protocol/Internet Protocol (TCP/IP)

At the root of the standard Internet protocols is the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. TCP/IP is an industry standard and includes a collection of protocols that work together to provide reliable data communications across both LANs and WANs. One example of a WAN is the Internet.

The IP portion of TCP/IP is a network-layer protocol responsible for specifying the format and address of packets on the network. IP is often combined with TCP in order to establish a connection between the host and destination and to guarantee that packets reach their destination as intended.

TCP is a transport-layer protocol that guarantees delivery of data and guarantees that packets will be delivered in the same order that they were sent. One way that TCP is able to provide these guarantees is by requiring a receipt from the destination verifying that the packets were received. While retaining the integrity of data delivery, this receipt exchange also generates traffic, which adds to the network overhead and can slow down delivery of the data.

User Datagram Protocol (UDP)

Like TCP, User Datagram Protocol (UDP) is a transport-layer protocol. UDP is the preferred protocol for streaming because it provides for one-to-one or one-to-many communications on a connectionless basis. Because it is connectionless, no delivery receipts are required. Instead, the UDP protocol relies upon other applications or upper-layer protocols to make sure the packets arrive intact. This enables UDP to transmit data very quickly.

Hypertext Transfer Protocol (HTTP)

Hypertext Transfer Protocol (HTTP) is an application-layer communication protocol that Web browsers and Web servers use to exchange information. HTTP relies heavily on the transport capability of TCP for traffic control.

Real-Time Protocol (RTP)

Real-Time Protocol (RTP) has some properties of a transport-layer protocol and is used for transmitting real-time data such as audio and video. RTP does not guarantee real-time delivery of data, but provides control mechanisms such as time stamps for the sending and receiving applications to support streaming data. Typically, RTP runs on top of the UDP protocol.

Windows Media 9 Series uses two streaming protocols in conjunction with the standard Internet protocols described above: the Real-Time Streaming Protocol (RTSP) and the Microsoft Media Server (MMS) protocol.

Real-Time Streaming Protocol (RTSP)

RTSP is an application-layer protocol that controls the real-time delivery of data, including audio and video content. RTSP supports two-way communication, which enables users to fast forward, rewind, and pause the playback of on-demand streams.

RTSP works with RTP to format packets of multimedia content and negotiate the most efficient transport-layer protocol (either UDP or TCP) to use when delivering the stream. Server administrators can also specify whether to use UDP or TCP for transferring packets. This decision is based on numerous factors, including firewall configuration and the speed of UDP versus the quality of TCP. RTSP is intended for unicast transmissions between servers and clients or between origin and distribution servers.

Microsoft Media Server (MMS) Protocol

MMS is a proprietary application-layer protocol developed by Microsoft to deliver unicast streams. It enables two-way communication so users can fast forward, rewind, and pause the playback of unicast, on-demand streams. Like RTSP, MMS can use either UDP or TCP to carry media packets across the network. MMS is intended for unicast streaming between servers and clients. Note that, with Windows Media 9 Series, MMS is no longer supported for server-to-server communication.

MMS was developed for use with earlier versions of Windows Media Services and represents the “rollover” protocol. When you create the URL that clients will use to connect to your content, use MMS. MMS enables Windows Media Player to negotiate (or roll over) to the optimal protocol for the connection automatically.

Media Stream Broadcast Distribution (MSBD) Protocol

Media Stream Broadcast Distribution (MSBD) protocol was used in earlier versions of Windows Media Technologies, but is no longer supported. Any Windows Media metafiles that currently specify MSBD should be changed to use MMS. Also, if your Windows Media Services 9 Series server is sourcing from a version 4.1 server, you’ll need to change the source URL to use MMS. See the online help for Windows Media Services for more information.

Protocol Rollover

Protocol rollover is the process that Windows Media Player uses to negotiate the best connection protocol for receiving a stream. Protocol rollover is enabled by default in Windows Media Player 9 Series and is supported through control protocol plug-ins in Windows Media Services 9 Series. By enabling multiple protocol plug-ins (including the WMS HTTP Server Control plug-in) on your Windows Media server, you can support a variety of client versions, client connection through firewalls, and clients that are connecting through different types of networks.

The request for a Windows Media stream usually begins with a user clicking a link on a Web page. This link is the announcement that contains a URL to your content. By default, the announcement uses the MMS protocol to ensure that protocol rollover will occur if necessary. Most of the time, the first connection attempt between a client and server is successful and no further action is taken. If that connection request is not successful, protocol rollover occurs, and the client attempts to connect to the server using another supported protocol. The client experiences a very small, usually unnoticeable period of latency during each protocol rollover attempt. In addition, when a client attempts to establish a new connection to the server, preference is given to the protocol that the client used in the previous connection.

It is recommended that you use protocol rollover to ensure that your clients have the optimal streaming experience. If clients connect to your stream using a URL with an mms:// prefix, any necessary protocol rollover will occur automatically.

Be aware that users can disable streaming protocols in the property settings of Windows Media Player. If a user disables a protocol, then it is disabled for rollover only. For example, if HTTP is disabled, then URLs will not roll over to HTTP. The logic used with protocol rollover differs depending on the type of client connecting to the server.

• When Windows Media Player 9 Series or a Player that uses the Windows Media Player 9 Series ActiveX control attempts to connect to the server using a URL with an mms:// prefix, the server automatically uses RTSP.

• If Fast Cache is enabled on the server (the default condition for all new publishing points), the server tries to connect to the client using RTSP with TCP-based transport (RTSPT) first.

• If the Player does not support that protocol, then the server attempts to connect using RTSP with UDP-based transport (RTSPU).

• If that connection is also not successful, the server will attempt to connect using the HTTP protocol if the WMS HTTP Server Control Protocol plug-in is enabled.

• If Fast Cache is not enabled, the server first tries to connect to the client using RTSPU, then RTSPT, and finally HTTP.

Earlier versions of Windows Media Player, such as Windows Media Player for Windows XP, do not support the RTSP protocol. However, the MMS protocol provides protocol rollover support for those players. Thus, when an earlier version of the Player attempts to connect to the server using a URL with an mms:// prefix, the server automatically negotiates the best protocol for the Player.

• The server first tries to connect to the client using MMS with UDP-based transport (MMSU).

• If that protocol is not supported, then the server attempts to connect using MMS with TCP-based transport (MMST).

• If that connection is also not successful, the server will attempt to connect using the HTTP protocol if the WMS HTTP Server Control Protocol plug-in is enabled.

Protocol rollover is not used when a distribution server attempts to connect to an origin server. Distribution servers cannot use a URL with an mms:// prefix to request a connection to the origin server. If the distribution server attempts to connect using RTSP, that request is translated as RTSPU. If TCP-based transport is preferred or required, then the URL must use an rtspt:// prefix. If the servers must connect using HTTP, then the URL must use an http:// prefix.