Archive for the ‘VoIP’ Category

Better 802.1X support for VoIP phones and “network paperclips”

Monday, July 2nd, 2007

One of the recurring annoyances with many 802.11 client devices is that they don’t support the best security protocols. Wi-Fi Protected Access (WPA) has two modes: the Personal mode based on pre-shared keys, and the 802.1X-based Enterprise mode. Well-known weaknesses in the former are not present in the stronger Enterprise mode.

One of the troubles with the lack of support for 802.1X is that it causes headaches for network administrators who are concerned about security, but need some widget to build their networks that doesn’t support 802.1X. I have often labeled many of these devices “network paperclips” because they are small, often inexpensive, and frequently, do a great deal to hold networks together. This morning, Jon Oltsik, the founding father of the OpenSEA Alliance picks up on the theme:

While the PC space is well covered, there is a new network-security frontier out there that remains barren. What about Internet Protocol phones? What about mobile devices? What about network-based appliances like printers?

Jon is getting uncomfortably (for the industry at least) close to an open secret about the Wi-Fi certification, too. There’s no requirement to support 802.1X to get Wi-Fi certification, and it’s often hard to tell from the product packaging whether the 802.1X/Enterprise methods of authentication are supported, or whether the product only supports the quicker-and-less-secure PSK/Personal methods. The Wi-Fi Alliance is working on the issue of how to reduce end-user confusion about security capabilities.

What brought all this to the front of my mind this morning is the much ballyhooed iPhone. There’s been a great deal of excitement about the dual 802.11/cellular capabilities of the device to speak VoIP, but it’s dead on arrival as far as most corporate networks are concerned. In a message to the Salsa-FWNA group this morning, Michael Griego writes about the disappointing wireless LAN security support on the iPhone:

Yes, it lacks 802.1x support out of the box, supporting only PSK security mechanisms. I was personally surprised at this and expect/ hope that this will change in one of the surely-soon-to-be-released updates since it should require only adding the supplicant software to make it work.

(Background note: Salsa-FWNA is an Internet2 group that is defining methods of federated authentication across university campuses. The group is making extensive use of 802.1X, which prevents the current iPhone from doing VoIP across campus boundaries.)

Like Michael, I also hope that Apple is working on an improved supplicant for the iPhone. If the iPhone runs MacOS X, it should be a straightforward port of the existing supplicant.

Finally, I’d like to make an offer for anybody reading this. If you have a device that needs to support 802.1X, but you’re not quite sure what to do (or just need a royalty-free code base), contact the OpenSEA Alliance and we’ll work with you on customizing the software to your device. Sufficiently interesting devices will be “self-customizing” once our developers get their hands on samples.

Lessons from building the Faraday Cage at the Interop Labs

Tuesday, May 29th, 2007

With Interop over, it’s worth jotting down a few lessons about the Interop Labs Faraday cage. First, the results were better than I expected, given the difficulty of building a complete RF shield. Based on measurements we took using both test tools and laptop-based tools, it appears that our cage provided about 40-45 dB of shield, which is a good amount given our abbreviated time and limited materials budget. For comparison, the VeriWave test chambers are guaranteed to provide at least 80 dB of shielding (though the number appears to be much higher in practice).

  • 802.11 shielding: 40 dB of shielding is good enough to provide a substantial reduction in the number of visible APs. Even before the show started, it was possible to see 300 to 400 APs immediately outside the door of the cage. With the door closed, we could reduce that number to 20-30, which includes the four APs that were powered on inside the cage.
  • Mobile phone shielding: The cage did cause some signal loss for cell phone signals, but the service came through loud and clear. Occasionally, some phones would exhibit the loss of one bar, but I don’t believe there is a standard indication for what a bar means between vendors, or even between different phones from the same vendor.
  • Related to the first point, the team from DiVitas found the cage extremely useful. Their demonstration of an fixed/mobile convergence application depended on having “reasonable” 802.11 service to set up a call on 802.11, and then degraded service to hand the call over to the voice network. Our cage provided that without any difficulty, and even allowed people to hear that voice quality on 802.11 can be better than voice quality on cellular networks.

After going through the process, we did learn a few lessons:

  • Buy, don’t build. We had to spend lots of time fiddling with the cage, and there were complicated entry/exit procedures for making sure that the door was adequately screened. Various flaps had to be secured in particular ways to get maximum shielding.
  • Related to the previous point: Don’t buy from us. We had fun building it, but this is not a vocation for us.
  • Materials matter. The cage was made of aluminum screen because it is inexpensive material, but aluminium has properties that are suboptimal for a project like this. Aluminium naturally forms a protective oxide layer. In aerospace, that’s cool. In Faraday cage manufacture, it’s not. The aluminium oxide is an insulator, so we saw resistances across the outer mesh screen approach an ohm if the current had to cross sheet boundaries. Aluminium is a difficult material to work with, since it melts at 660 °C, but its oxide melts at 2054 °C. In practice, we were unable to join the metal sheets together directly because we didn’t want to try brazing (and we lacked equipment which could generate the requisite heat anyway); we ultimately settled for “sewing” the sheets together with copper wire as shown in the photos included with original post.
  • Complete screening is hard. Our first attempt was to keep the cage completely isolated from everything, with only a power drop. However, putting Ethernet cables in to the cage did not seem to change the screening effect at all. Ethernet is tightly twisted to resist carrying interference, but it can still act like an antenna. There are two possible conclusions: we did a perfect job putting the Ethernet in, or the cage leaked enough that there was no incremental penalty from the Ethernet cables. We’ll go with the latter choice.
  • As a sign that the cage leaked even without the Ethernet, we did not notice any difference between (1) no Ethernet cables, (2) one Ethernet cable, (3) one Ethernet cable with a snap-on ferrite core, or (4) two Ethernet cables, one of which had a snap-on core. For demonstration purposes, we put two cables in to the cage, but a “real” cage should take penetrations much more seriously.
  • Grounding didn’t matter. The electrical contractor set up a ground wire for us from the show electrical system, but connecting it did not make a difference in the effectiveness of the cage. Our suspicion is that the ground wire was good enough to act as an electrical safety, but that it had high impedance to the ground itself. In the end, we decided to leave it connected because it “looked cool.”

High-tech home ec: Building a Faraday cage at the Interop Labs

Tuesday, May 22nd, 2007

As part of the VoIP demo at year’s Interop Labs, we’re building a Faraday cage. Last year, I did some basic research into quality of service using WMM by recording voice samples over the air, using the wireless traffic at the show floor for background noise.

This year, the team wanted to do something a bit more controlled. We had questions about how well WMM worked when more than a single call was prioritized. To control for the many variables of wireless traffic on the trade show floor, we needed to isolate the VoIP testing from everything else. During the staging event, Jed Daniels built a prototype Faraday cage to keep the show floor out, and our background traffic in.

Building a walk-in cage is a lot harder than building a small prototype. Faraday cages work best when they are a single conductive surface, but the walk-in cage was big enough that we had to join sheets of mesh. To improve conductivity between panels, we wound up “sewing” sheets together with copper wire.

Needles are not well designed for pulling wire through a small-aperture mesh, so we needed to sew in two-person teams. Here’s me working with Jed, pulling copper wire through the mesh as we sew along the base:
Sewing the cage, outside view

Here’s the reverse view, looking over Jed’s head towards the outside.
Sewing the cage, inside view

Here’s a shot of the final result, with Jed and an engineer from Veriwave working on the test tool to generate controlled background traffic for our demonstrations:
Jed in the cage

Finally, after all that work, we felt the need to “make our mark,” so all the people who worked on the cage sewed initials in to the front panel:
Initials in the cage
(From the upper left to the lower right, the initials are Jed Daniels, Mike McCauley, Matthew Gast, J.J. McNamara, Jerry Perser, Bill “WEJ” Jensen, and John Balogh.)

Secure VoIP demonstration at Interop

Wednesday, May 16th, 2007

Last month, the Adminsistrative Office of the United States Courts released the 2006 wiretap report (main report in PDF format). There are two extremely interesting points.

First, the third paragraph of the introductory page, which reads:

Public Law 106-197 amended 18 U.S.C. 2519(2)(b) to require that reporting should reflect the number of wiretap applications granted for which encryption was encountered and whether such encryption prevented law enforcement officials from obtaining the plain text of communications intercepted pursuant to the court orders. In 2006, no instances were reported of encryption encountered during any federal or state wiretap.

(Steve Bellovin, via Eric Rescorla.)

Second, on page 11 of the PDF (under the section “Summary and Analysis of Reports by Prosecuting Officials”), we learn that the federal government doesn’t encounter computers all that often:

The electronic wiretap, which includes devices such as digital display pagers, voice pagers, fax machines, and transmissions via computer such as electronic mail accounted for less than 1 percent (13 cases) of intercepts installed in 2006; 6 of these involved electronic pagers, and 7 involved computers.

For comparative purposes, the report notes that 1,839 wiretaps concluded in 2006.

Most voice communications are not encrypted. The exception is mobile telephones, which are encrypted only on the radio link. (Mobile phone wiretaps, however, generally take place at the switching office, where the voice traffic is not encrypted.) This certainly includes most VoIP calls today, and is a reason that is often cited for the lack of use of SIP-based services on corporate networks. Most VoIP data is transmitted using the Real-Time Protocol (RTP), which does not encrypt payload data. The Secure Real-Time Transport (SRTP) offers a potential solution, and implementations are now available.

After that very long introduction, I’d like to point out that the Interop Labs next week will have an interoperability demonstration featuring SRTP. It’s open to the public, so if you happen to be on the show floor, stop on by!

As a completely shameless plug, you can also see the Open1X supplicant in the iLabs, which is now supported by the newly-formed OpenSEA Alliance.

My ideal 802.11 phone

Tuesday, February 13th, 2007

This is an idea that’s been percolating for a while, but Dameon’s recent rant about how VoIP hardware is boring has triggered two responses.

One is that I have started explaining what I do with VoIP to the rest of the world as, “I have become my own telco.” If I want a service, I can define and implement it myself, without needing to wait for a big market to develop and catch the eye of the telco. (I did this recently to make Asterisk handle incoming telephone calls in a time-aware fashion for my international travels.)

But, more on point, I’m also excited by the proliferation of wireless LAN phones. The dual-mode phone is a way of communicating traditionally (with the cell side of the device) as well as with services that I can define myself (with the 802.11 side). Unfortunately, most of the phones on the market are hardly interesting. Here’s my “hit list” of features that you have to implement to make me pay attention:

  1. WPA(2). This shouldn’t even be hard at this point. We’ve worked out all of the kinks from these protocols, and there are multiple open-source implementations. There is no excuse for bringing any wireless LAN device to market that doesn’t support good security in 2007.
  2. WMM. Last year at Interop, I was able to demonstrate that WMM can give you voice quality, even with significant background traffic. There are plenty of reference designs from hardware vendors that do WMM. Selecting only WMM phones drops you to just eight Wi-Fi Certified devices.
  3. PMK caching. This is an under-appreciated feature that was part of the 802.11i amendment. It’s a way of saving master keys to cut down on roaming times. Combined with the “opportunistic” version that establishes master keys on APs before it’s needed, you can get some impressive handoff times between APs, and you’re hard pressed to hear a difference.
  4. U-APSD. This is an acronym for Unscheduled Automatic Power Save Delivery. Anybody who’s used an early 802.11 phone has undoubtedly noticed that the battery life is, to put it nicely, awful. U-APSD works keep the 802.11 radio powered down when it’s not used, so that almost all of the 802.11 radio (and power) usage is devoted to transmitting voice. Anecdotally, it can extend battery life by 50-100%, but there are so few implementations I can’t speak from a wealth of data.

Naturally, even after you get to the end of this list, there’s a lot more that can be done, but it’s relatively small potatoes compared to the big four. There are some further quality of service parameters that can be used to help an 802.11 phone in a big network select the right AP to go to, and there are some features that help further smooth out handoffs. To be honest, there are so few phones that can get to #2 on the list that I’m not worried about writing up #5 through #10.

Ignoring SIP redirect messages from the Cisco 7912

Saturday, January 27th, 2007

A few months ago, I started using a Cisco 7912 with my home Asterisk system. It’s a much nicer phone than most analog sets you can buy. Furthermore, it is a pure IP phone and therefore doesn’t have the same echo problems as my analog phones hanging off ATAs.

However, there is one frustration. The phone attempts to be smart, and will redirect calls to voice mail after four rings if the voice mail number has been configured. Generally, it’s a nice feature, but it can be quite annoying when I have the Asterisk-powered doorbell ring the 7912. The procedure goes something like this:

  1. Somebody presses the Doorbell Fon, which creates a call into an FXO port on my Asterisk server.
  2. Asterisk handles the call, either by ringing a group of extensions directly, as in Dial(SIP/cisco7912&SIP/others), or by ringing all extensions in a queue.
  3. All the phones that are targets in the queue or Dial application ring. On the fourth ring, the 7912 gets smart and decides to send the call to voice mail.
  4. Upon receipt of the SIP redirect message, Asterisk sends the call to the voice mail extension. However, without knowing what mailbox to send to, Asterisk prompts the user. On a Doorbell Fon, there is only one button and no way to interact with the phone.

While redirection to voicemail may generally be a useful feature, four rings doesn’t make sense for a doorbell, especially if the 7912 causes the call to be sent to voice mail and prevents other extensions from answering it. What I would really like Asterisk to do is to ignore SIP redirect messages. (I can think of many applications where you’d want Asterisk to do the call processing without regard to what client devices tell you to do, especially if you might be liable for the resulting toll charges.)

It turns out that there’s an experimental flag to do this in the Dial application. In Asterisk trunk, there’s a small bit of code that allows you to pass the “i” option to Dial to instruct Asterisk to ignore SIP redirects. I’m still running the 1.2 release, so I don’t have this option just yet. I suppose it is just another reason why I am looking forward to my upgrade from Asterisk 1.2.

Cisco 7912 ignores DNS servers in DHCP assignments?

Saturday, December 23rd, 2006

My initial experiments with VoIP were all behind my firewall. Now that I want to have Asterisk interact with the rest of the world, I need to follow the Interop Labs 2006 advice and keep NAT away from VoIP because they don’t mix. I’m redesigning the integration of VoIP into my home network. I’ve moved my Asterisk server on to a DMZ where it now has a routable IP address.

One of my VoIP devices is a Cisco 7912 IP phone. Even if I’m willing to put a fortified (and firewalled) server outside the firewall, I still plan to keep VoIP devices inside. To make the phone aware of the new server address, I went into the phone configuration and changed the SIP server from its old IP address inside the firewall to a DNS name outside the firewall. When the phone restarted, it stubbornly refused to register. By looking at SIP debugging on Asterisk and firewall logs, I could tell that the phone was not sending the initial SIP registration message to the server. Moreover, I could tell it wasn’t even trying to look up the name I had entered for the SIP server. When I replaced the name with the IP address stored in DNS, everything worked just fine. Fortunately, I don’t plan to be changing my server’s address any time soon, so I can live with this small annoyance.

Initial investigations on hooking up Skype to SIP with Asterisk: NCH Uplink, ChanSkype, and PSGw

Monday, October 30th, 2006

