A client may not be able to connect to multicast streams or to other User Datagram Protocol streams through Windows Firewall by using Windows Media Player (883831)

WORKAROUND

Warning These workarounds may make your computer or your network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend these workaround but are providing this information so that you can implement these workarounds at your own discretion. Use these workarounds at your own risk.

To allow users who do not have administrator rights to receive UDP streams, use one of the following methods. The following sections discuss the advantages and the disadvantages of each method.

Add the application to the Windows Firewall exceptions list

An application on the Windows Firewall exceptions list is allowed to receive all incoming traffic. In many ways, this is the easiest method. However, it creates a vulnerability that may not be required. Therefore, this method is less secure than the other methods.

Important We do not recommend this method.

Specifically allow incoming traffic from the IP addresses of all servers that are running Windows Media Server and that stream to clients in the intranet

Administrators can configure Windows Firewall to allow incoming traffic from specific IP addresses. If your intranet does not contain many servers that are running Windows Media Server, or if you can easily specify a range of IP addresses, this is a good method to use. This way, you can add the application to the Windows Firewall exception list. However, you can allow it to receive incoming traffic only from the IP addresses that you specify.

Open the port or the ports that the incoming traffic must use for the specific application

You can configure Windows Firewall to allow UDP traffic only for specific ports. The protocol determines the ports to open.

Note This method may require that you change the Windows Media Player settings or the configuration settings on the server.

Real Time Streaming Protocol (RTSP) - In the default installation of Windows Media Player, RTSP protocol randomly chooses the incoming data ports. To specify the range of ports to use, the user can do the following:
1. On the Tools menu, click Options.
2. In the Options dialog box, click the Network tab.
3. On the Network tab, select the Use ports check box, and then specify a range of ports to use.
If the Use ports check box is selected, RTSP will always use the ports in that range. Therefore, the administrator can enable RTSP (UDP) streaming by opening the specified ports in the firewall.
Microsoft Media Server (MMS) - Like RTSP, MMS (UDP) uses a random port for incoming data. MMS will also use the ports that the Use ports option specifies. The administrator can enable MMS (UDP) streaming by opening the specified ports in the firewall.
Multicast - For multicast streams, the port that the client receives streaming traffic through is configured on the server. This value is specified in the Microsoft NetShow channel (.nsc) file. The client has no direct way to know this port number before the port is used. The administrator for Windows Media Services can set the destination port by configuring the multicast publishing point. To do this, follow these steps:
1. On the Properties tab of the publishing point, double-click the WMS Multicast Data Writer plug-in. This plug-in is located in the Multicast Streaming category.
2. Configure the multicast properties such as the multicast address.
The network administrator can also open the specified port in the firewall.
Hypertext Transfer Protocol (HTTP) - Because HTTP is a TCP-based protocol, it is not affected by the problem that is discussed in the "Symptoms" section. HTTP streams can be accessed directly. HTTP streams can also be accessed through protocol rollover if neither RTSP nor MMS can open the required port.

Enable rollover to a TCP-based protocol on all Windows Media Server publishing points that stream to clients in the intranet

This method is more secure that the others because you do not have to change the configuration of Windows Firewall. However, TCP connections use more resources on the network and on the server than multicast traffic or UDP traffic. Therefore, this method may not be the best choice for your network, depending on the load on the server and the expected number of clients that must roll over.

MORE INFORMATION

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.