Hack38.Test Your Connection for Skype Friendliness

Hack 38. Test Your Connection for Skype Friendliness

Skype's performance depends somewhat on how P2P friendly your network is. Find out with these tools.

Works with: all versions of Skype.

Before testing your Internet connection for Skype friendliness, it's worth summarizing what an ideal P2P-friendly connection should look like:

• Outgoing TCP connections should be allowed for remote ports 80, 443, and 1024 and above.

• Outgoing UDP packets should be allowed for remote ports 1024 and above.

• NAT should retain "state," which means that translations should be remembered for a period so that other packets can reuse them. Ideally, state should be kept for an hour or more, but even maintaining state for 30 seconds will improve things.

• Multiple ports (both TCP and UDP) can be used in parallel.

UDP packets are the preferred method of communication for most P2P applications, including Skype, because they are fast and less demanding (than, say, TCP) on network resources. Skype can work without using UDP, but call quality suffers.

A quick and easy way to test the P2P friendliness of your network connection is to use a neat little tool called NAT Check, which is freely available for Windows, Linux, and Mac OS X from http://midcom-p2p.sourceforge.net/. NAT Check gives a summary of useful information, which is indicative of the friendliness, or unfriendliness, of your network connection to P2P applications in general, and to Skype in particular. Here's an example of output from NAT Check:

Table 3-2.

TCP	RESULTS:
TCP	consistent translation:	YES	(GOOD for peer-to-peer)
TCP	simultaneous open:	YES	(GOOD for peer-to-peer)
TCP	loopback translation:	NO	(BAD for P2P over Twice-NAT)
TCP	unsolicited connections filtered:	YES	(GOOD for security)
UDP	RESULTS:
UDP	consistent translation:	YES	(GOOD for peer-to-peer)
UDP	loopback translation:	NO	(BAD for P2P over Twice-NAT)
UDP	unsolicited messages filtered:	YES	(GOOD for security)

The preceding output was generated on Windows by running the command natcheck > p2p_test.txt in a command prompt window. After the command has finished running, you can find the results of the test in the file p2p_test.txt.

As a mini-guide to interpreting the output from NAT Check these notes may be of some help:

Consistent translation

Tells you if state is maintained. If "YES," input and output ports are the same for consecutive packets, thereby reducing network overhead.

Simultaneous open

P2P applications, Skype included, typically perform better if they can operate over several ports at once. A "YES" here tells you that multiple ports can be used without a problem.

Loop-back translation

In twice-NAT, both the source and destination addresses are subject to translation as packets traverse NAT in either direction. A "NO" here means that your machine cannot communicate with other hosts on the same private network using public (translated) port bindings assigned by the NAT.

Unsolicited messages filtered

This tells you whether packets originating from an unknown source are discarded. A "YES" here is good from a security point of view (errant packets are blocked) and in terms of network performance (discarded packets no longer consume network resources).

An alternative to running NAT Check on your machine is to look up on the Web whether your firewall/router/NAT is P2P friendly from a list maintained at http://bgp.lcs.mit.edu/~dga/view.cgi. This is an inferior method to running an actual test on your machine, but it might provide some quick answers. If your device is listed, look at the entry in the UDP Consistent Translation column, as a "yes" here will most likely mean that your network connection is P2P friendly.

Lastly, it's preferable for your network hardware to support packet fragmentation and reassemble. Though not essential, this feature will improve call quality.