求助，用WINDOWS MESSENGER 4.7 无法传文件给别人

shanghainese

但接收没问题
  
NIS2003已经DISABLED
  
使用环境：LINKSYS无线上网

yogibear

其他人能不能把文件在和你一样的使用环境下把文件传给对方呢？
  
对方的没有把接收文件的端口给disbale吧？
  
还有改用MSN Messager不行吗？

hmsea

1、是否你或对方的网络联结中使用了防火墙，如有，请关掉它。
2、你或对方是否有一方处于内部局域网中，请升级至MSN6试试。

giga

升级到6，没有问题！
今天刚刚发了一个20M的文件给一个多伦多的朋友

kelvinlu

把xp的防火墙关了试试

shanghainese

但是如果我自己用4.7给6.0发，6.0的机器能接收，NIS2003开着的时候发的（两台都是连接LINKSYS无线路由器），我本来是怀疑LINKSYS的，但后来一想也不对，在装LINKSYS之前，我的WINDOWS MESSENGER 4.7，ICQ也都是只能收不能发，我把NIS2003 DISABLED，在SERVICE里也停掉了，同样不行。至于对方肯定没问题，他平时都收发正常，我到现在还分析不出问题所在

yansy

应该是ICF没有设置好的问题，打开6891－6900号端口就可以了。

shanghainese

QUOTE:

yansy wrote:
应该是ICF没有设置好的问题，打开6891－6900号端口就可以了。

  
在路由器上打开这些端口？

黏土

升级到6是个比较好的办法

shanghainese

QUOTE:

黏土 wrote:
升级到6是个比较好的办法

  
6.0也发不出，昨天装了个QQ，却能发，不知QQ用的是什么端口？

knightmx

QUOTE:

shanghainese wrote:
[quote]黏土 wrote:
升级到6是个比较好的办法

  
6.0也发不出，昨天装了个QQ，却能发，不知QQ用的是什么端口？ [/quote]
  
不可能啊，以前用4.7的就是发不出去，现在用了6.0的问题解决了，要不就是对方那儿的问题了！

shanghainese

我用排除法试过，就是找不出问题所在，我也不知道为什么，6.0那台电脑连NIS2003防火墙也没装

shanghainese

我找到这些资料，大家共享，晚上试试打开6891
  
Windows XP 中的Windows Messenger：在防火墙和NAT环境中的使用和运行
  
本文对Windows Messenger的几种使用情境进行了讨论，并且介绍了在这些情境下，您需要如何操作才能使用Windows Messenger的全部功能特性，同时为问题的发现和解决提供了几种可能的解决方案。  
  
Windows Messenger为用户带来了激动人心的全新实时通信体验，它将为人类的通信沟通方式带来一场彻底的变革。通过使用Windows Messenger，您可以通过即时消息（IM）。语音、视频、应用程序和数据共享、以及远程协助同您的朋友、家人和同事展开交流。在很多网络环境下，您无需对网络结构进行任何的改变即可使用所有这些功能特性。但是某些特殊的网络（例如企业或家庭网络）可能还会部署一些防火墙和（或）网络地址转换（NAT）组件。  
  
通过阻止外部用户直接访问内部计算机，防火墙可以网络上的计算机免受非法访问的侵害。位于防火墙后方的计算机使用NAT组件共享有限的公共 IP（Internet Protocol，Internet协议）地址。在当前使用IPv4地址分配架构的Internet中，共享IP地址是一种有限的资源。因为IPv4地址分配架构不能提供足够的IP地址，信息技术行业被迫对NAT技术进行了标准化，并且部署了许多NAT产品，以便对IP地址和TCP（Transmission Control Protoco）/UDP（User Datagram Protocol）端口进行共享。 所以，在这些特定的网络环境下，某些Windows Messenger功能（主要是即时语音和视频通信功能）在功能上可能会大打折扣。  
  
如果通信双方使用的是具有通用即插即用（UpnP）能力的防火墙或者NAT组件，所有的Windows Messenger新特性都可以正常使用。但是， features work as intended. However, there are netw有些网络则需要进行特别的配置，以便所有的Windows Messenger新特性都能够正常工作。  
  
