One of the more interesting aspects of ipDTL is how it creates what's known as a peer-to-peer connection between the source computer and the recording computer. This type of connection is unique in that it finds a way to get through the firewalls that invariably exist on both ends of a Voice Over IP (VOIP) connection.
In an ideal world, your computer (the source, with your microphone attached as its input) would be able to talk over the internet directly to the computer that was to record that microphone signal. To accomplish this, your computer establishes a connection with the recording computer using TCP (Transfer Control Protocol) packets, which contain all the necessary setup information both computers require to create a bi-directional multiple-handshake connection with each other. Communication using TCP packets requires that each packet sent is acknowledged by the receiver, to ensure that the connection is both fast and secure, which of course slows down the initial communication between the two computers. However, once that connection is completed, your computer switches to sending the far simpler UDP (User Datagram Protocol) packets, which require no such acknowledgement from the receiver and thus can be sent and received far more quickly than can the TCP packets. The conversation between the sender and receiver continues to occur quickly using UDP packets, with TCP packets sent only occasionally to monitor the continuity of the connection. If and when the TCP packets are not acknowledged by the receiver, then the source would begin sending the necessary information to restart the conversation with as little packet loss as possible.
Sometimes ipDTL can make a clear peer-to-peer connection between the source computer and the recording computer. When it can do that, it does. When it cannot, well, it goes to plan B. Because unfortunately we don't always live in an ideal world, the internet can be a dangerous place full of bad actors attempting to do bad things to our computers and connections. For safety's sake, our computers run firewalls and obfuscated IP addresses to prevent those bad actors from doing bad things on our machines. However, those firewalls make creating a peer-to-peer connection between our computers more difficult, as they obfuscate and block direct connections between our computers (performing a function called Network Address Translation, or NAT). The methodology for overcoming these little bumps in the road, when they exist, usually involves engaging another server, which connects the source and recording computers to each other by accepting incoming packets from both machines and then routing them.
This is the purpose of servers that Skype uses for everything from routing packets to checking on the "heartbeats" of a communication session. ipDTL performs the same routing and monitoring. Interestingly, Skype uses primarily its users' servers, at least those that have static IP addresses, as "volunteers" to perform these necessary tasks. ipDTL has its own servers in the UK, Europe, and some in the US to perform similar functions. The majority of those servers are in the UK at the moment, but In:Quality promises that new servers are coming online in the US on a regular basis, concurrent with the increase in US users. The more servers available, the quicker and more capable the connections between audio source computers and recording computers, when both are utilizing ipDTL. With the high need to keep computers behind tight firewalls, the need for ipDTL servers to be available to "punch through" firewalls becomes more important than ever for good performance.
♦
