Corporations frequently use multicast streams to broadcast live events across the local intranet. Multicast streams limit the network bandwidth that a broadcast uses because all clients connect to the same multicast stream.
Note Typically, multicast streams are not sent over the Internet because most network segments on the Internet are not multicast-enabled.
When a client tries to connect to a stream or to a multicast stream by using UDP protocol, the Windows Media Format SDK and Windows Media Player try to open the ports in Windows Firewall that are required to receive incoming UDP traffic for that stream. However, if the user is running the application by using a user account that does not have administrator rights, the ports are not opened because only administrators are allowed to change Windows Firewall settings.
If the multicast publishing point on the server that is running Windows Media Services is configured to allow rollover to unicast streaming, the client rolls over successfully and then connects to the stream by using a TCP-based protocol.
However, unicast streaming uses much more network resources and server resources than multicast streaming uses. Therefore, when multicast clients roll over to a unicast connection, more stress is added to the network and to the server. If many clients roll over to a unicast connection, the user experience may be decreased if insufficient resources are available to carry the increased load.
Similarly, a client that tries to connect to a unicast UDP stream rolls over to a TCP-based protocol if the client cannot connect to the stream. Depending on the version of the Windows Media Format SDK that the user has installed, the user may receive a
Windows Security Alert dialog box from Windows Firewall. The message in the dialog box states that the application has been blocked from accepting connections from the Internet.
If you are an administrator of Windows Media Services, note that TCP connections use slightly more resources on the server than UDP connections use. Therefore, if many clients roll over from UDP protocol to a TCP-based protocol, the server may experience increased load issues.
The protocol that is used for streaming may depend on the URL and the settings on both the server and the client. The client also caches information about the protocol that was used the last time that the connection was made successfully. For later connections to a stream, the client may use this information to change the protocol that it tries first.
To determine the protocol that is being used for a stream, a user can click
Statistics on the
View menu and then note the protocol that is specified on the
Advanced tab.
In the following examples, the user is using Windows Media Player and the following are true:
- The client is running Windows XP SP2 or a later version.
- The client has Windows Firewall enabled.
- The user's user account does not have administrator rights.
Note Other applications that are based on the Windows Media Format SDK may experience the same behavior.
The client connects to a multicast URL, and rollover is enabled
- Windows Media Player 10 - Multicast rollover occurs. The client performs a unicast protocol rollover and then connects to the stream by using TCP.
- Windows Media Player 9 Series - The user receives a Windows Security Alert notification from Windows Firewall, and then rollover occurs. The client performs a unicast protocol rollover and then connects to the stream by using TCP. When the user receives the Windows Security Alert notification, the user may choose not to see the notification again for the current application.
The client connects to a multicast URL, and rollover is not enabled
- Windows Media Player 10 - The user receives an error message that Windows Media Player cannot connect to the server. The error message suggests that a firewall might be the cause of this problem.
- Windows Media Player 9 Series - The user receives a Windows Security Alert notification from Windows Firewall. Then, the user receives an error message from Windows Media Player. This error message states that the server is busy. When the user receives the Windows Security Alert notification, the user may choose not to see the notification again for the current application.
The client connects to a negotiated protocol URL
Many protocols try to negotiate automatically with the server for the most efficient way to exchange information. For example, both RTSP and MMS will try to stream content by using UDP. If that method does not succeed, RTSP and MMS will try to stream content by using TCP.
Some application settings may affect protocol rollover behavior. For example, the settings in Windows Media Services 9 Series Fast Start and Fast Cache may affect protocol rollover behavior. See the product documentation for protocol rollover behavior.
- Windows Media Player 10 - The client connects by using TCP.
- Windows Media Player 9 Series - Depending on the protocol that is specified in the URL, the user may or may not see a Windows Security Alert notification from Windows Firewall. The client connects by using TCP.
The client connects to a URL that specifies the UDP protocol
For example, the protocol specifies that the connection will use RTSPU or MMSU.
- Windows Media Player 10 - The user receives an error message that Windows Media Player could not connect to the server. The error message suggests that a firewall might be the cause of this problem.
- Windows Media Player 9 Series - The user receives a Windows Security Alert notification from Windows Firewall. Then, the user receives an error message that Windows Media Player could not connect to the server. The error message suggests that a firewall might be the cause of this problem.