说明： Microsoft承诺同业界领先厂商以及标准化组织（例如Internet工程组IETF）密切合作，确保这些强大的通信和协作功能能够在安装了防火墙和NAT组件的网络上得到使用。  
  
NAT和防火墙问题  
  
本节内容介绍了对受NAT和防火墙问题影响的Windows Messenger功能，这些功能包括：即时消息和出席（Presence） 、音频和视频、应用程序共享和白板、文件传输以及远程协助。  
  
Windows Messenger提供了使用文字、语音和视频进行沟通交流的能力；它也可以通过文件传输开展协作；或者共享应用程序和使用白板绘图。  
  
在很多配置情况下，所有的Windows Messenger功能都可以直接正常工作。但是在某些配置情况下，某些特定的功能可能会受到某些限制或者根本无法工作。为了解决这些问题，Windows Messenger使用了Windows XP及较早期Windows版本中的UPnP架构。随着越来越多的Internet网关设备开始为UPnP提供支持，这种解决方案的可用性将变得越来越强。  
  
说明：Microsoft将在Windows XP的Internet连接共享（ICS）和Internet连接防火墙（ICF）中提供对UPnP的支持。（同Internet连接共享和Internet连接防火墙有关的更详细信息，请阅读： Windows XP在安全性方面的新增特性。  
  
受NAT和防火墙问题影响的Windows Messenger功能包括：  
  
即时消息和出席（Presence）功能  
一般来说，防火墙和NAT设备对IM和出席功能不会有任何的影响。如果Windows XP客户机可以创建并维护一条到服务器的连接，那么其它的IM和出席也能够沿着相同的途径进行通信。例如，Microsoft Exchange IM使用HTTP（超文本传输协议）传送它的出席（Presence）和IM消息，并且拥有能够确保这些消息通过防火墙和NAT设备的传输机制。这些机制包括：通过轮询维护一条能够进行双向通信的服务器连接，以及在一侧设定一个固定的端口用于回叫传输。  
  
在使用会话初始化协议（SIP）解决方案的时候，数据可能使用TCP、UDP或者安全套接字层（SSL）进行发送。此外，SIP数据传输还需要使用动态端口，所以您可能需要开放防火墙上的所有端口。如果在SIP客户端与服务器间存在一个NAT设备，那么，反映在SIP消息中的端口和地址可能会与实际的端口和地址有所不同。Windows Messenger拥有的某些机制可以解决这些问题，我们将在以后的文章中对它进行讨论。  
  
音频和视频  
在协商进行一个音频－视频会话的时候，音频－视频流会选择使用动态端口。在使用动态端口时，应用程序无需考虑系统中还运行了哪些其它的应用程序以及这些程序都使用哪些端口资源即可正常工作。对于.NET Messenger，来自B站的会话邀请会被发送到B站所接收到的A站地址处。  
  
如果网络环境中存在防火墙或者NAT设备，可能会发生以下问题：  
  
无论是在会话邀请还是在接受会话的过程中，由A提供的地址都可能是一个经过NAT设备转换的内部地址 —— 一个无效（或虚假）地址，B无法使用这个地址同A联系。在使用4.5版本的客户端程序的情况下，A可能会对会话进行初始化，但是相同或者类似的地址问题仍然存在。  
当B向A发送会话邀请的时候，该邀请所使用的IP地址和端口是由A传递给B的。要想使会话能够顺利进行，A和B之间的所有防火墙都必须开放该端口。  
实时传输协议（Real–time Transport Protocol，RTP）数据流使用动态分配的UDP端口进行发送，端口范围在5004 – 65535之间。如果传输路径上有任何一个防火墙没有开放这些UDP端口，那么这些流数据将不能到达它们的目的地。  
应用程序共享和白板  
当您在一个安装了防火墙或者NAT设备的网络环境中使用应用程序共享和白板功能的时候，可能会发生以下问题。（前两个问题与音频和视频功能遇到的问题相同）  
  
