1.open port 1863
open port 6981 - 6900
2.在 Messenger 主視窗上，按一下 [工具] 功能表，按一下 [選項]，再按 [連線] 索引標籤。
請注意在此索引標籤中所需要的資訊。
請提供所有網路使用者在其 MSN Messenger 程式中正確設定 [連線] 索引標籤所需的資訊和指示。
請確認內部的區域網路可以存取「網域名稱系統」(DNS) 伺服器，來解決如「messenger.msn.com.tw」等外部主機的名稱問題
3.i use http proxy in 索引標籤(Messenger 主視窗上，按一下 [工具] 功能表，按一下 [選項]，再按 [連線] 索引標籤。 )
isp is ethome(東森寬帶),no dmz router,二台電腦沒有使用真實ip,一台有真實ip,no problem can work,if you have any question you can go
http://redhat.ecenter.idv.tw/
高手比較多（台灣有些高手真不簡單),或得不到滿意的答案,可問a471 or 不飛
http://www.microsoft.com/windowsxp/p...atfw/natfw.doc
The following Windows Messenger features affected by NAT and firewall issues are:
Instant Messaging and Presence
In general, there are no issues with IM and presence affecting communication through a firewall or NAT device. If the Windows XP client can create and maintain a connection to the server, other IM and presence communication can follow this same path. For example, Microsoft Exchange IM transports its Presence and IM messages using hypertext transfer protocol (HTTP) and has mechanisms to insure that these messages can traverse firewall and NAT devices. These mechanisms include polling to maintain a TCP connection to the server for two-way communication and setting aside a fixed port for callback delivery.
When a session initiation protocol (SIP) solution is used, the data may be sent using TCP, UDP or secure sockets layer (SSL). SIP signaling may also use dynamic ports, which may require opening the entire range of ports on a firewall. If a NAT device is placed between SIP clients and their servers, differences may exist between the ports and addresses reflected in the SIP messages and the actual ports and addresses. Windows Messenger has mechanisms to overcome these issues and are discussed later in this article.
Audio and Video
When negotiating an audio-video session, dynamic ports were chosen for the audio-video (AV) stream. Dynamic ports are used to enable the application to work regardless of what other applications are running on the system and using port resources. In the .NET Messenger case the session invitation was sent by station B to the address it received for station A.
The following issues might arise if a firewall or NAT were present in these scenarios:
• The address provided by A in either the session invite for session signaling, or in the session acceptance for the UDP streams, might be an internal address that is translated by a NAT device—an invalid (or fake)
address for B to use to contact A. In other scenarios with the 4.5 client, A might initiate the session, but the same or similar addressing issues will exist.
• When B sends the session invitation to A, this invitation is sent using the IP address and port passed from A to B. For this to work, this port must be enabled to pass through any firewall between A and B.
• The actual Real-time Transport Protocol (RTP) streams are sent using dynamically allocated UDP ports in the range of 5004 – 65535. Without a way to open these UDP ports on any firewall in the path dynamically, the streams will fail to reach their destination.
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.
Administrator/User Action Required
To enable voice and video communications with Windows Messenger through a non-UPnP firewall, configure the firewall to allow incoming traffic on UDP ports 5004 – 65535.
For other purposes, enable the following ports:
• File Transfer: 6891 (to allow 10 simultaneous file transfers open ports 6891 through 6900)
• Application and Whiteboard Sharing: 1503
• Remote Assistance: 3389