NAT vs MSN Messenger----What's the solution for them??
這是官方的網站文件,不知有網友可以分享這方面的經驗嗎?
文件有提到 UPnP protocol,以 redhat 7.1 完成的 nat 有支援此項嗎?
以下摘自微軟網站 (
http://www.microsoft.com/windowsxp/pro/techinfo/deployment/natfw/natwinmes.asp )
------------------------------------------------------------------
This section addresses issues and configurations for NAT devices.
Problems Caused by NAT Devices
The specific problems that NAT devices cause in relation to Windows Messenger features include:
Clients behind a NAT device usually have a private IP address assigned to them. This address is translated to and from a public IP address and port by the NAT device. In several cases this private address is presented in a message to a Windows Messenger peer to enable the peer to contact the client. The address is invalid for this use and the translated address must be used instead.
There are several cases where port mappings must be made at the NAT device to present an address and port to an external client and have it map to the appropriate internal client.
In some cases where static ports are used for a particular feature, only a single client behind the NAT can use that feature.
Working With Different NAT Device Configurations
The following section discuss issues related to different NAT device configurations:
UPnP–enabled NAT Devices
The UPnP forum contains several working committees, including a working committee specific to Internet gateway devices. This group is responsible for defining the specifics of UPnP support for these devices which include NAT and firewall devices. This group has defined a standard for ICS and NAT network traversal using UPnP.
NAT and firewall devices that support this standard can be detected and controlled using UPnP protocols. UPnP can be used by clients to read and configure port mappings. Windows XP ICS and ICF support this standard. Other vendors of network edge devices have also announced support of this standard, including ARESCOM Inc., Buffalo Technologies Corp., D–Link Systems Inc., Intel Corp., Linksys Group Inc. and NetGear Inc.
Windows XP also provides client support for UPnP and application program interfaces (API) specifically designed for applications to detect and leverage UPnP–enabled NAT and firewall devices on a network. Windows Messenger in Windows XP uses these APIs to achieve the following:
Detect whether the Windows Messenger client is behind a NAT device, and if so retrieve the translated address to send to its peer. This solves several problems seen above.
Obtain a port–mapping for dynamically allocated ports to be used for signaling, such as required by a SIP session configuration. This allows signaling by the external client to reach its destination.
Obtain mappings for the dynamic ports used by media streams — including those used for AV, AS and WB.
Detect whether the Windows Messenger peer is behind the same NAT device. If so, the real addresses of the peer are retrieved and the peers can communicate directly.
Note Support for UPnP clients of NAT traversal is currently available for previous versions of Windows—(Windows 98, 98SE, ME). This support is distributed by running the Network Setup Wizard that ships in Windows XP.
Non–UPnP NAT Devices
Windows Messenger peers, separated by a NAT device that cannot be detected, should be able to use IM and Presence. This is true whether the network service being used is .NET Messenger, Exchange IM, or a SIP solution. Clients using SIP servers also work because logic has been added to the client to ensure communication when the server is opened.
Issues arise, as described earlier in this article, with the other features of Windows Messenger. The following points relate to those issues:
IM and Presence are implemented through a mediating server with a direct TCP connection initiated by the client when using .NET Messenger or Exchange IM. This should not present any NAT or firewall issues. Sessions or connections initiated by clients external to the NAT device will not succeed because the internal client cannot provide the NAT–translated address to the peer. In the case of AV this applies to calls made by the internal client to the external client, because the external client is the one initiating the SIP session. If the external client calls the internal client, the failure occurs later in the process. The internal client can send the SIP invite to the external client, but the address passed in this invite is incorrect.
Calls made between peers on the same side of the NAT device should work.
An application layer gateway (ALG) for SIP may alleviate some of these problems. ALGs can be used as an application level filter for specific applications and protocols.
Cascading NAT Devices
Even if the edge of your network doesn't use a NAT device, or uses a UPnP–aware NAT device, Windows Messenger AV communication can be defeated by a cascading NAT scenario. In this scenario, another NAT device exists in the path between you and the Windows Messenger client you are communicating with, and this NAT device is not under the control of either client. This can occur if your Internet service provider (ISP) also uses NAT technology in their network. This is not a common occurrence. If you suspect this situation, contact your ISP to verify the issue and discover possible workarounds.
