EN
Dieser Inhalt ist in Ihrer Sprache leider nicht verfügbar. Im Folgenden finden Sie die englische Version.

Firewall and NAT Support for Streaming over MMS

Gail McClellan
Microsoft Digital Media Division

Updated: April 2002

Summary: This article addresses the issues of setting up streaming using the MMS protocol with a system model that includes firewalls or a NAT (network address translation) device. This article also discusses the specific protocol information needed to support UDP-based MMS streams. (4 printed pages)

Contents

Introduction
MMS Operation
Firewalls and Protocols
Legal Notice

Introduction

MMS is a proprietary media server protocol developed by Microsoft for streaming digital media. This protocol is supported in Microsoft® Windows® Media Server version 4.0 and later, and Microsoft Windows Media Player.

A typical MMS session uses a TCP connection for sending and receiving media control commands, and a UDP connection for streaming the data. The server listens for incoming TCP connections on port 1755. To start a session, Windows Media Player connects to that port and sends various MMS requests.

The destination IP address and UDP data port are negotiated during the initial setup of the session. The client chooses a destination UDP port and sends its IP address and the UDP port to the server. The server, in turn, creates a UDP socket and connects it to the destination IP address and port. Alternatively, clients can request that the server send the data over the same TCP connection that is being used for the control messages. In this case, no UDP sockets are used at either end of the connection.

When using UDP to stream digital media, a UDP port is also opened on the server to receive resend requests from clients. All resend requests are sent to UDP port 1755 on the server by default.

NAT (network address translation) is an appropriate solution when the inside client needs to open a connection out to a remote site (Web browsing, for example). It is also useful when the two ends connect on a selected, random port (IRC's CTCP or FTP). It can be problematic when a specific port is used and more than one of the translated machines need to accept new incoming connections, such as in Web serving, online games, and other servers. This is the case with streaming. The information provided below briefly explains how to modify fields in the MMS message so that it will direct data to the correct IP address and port.

MMS Operation

The client and server exchange a number of messages when initially establishing a session. One message is of particular interest to firewalls or NAT services since it contains the client IP address and port. Here is an example of the message:

00000:  00 C0 4F 68 5D B4 00 60 B0 1B DB 5F 08 00 45 00   .ÀOh]´.`°.Û_..E.
00010:  00 A0 B5 60 40 00 80 06 0F 5A AC 1D EE AD AC 1D   . °Âµ`@.€..Z¬.î–¬.
00020:  EE B4 0D 7F 06 DB 23 FC 91 F3 70 3F 2D D8 50 18   î´..Û#ü'óp?–ØP.
00030:  43 A0 C3 C3 00 00 01 00 00 00 CE FA 0B B0 68 00   C°Ã Ã......Îú.°h.
00040:  00 00 4D 4D 53 20 0D 00 00 00 02 00 00 00 D5 78   ..MMS ........Õx
00050:  E9 26 31 08 CC 3F 0B 00 00 00 02 00 03 00 01 F9   é&1.Ì?......... ù
00060:  F0 F0 FF FF FF FF 00 00 00 00 00 00 A0 00 02 00   ððÿ ÿ ÿ ÿ......°...
00070:  00 00 5C 00 5C 00 31 00 37 00 32 00 2E 00 32 00   ..\.\.1.7.2...2.
00080:  39 00 2E 00 32 00 33 00 38 00 2E 00 31 00 37 00   9...2.3.8...1.7.
00090:  33 00 5C 00 55 00 44 00 50 00 5C 00 33 00 34 00   3.\.U.D.P.\.3.4.
000A0:  35 00 39 00 00 00 2D 00 32 00 32 00 30 00         5.9...-.2.2.0.  

MMS-protocol messages include a message identifier in the header. The message identifier is located at byte offset 37 within the payload of the TCP packet, and is 4 bytes long. The message identifier for this example exchange is 196610 (0x30002).

The UDP destination is a UNICODE string of the form \\IP Address\\Protocol\\Port. For instance, the UDP destination is \\172.29.238.173\UDP\3459 in the example shown above.

The first byte of the first character of this string is the byte number 61 of the TCP payload. In the example above, the TCP payload begins after byte number 00036 (byte number 54 in decimal), with the byte value 01.

If an intervening firewall, NAT service, or other proxy server needs to modify the destination address specified in this message, it must also modify various length fields of the packet if the new address has a different number of characters than the previous address. Specifically, the following length fields in the MMS message need to be modified so that the destination address or port number specified in the MMS message is changed. This, in turn, could result in changing the size of the MMS message:

Field Description
messageLength A 4-byte number that starts in byte 9 of the TCP payload and ends in byte 12. It is easy to recognize because it is located between two constant strings: CE FA 0B B0 and 4D 4D 53 20 ('MMS').
chunkLenLV A 4-byte number that starts in byte 17 of the TCP payload and ends in byte 20.
chunkLenLM A 4-byte number that starts in byte 33 of the TCP payload and ends in byte 36.

A chunk unit is 8 bytes. chunkLenLM specifies the number of 8-byte chunks that exist in the last section of the MMS message. Any change in the number of bytes required for the IP address or port number field may require a change to this field. Note that the IP address is a string value; if the length of the changed string \\IP Address\\Protocol\\Port is less than the original string, then this length field will remain unchanged.

The chunkLenLV value is always 2+ chunkLenLM. For the example above, this value will be 2 + 11 = 13.

The messageLength field in the MMS message equals chunkLenLV * 8, since each chunk is 8 bytes. For the example above, this value will be 13 * 8 = 104.

If the client request is successful, the server responds to the message from the client, using a MMS message with a message identifier of 262146 (0x40002).

Firewalls and Protocols

For more information on firewalls and general information on protocols see Firewall Information.

Legal Notice

Portions, Copyright © 1994-2000 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved. http://www.w3.org/

Anzeigen: