Wona Block Skype?? Will not be easy

The recent spate of Internet VoIP companies like Skype, Vonage and Net2Phone has fueled a political debate unforeseen as recently as five years ago. This controversy presents a new plot twist in the ever-unfolding soap opera of government deregulation and who has the right to the last mile of cable customers.
Traditional CLEC providers make the most of their money from residential phone and DSL lines. Now they are seeing competition from non-traditional companies that manage VoIP services in the very DSL lines funded by the traditional CLECs and cable providers. These groups of third line telephony services for their cables without a penny of revenue to the CLECs that provided the infrastructure.
If you are an intelligent reader to keep up with trade journals, is likely aware that this controversy has all the human interest voyeur normally reserved for the tabloids. Players do not have names like Pitt and Hilton, but instead of Skype, Qwest, Comcast and Vonage. You’ve probably seen several editorials and commentaries on two or more sides beating this subject to death.
For now, I will leave the debate alone. We will focus on the Operational Strategy: How to deal with specific traffic over a data line and how this may apply to the special case of Skype.
As CTO of APconnections, a company that specializes in bandwidth control and quality of service, I am well informed on the subject of competing carriers blocking traffic in data networks. I often wonder if we can find a solution to block (insert evil music here) â?? Skype?? traffic. Skype and Vonage have become the scourge of ISP service providers seeking to offer phone service for a fee along with their data services. The obvious conclusion for the owner of the data line is to block only these vagabonds of all and be done with it.
While the blocking of most data traffic is easily accomplished, I must confess from the beginning I feigned some efforts in blocking Skype only to retreat to fight another day after being defeated. What follows is a brief tutorial on blocking traffic, so easy for the casual reader of the technology. After covering the general case of traffic blocking we’ll cover the special case of traffic blocking Skype is a different animal.
Diving right into the mechanics of implementing traffic shaping by the first lesson is how to recognize traffic on a network. As you probably know, all Internet traffic travels through what is called an IP packet. An IP packet very simply be thought of as a series of characters who move from computer A to computer B. The string is called â?? Payload, â?? very similar to the transport of goods within a railroad car. Outside of this load, or data, is the address where it is being sent. These two elements, the address and payload constitute the entire IP packet.
In the case of different Internet applications would expect to see different types of payload. For example, take the example of a skyscraper being transported from New York to Los Angeles. How could this be done by using a freight train? Common sense suggests that it could dismantle the office tower that is in the greatest number of freight cars needed to transport, and then when the train arrived in Los Angeles waiting for workers at the other end are instructions on how to reassemble the tower.
Well, this analogy works with just about anything that is sent via Internet, only the payload is a data type, not a physical piece of brick, metal and wires. If we were to send a Word document as an email attachment, guess what, the contents of the document is removed in a lot of IP packets and sent to the receiving email client where it would be re-assembled. If I looked at the payload of each packet of Internet traffic, I could actually see fragments of the document in each packet and could easily read the words as he passed.
This is the basis of traffic blocking: Look inside Internet packets and see if you can say what they are. Conceptually, there is really nothing more than that.
Now going beyond the simple case of sending a Word file, let’s assume that we are sending a telephone call from user A to user B. How does that work in a traditional sense? Perhaps you’ve heard of SIP and H.323 VoIP protocols so common. We have to make a small conceptual leap in the example e-mail attachment to a mobile phone call live over the Internet, but I can assure you it is fairly painless. When sending a live stream of voice data over the Internet need parts of the phone call things scanned in a series of IP packets. Special equipment at the front of the phone call digitized voice data and feeds it into an IP packet, it sends, and on the other side it is understandable to join in the emulation of voice.
It is possible that a device to control the data going through the lines, categorize and display it. digitized voice data is very different from a Word file in the transport of digitized voice, because when it is displayed as ASCII characters like a garbled mess of goop. It is visible at random, so much so that there is no discernible pattern and can easily forget the words legible for humans.
So how would one say that the information is through an Internet connection is a voice call?
Before the invention of Skype, things are very simple. The good thing about all these standard VoIP solutions from Avaya, Toshiba, Cisco, and others is that you could see a very predictable human exchange between two extremes readable information just before the actual phone call. This is what is commonly called â?? Call set up. â?? Before calling a voice phone started it was common for the two phone systems to exchange data that mimics human conversation:
Team A: â?? Hey buddy, I’m going to send a call. â??
Response Team B: â?? Not now, I’m busy. â??
These procedures for establishing calls are sent back and forth within the IP packet in the form of human readable text very common. Although perhaps not as comprehensive as â?? Buddy? Hey, I’m about to call, â?? is often evident by reading the text what is happening.
Meanwhile, there are several automated devices designed by commercial firms that specialize in detecting all types of Internet traffic, including voice. Some corporations buy these devices intended to stop streaming audio, or perhaps to give priority to Citrix traffic.
The list of types of things and reasons to detect and give special treatment to data of different traffic flows is endless, and it would be an interesting topic in itself, but for now let’s go back to the detection of voice and the special case of Skype traffic. Scenario 1: Direct final point to end point of VoIP
If you recall, with voice calls once the call is in progress and ongoing data loading blob resembles confused and do not identify with one call. Therefore, it is important to see the implementation in action. The launch of the call between two IP phones is easily detectable. Recalling the IP addresses involved in the installation, you can safely assume that future traffic between two IP addresses is a phone call and block the traffic between the two. Scenario 2: Source of centralized VoIP
The above scenario involves two IP endpoints talking to each other. Another version of the VoIP phone service using a VoIP PBX. In this scenario all the phone calls come from a common PBX has a known IP address, so it’s only a matter of blocking all traffic to or from that IP address if you want to stop PBX voice traffic. Seeing such a network will provide a common IP address that always seems to be sending messages to identify common call set up other IP addresses. Once you know this, you only need to remember the IP address of one of the parties (central) and you can handle future calls. Scenario 3: Centralized Broker
In a third scenario of a central corridor is used to set the phone calls. This would typically involve a form of PBX in a contract between two VoIP phones to talk directly with each other. The centralized PBX is contacted by a party wishing to make a call. Then contact the fate of the parties to conclude the call. During the configuration process is negotiated could see the configuration of communications along the inside IP packets. The conversation goes something like:
Computer A running back: â?? Hi I would like to call my friend in Miami, but all I have is his name. Can you fix an IP call for me? Â??
Broker for team A: â?? Yes, just a second, I will look up. â??
Broker Team B: â?? Hey Miami, a phone in Los Angeles would like to make a phone call. . . â??
Well, you get the idea. The final call would again be a stream of garbled goop, but listening to the context of the facility could determine the two IP addresses to taking part in a phone call and the call block more traffic in the future between the two.
So you know my entire library of knowledge and secrets about how to detect VoIP traffic. It is time to move on to what I do not know about Skype.
Skype calls seem to speak from point to point when a call is finally set and active. This activity can be seen through the creation of Skype calls in my laboratory. Of course I know beforehand what the two extremes are, I can see Skype traffic whizzing by on my sniffer. However, when considering the flow have failed to see any discernible human call set up, so without prior knowledge of options, could never be sure if what I was seeing was a Skype call.
Skype configuration seems to take place with a stock broker, but the implementation appears to have no intelligible human readable pattern. Part of installing a Skype only appears as unreadable blob.
It appears that Skype uses a distributed topology where calls are made from a number of different actors in constant change. If Skype uses a stock broker I could learn the IP address of the corridor and therefore, I know no one talking to him is the creation of a Skype call. But without a common corridor and known, there is no generic way I can look for contact a broker.
To date, all my common tricks for determining the VoIP traffic on the Internet have been thwarted by the designers of Skype. I have no idea whether that was a deliberate attempt to avoid detection or just an unwanted side effect of their design. Perhaps a reader with inside knowledge will step forward and answer this and other questions. For now I have a lot in my plate, so I’ll leave the mystery of the detection of Skype for my peers.