Important This article contains information that shows you how to help lower security settings or how to turn off security features on a computer. You can make these changes to work around a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect your system.
This article discusses new behavior that a user may see in Microsoft Windows Media Player and in applications that are built by using the Microsoft Windows Media Format SDK. The new behavior may appear after the user installs Microsoft Windows XP Service Pack 2 (SP2). The new behavior affects networking playback through Windows Firewall. By default, Windows Firewall is enabled on Windows XP SP2. This article also discusses workarounds for the new behavior.
A client may not be able to connect to multicast streams or to other User Datagram Protocol (UDP) streams by using Microsoft Windows Media Player if the following are true:
The client is running Microsoft Windows XP with Service Pack 2 (SP2) or a later version.
The client has Windows Firewall enabled.
The user's user account does not have administrator rights.
This behavior occurs because a new security feature of Windows Firewall does not allow incoming UDP traffic unless an administrator has configured Windows Firewall to allow it. This behavior also occurs in earlier versions of Windows if Windows Firewall is enabled. By default, Windows Firewall is enabled in Windows XP SP2 and later versions. Therefore, more users may experience this problem.
Note Windows Firewall is known as Internet Connection Firewall in earlier versions of Windows.
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:
On the Tools menu, click Options.
In the Options dialog box, click the Network tab.
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:
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.
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.
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.
For more information, see the product documentation.
For more information about specific configuration settings, visit the following Microsoft Web site:
http://technet.microsoft.com/en-us/library/bb877979.aspxFor more information about multicast streaming, visit the following Microsoft Web site:
http://www.microsoft.com/windows/windowsmedia/forpros/server/server.aspxFor more information about protocol rollover, visit the following Microsoft Web site: