Yes it is, he is directly above his router and his internet browsing hasn't been affected.

Yes it is, he is directly above his router and his internet browsing hasn't been affected.
Non-UPnP NAT Devices
Windows Messenger peers, separated by a NAT device that cannot be detected, should be able to use IM and Presence information. 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 information 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 do 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.
Edit: Its dodgier on Msn 7.5 and 8,
It works fine on MSN 7
Last edited by Cells; 01-10-2008 at 10:03 PM.
*\l/*/\Cheerleading is for men.
Want to hide these adverts? Register an account for free!