由会话发起站点提供的地址可能是一个经过NAT设备转换的内部地址。这是一个无效的地址，外部客户端不能够使用该地址开始SIP会话或者同A建立TCP连接。  
外部客户端发送SIP邀请所使用的端口（由内部客户端传递给外部客户端）必须使SIP邀请能够通过这两个客户端之间的所有防火墙。  
用来传输应用程序共享（AS）和白板（WB）数据的TCP连接使用1503端口，您需要启用该端口，以便数据能够通过所有的防火墙。在一个具有UPnP能力的网关上，您无需启用该端口，因为它会将内部的静态端口映射到其它端口上。  
因为TCP数据连接使用一个特定的端口（1503），如果客户端位于一个不具备UPnP能力的NAT设备之后，该端口必须被映射到该客户端上。以确保能够通过最常见的NAT设备进行通信。这还意味着：该端口一般不能被NAT设备后面的其它客户端所使用；在一个时间中，只有位于相同NAT设备后面的一个客户端能够拥有一个AS或WB会话。  
文件传输  
文件传输（FT）需要会话发起站点将它的地址通过服务器传递给FT会话的另一方。所以，它所遇到的第一个问题与使用应用程序共享和白板功能时遇到的问题相同：  
  
由会话发起站点提供的地址可能是一个经过NAT设备转换的内部地址。这是一个无效的地址，另一方无法使用该地址建立TCP连接。  
针对文件传输的TCP连接可以由外部客户端发起，但是存在另外一个问题。  
  
外来和外出的TCP连接都使用6891到6900间的端口。这使得每个发送方最多只能建立10条文件传输连接。在通信双方之间的所有防火墙上，这些端口都必须被开放。如果您仅仅开放6891端口，用户每次只能建立起一条文件传输连接。  
远程协助  
远程协助使用远程桌面协议（Remote Desktop Protocol，RDP）；与Microsoft Terminal Services使用同一个协议。RDP建立在TCP连接之上。Windows Messenger使用基于服务器的会话邀请逻辑（与FT类似）建立远程协助会话。所以，它同样会因为NAT产生与FT同样的问题。  
  
远程协助包括了一个附加逻辑，以应对可能遇到的NAT环境。该逻辑会简单地尝试从会话双方两个方向上建立TCP连接。如果只有一个客户端位于NAT设备之后，那么连接仍然可以建立，远程协助会话也依然可以进行。如果两个客户端都位于（不具备UPnP能力）NAT设备的后面，那么连接将不能建立。只有在远程协助中加入了语音会话时，这个附加的SIP邀请逻辑才会被加入。  
  
除了由NAT地址转换产生的问题（只有在通信路径中存在多个NAT设备才会出现问题）之外，远程协助协议需要使用3389端口建立TCP连接。这意味着，通信双方之间的所有防火墙都必须开放3389端口。
  
NAT和Windows Messenger  
  
本部分内容介绍了Windows Messenger在NAT环境下可能产生的问题以及相关配置方法。  
  
由NAT设备引起的问题  
  
NAT设备会在以下方面对Windows Messenger功能的使用造成不良影响：  
  
位于某台NAT设备后面的客户端通常会被分配一个私有的IP地址。在收发数据时，该地址会被NAT设备转换成某个公共IP地址和端口。在一些情况下，这个私有地址会被包括在Windows Messenger消息中发送给另一个用户，以便该用户能够同消息发送方进行联系。但是，消息接收方并不能使用这个私有地址同发送方建立连接，该地址必须经过转换，被一个公共地址所代替。  
在一些情况下，NAT设备必须进行端口映射，以便将一个地址和端口发送给外部客户，并且将该地址同相应的内部客户进行映射。  
有时，我们必须为某个特殊的功能使用静态端口，这种情况下，在同一时间内，NAT设备后只有一个客户端能够使用该功能。  
在不同的NAT配置环境中工作  
  
下面，我们将对不同的NAT配置环境进行讨论：  
  
支持UPnP的NAT设备  
UPnP论坛包含数个工作委员会，其中有一个专门为Internet网关设备而设立的工作委员会。该委员会主要负责为这些设备（例如NAT和防火墙设备）制订UPnP支持规范，并且已经为使用ICS和NAT网络转换定义出了一个标准。 支持该标准的NAT和防火墙设备可以使用UPnP协议进行检测和控制。客户端程序可以使用UPnP读取和配置端口映射。Windows XP ICS 和ICF 支持该标准。其它网关设备厂商也已经宣布将为该标准提供支持，这些厂商包括：ARESCOM Inc.、Buffalo Technologies Corp.、D–Link Systems Inc.、Intel Corp.、Linksys Group Inc.以及NetGear Inc.  
  
此外，Windows XP还为UPnP提供了客户端支持和应用程序编程接口（API），以便应用程序能够检测出网络中具备UpnP能力的NAT和防火墙设备并对其加以利用。Windows XP中的Windows Messenger 可以使用这些API完成以下工作：  
  
检测Windows Messenger客户端程序是否位于NAT设备之后，并且在程序位于NAT设备之后的情况下，返回经过转换的地址，然后将该地址发送给会话方。这就有效解决了我们上面提到过的几个问题。  
获得动态分配端口的端口映射，并且使用它进行数据传输，对于一个SIP会话配置来说，这信息是必需获得的。这样，外部客户端的数据就可以顺利到达目的地。  
获得针对媒体流的动态端口映射 —— 包括AV、AS和WB使用的端口。  
检测Windows Messenger的通信双方是否位于同一个NAT设备之后。如果是，则使用真实的IP地址在双方间直接进行通信。  
注：现在，您还可以为Windows的以前版本（Windows 98、98SE、ME）添加对NAT转换的UPnP客户端支持。您可以通过在上述版本的Windows系统中运行Windows XP附带的网络安装向导（Network Setup Wizard）获得这种支持能力。  
  
不支持UPnP的NAT设备  
如果使用Windows Messenger进行通话的双方不位于同一个NAT设备之后，并且该NAT设备不能被Windows Messenger检测到，那么他们应该仍然可以使用IM和Presence（在线显示）功能。无论您使用的是.NET Messenger、Exchange IM或者是一个SIP解决方案，情况均是如此。使用SIP服务器的客户同样能够工作，因为相关逻辑已经被添加到了客户端程序上，以确保在服务器运行期间通信能够正常进行。  
  
我们在本文的前面部分曾经提到，NAT设备会给Windows Messenger部分功能的使用带来一些问题。下面，我们将就这些问题进行讨论：  
  
在使用.NET Messenger或者Exchange IM时，IM 和Presence功能可以通过一台中间服务器得以实现，该服务器具有一条由客户端程序发起的直接TCP连接。这样应该不会产生任何NAT或防火墙问题。由位于NAT设备外部的客户端程序发起的会话或连接不会取得成功，因为内部的客户端程序无法向对方提供经过NAT转换的地址。AV会话的情况即是如此，由内部客户端向外部客户端发起的呼叫可以取得成功，因为外部客户端是SIP会话的发起方。但是如果由外部客户端呼叫内部客户端，呼叫过程将失败。因为虽然内部客户端可以向外部客户端发送SIP邀请，但是在会话邀请中夹带的地址是一个错误的地址。  
位于NAT设备同一侧的双方能够正常进行会话。  
SIP的应用层网关（ALG）可能会对这些问题有所缓和。用户可以将ALG用作一个应用层过滤器，使用它对特定的应用程序和协议进行过滤。  
级联式NAT设备  
在级联式的NAT环境中，既使您的网络中没有使用NAT设备，或者使用了一个支持UPnP的NAT设备，Windows Messenger的AV通信可能仍然不会取得成功。因为在这种配置环境下，通话双方之间的会话路径中可能存在其它NAT设备，而这些NAT设备是不受会话双方控制的。例如，您的Internet服务提供商（ISP）也在它的网络中使用了NAT技术，但是这种情况并不常见。如果您怀疑通信问题是由这种情况引起的，请同您的ISP联系，以确定问题原因并找出相应的解决办法。

yogibear

等你的实验结果。。

shanghainese

QUOTE:

yogibear wrote:
等你的实验结果。。

  
打开6891 后，6.0能给别人传文件了，4.7则依然不行

shanghainese

估计是4.7对UPnP的支持不够完善，6.0则做得比较好，所以打开6891 后，6.0能给别人传文件了，4.7则依然不行