I’ve been playing around for the past couple of weeks with Skype-to-SIP adapters so that I could set up a Skype trunk with my home Asterisk server. No matter what your feelings on the proprietary Skype approach, it does deal with NAT quite well, and that may be important if you are on a single dynamic IP address connection. I’ve also been interested in integrating Skype into the Asterisk setup since the announcement of free outbound calling through the end of 2006. Although there are $1,000 Skype-to-PBX bridges, I am not interested enough in Skype connections to spend more money than my Asterisk server hardware cost. For my investigation, I looked at three “personal-scale” products:

All three products take the same approach. Each product is composed of a SIP interface component and a Skype client control component that uses the Skype API. When a call comes in to one half, it is directed to the other half, typically by redirecting the audio streams from the speakers through an operating system conduit. PSGw uses the term software audio cable, which is the best description.

Uplink Skype to SIP

NCH Swift Sound is an Australian company with expertise in computer-based audio and a few VoIP-related applications. Uplink’s installer offers you the Axon PBX, though it’s not necessary when you plan on using Asterisk. Uplink is a Windows application, and has a $40 price tag for license, though free downloads are available.

I already run one full-time PC for Asterisk, and I didn’t want another one just in case somebody decided to Skype me. My first approach was to try running Uplink in VMware, though I quickly abandoned that when it became clear just how much the VMware emulation layer would require in terms of resources. When the Windows VM needed CPU time, it dramatically affected performance of the applications running under Linux. The sound quality was awful, too. At first, I wondered if the sound quality was due to resource constraints on the shared system, so I ran Uplink on a separate machine. Although sound quality improved, the audio was still not anywhere near conversational quality. It was interrupted by frequent drops and hesitations. The only reason that I could make out what was coming through the telephone is that I had recorded the voice prompts myself.

To correctly get Skype to call out to a phone number, there’s a bit of phone number massaging required. Skype expects a call out number to be done in the international telephone style (+1415…), so you’ll need to add the plus sign on. To dial a skype user from the telephone keypad, you’ll also need to set up a mapping between a number and the name. Here’s some example dialplan code that does both. (Uplink is set up to register with the peer name “skype”.)
//Use “09” as a Skype outbound trunk
//Add leading “+” on to 1-NPA-NXX-XXXX number
_091NXXXXXXXXX => {
Answer;
Dial(SIP/+${EXTEN:3}@skype,60,);
};
// Map 09-888 to echo service
_09888 => {
Answer;
Dial(SIP/echo123@skype,60,);
};

Plus:

  1. The easiest setup of the three applications I tested. Uplink installs like any other Windows application, and its configuration is well thought out. It also shows reasonable debugging information as it runs, so it’s pretty easy to see what’s going on inside.

Minuses:

  1. Windows-only solutions require a second box with Linux-based Asterisk systems. (This may be offset if you have a powerful enough machine to run VMware, but my VMware installation bogged down on a 1.6 GHz AMD Turion64 with 512 MB RAM.)
  2. Poor sound quality, regardless of whether Uplink runs in a VM or on an external machine.
  3. Poor call supervision. Frequently, Skype would stay connected even though Asterisk had sent a BYE message to the SIP side of Uplink. I had to fix this by hanging up in the Skype GUI.

ChanSkype

Note: The following applies to an old version of ChanSkype. Last Wednesday, they released version 1.2, which could address one of my major concerns.

ChanSkype was announced in early October by a Brazilian company. The approach is perhaps the best of any of these products because it makes Skype instances appear as channels, rather than trying to control clients directly with a co-resident SIP gateway. It has the ability to use multiple Skype instances as outbound trunks from the same machine, which is a unique capability within the products that I looked at.

Configuration of ChanSkype was the most in-depth of any of the products. None of it is particularly hard, and the company provides quite good documentation. My two big challenges were the general configuration complexity, as well as the fact that the channel driver is provided as a 32-bit binary driver and can’t be dynamic linked into a 64-bit Asterisk.

The configuration complexity comes directly from the approach that the product takes. Several instances of the Skype client are each run by using VNC as the display. With several VNC instances running, each Skype client can function as an outbound trunk that is directly addressable by the channel driver. Unfortunately, even if you only want one Skype instance, it still requires VNC.

To set up outbound calling, you’ll need to add the plus sign on to the front of the number, as in the following dialplan code:
//Use “09” as skype trunk
_091X. => {
Answer;
Dial(Skype/any/+${EXTEN:3},60,);
};

I had trouble with one-way audio during this test, though I believe that was due to NAT on my own network, and a SIP security device that I am using.

Pluses:

  1. ChanSkype had by far the best audio. The inbound audio when making a telephone call was nearly perfect, though it was hard to tell from the 15-second per-call limit that is embedded into the channel driver.
  2. Unlike the other two products, this one is capable of sending multiple Skype streams outbound because it runs multiple clients simultaneously. This is hard to test with a 15-second call limit, though.
  3. The best integration into the dialplan. Because ChanSkype is a channel driver, it’s easy to say Dial(Skype/skypeinstance/number) and let the channel driver figure out who’s free.

Minuses:

  1. This was the most complex configuration. Even if you only want one outbound Skype trunk, it requires running a VNC server for that client.
  2. If you run Asterisk on AMD64, there may be some extra work to get the 32-bit channel driver running. I run Asterisk on Gentoo, and found that recompiling Asterisk as a 32-bit application is sufficient because there is a wide range of compatibility libraries that can be used. (In talking with the company, I discovered they plan to release a 64-bit version.)
  3. ChanSkype doesn’t take inbound calls. If your purpose is to get cheaper outbound calling, this may not be a problem for you. (Note: ChanSkype 1.2, announced on October 25, lifts this limitation.)

Personal Skype Gateway (PSGw)

PSGw is one of the oldest Skype-to-SIP converters. Although it started on Windows, it was ported to Linux in July of this year. Because of my preference for a single-machine solution, I worked with the Linux version. Like ChanSkype, the Linux PSGw is distributed as a 32-bit application. On my system, however, there are repeated segmentation faults if it is run with 64-bit libraries.

PSGw requires a separate IP address from Asterisk to avoid port conflicts. I solved this with a secondary address on the main network interface, but this may not be possible if you don’t have enough routable IP addresses, or a way to keep the PSGw-to-Asterisk connection from going through a NAT. (At the Interop Labs earlier this year, we found that SIP and NAT don’t mix.)

Once I had successfully installed PSGw, it was easy to start. When I made my first call, PSGw mapped the call from SIP on to Skype and promptly died. As far as I can tell, the premature death was due to a library conflict. On Linux, the Skype API runs over D-Bus, and a key dynamic library used by PSGw is distributed as a 32-bit object. I was able to solve the problem by building a 32-bit chroot area, though that’s definitely not for the faint of heart. (To get Skype running in the 32-bit chroot, I needed to have a second, 32-bit version of the libraries it depends on, as well as the sound daemon used by KDE.)

Even once the 32-bit chroot was in place, there were problems with PSGw staying up if I permanently authorized PSGw to use the Skype API. To revoke the authorization, remove it from the config.xml file for the user you sign on as. Look for this line, and take out any programs that are authorized:



Pluses:

  1. By far the best call supervision. When Asterisk hung up, PSGw would terminate the Skype call. There was never a call leg that stayed up longer than its counterpart.

Minuses:

  1. Most complex setup on AMD64 due to the apparent requirement for a 32-bit chroot. (This isn’t documented anywhere, but the program crashed a lot until I put it into a 32-bit chroot.)
  2. Extremely poor call quality. I couldn’t tell that it was relaying human speech.

Closing thoughts

Based on my testing, ChanSkype seems like the most promising approach. I’ll try the recently-released 1.2 version, and report back.

In the future, it may be possible to use something likethe recently-announced Philips VOIP841, which would seem to offer the ability to be a Skype-to-analog converter that doesn’t require a computer. (Philips also announced Netgear would deliver a PC-less Skype phone.)