Discover Habbo's history
Treat yourself with a Secret Santa gift.... of a random Wiki page for you to start exploring Habbo's history!
Happy holidays!
Celebrate with us at Habbox on the hotel, on our Forum and right here!
Join Habbox!
One of us! One of us! Click here to see the roles you could take as part of the Habbox community!


Page 3 of 3 FirstFirst 123
Results 21 to 23 of 23
  1. #21
    Join Date
    Mar 2005
    Location
    Peterborough
    Posts
    10,267
    Tokens
    2,710
    Habbo
    Esurients

    Latest Awards:

    Default

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


  2. #22
    Join Date
    Sep 2007
    Location
    Blackpool
    Posts
    8,200
    Tokens
    0

    Latest Awards:

    Default

    Quote Originally Posted by You View Post
    Yes it is, he is directly above his router and his internet browsing hasn't been affected.
    No, it's nothing to do with that, I can't explain it!

  3. #23
    Join Date
    Sep 2008
    Location
    Suffolk
    Posts
    143
    Tokens
    0

    Default

    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.

Page 3 of 3 FirstFirst 123

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •