Article ID: 883831 - View products that this article applies to.
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:
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 listAn 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 intranetAdministrators 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 applicationYou 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.
Enable rollover to a TCP-based protocol on all Windows Media Server publishing points that stream to clients in the intranetThis 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 connects to a multicast URL, and rollover is enabled
The client connects to a multicast URL, and rollover is not enabled
The client connects to a negotiated protocol URLMany 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.
The client connects to a URL that specifies the UDP protocolFor example, the protocol specifies that the connection will use RTSPU or MMSU.
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:
Article ID: 883831 - Last Review: March 20, 2013 - Revision: 4.0