*scottstuff*

According to The Register, Cisco is currently adding encryption abilities into their phones and call manager software. The article’s kind of hard to follow–it claims that the 7960G currently has encryption support, which is news to me–but the general gist is that they’re planning on adding some sort of direct VPN support into most of their phones via software upgrades.

Knowing Cisco, the feature will be implemented in some odd manner (L2TP+1DES IPsec in the phone?) and will only work with the CallManager-specific SCCP image for the phones, not the SIP image.

On the other hand, if they actually added TLS/SSL support for SIP and SRTP, then that’d be a huge motivation for getting encryption in Asterisk.

I’ve been looking for a Bluetooth plugin for Asterisk for a while, so my home Asterisk server can pick up incoming calls to my cell phone and route them onto my home phone network. I’m certainly not alone in this–it comes up monthly on the Asterisk-users mailing list.

It looks like the wait is nearly over–Theo Zourzouvillys announced a bluetooth driver for Asterisk this morning. It’s apparently still rough around the edges, and it’s only been tested with a single model of phone, but it works for him now, and the Asterisk community is pretty good at picking up things like this and enhancing them.

I’m going to play with this this weekend and see if I can get it to work with my T616; if so, it’d be a nice addition to my home phone system.

Asterisk 1.0 appears to have been released. I haven’t seen an official announcement on the mailing list, but apparently it was announced in person at this week’s Astricon convention.

If you want to download it, it’d be best to use a mirror.

Most likely, only minor changes have been made since the latest release, 1.0-rc2.

As I mentioned before, Linksys is now selling cheap SIP analog telephone adaptors using a design licensed from Sipura. There was a long-standing question about the Linksys PAP2: does it only work with Vonage, or will it work with any SIP provider?

Initial reports were spotty–some people claimed to have their PAP2 working with Asterisk, while others found their PAP2 automatically connecting to Vonage. According to a few posts on the asterisk-users mailing list, the answer is tied to the model number: if you get the PAP2, you might be stuck with Vonage. If you buy the PAP2-NA, then you’ll end up with a provider-agnostic device. They’re both around $50, although the -NA is currently harder to find.

I had a little problem at work last week: I needed to test a dial-in modem, but I didn’t have a pair of phone lines to use for testing. Our rented office space comes with a PBX, but they’d probably charge us a couple hundred bucks to wire up a pair of analog ports for us, and then take a week or two to do it. Alternately, there’s a bunch of stuff on the market that you can buy for this sort of testing, but considering what it costs, it’s kind of pointless for us.

Instead of doing that, I was able to rig up a testing system using Asterisk and a bit of equipment that we had sitting in the lab: a Cisco 3640 with a 2-port FXS VIC. Going into this, I wasn’t sure how long it’d take–I’d never set up voice services on any Cisco devices before, so I wasn’t sure how big of a pain it’d be. I figured it’d take me most of a day to get it set up and working. As it turned out, the first phase of the project, setting up Asterisk and the Cisco, only took a hour. Installing Asterisk 1.0-RC2 only took a few minutes, and configuring the Cisco to talk to Asterisk was fairly painless. I didn’t have a test phone (or even a modem) handy yet, but I was able to use X-Lite to call Asterisk and watch the phones ring on the Cisco.

The second phase was supposed to be easier: wiring up a serial modem to a test device, and then plugging my laptop and the serial modem into the 3640. And that’s where everything fell down. While I could dial into the Cisco FXS ports without problems, I couldn’t dial out from them. In fact, I couldn’t even get the ports to go off-hook–the Cisco never even noticed that I’d picked up the phone. After reading half of cisco.com, I concluded that the IOS version that we were using must just have been broken and upgraded to a newer release. And that was all it took–everything worked perfectly as soon as the 3640 finished rebooting.

For reference, here are the Cisco config snippets that I needed on the 3640. The two FXS ports are 1/0/0 and 1/0/1. I’m calling them extension 3001 and 3002. Here’s the config:

voice-port 1/0/0
 signal groundStart
 station-id name PORT 1
 station-id number 3001
!     
voice-port 1/0/1
 signal groundStart
 station-id name PORT 2
 station-id number 3002
!     
dial-peer voice 1 voip
 destination-pattern ....
 session protocol sipv2
 session target sip-server
 codec g711ulaw bytes 80
!     
dial-peer voice 2 pots
 destination-pattern 3001
 port 1/0/0
!     
dial-peer voice 3 pots
 destination-pattern 3002
 port 1/0/1
!     
sip-ua
 retry invite 3
 retry cancel 2
 sip-server ipv4:10.0.0.1:5060
!     

Here’s the Cisco part of Asterisk’s sip.conf:

[3001]
type=friend
username=3001
host=10.0.0.2
context=intern
canreinvite=yes
dtmfmode=inband
qualify=1000

[3002]
type=friend
username=3002
host=10.0.0.2
context=intern
canreinvite=yes
dtmfmode=inband
qualify=1000

And finally Asterisk’s extensions.conf:

[intern]
exten => 3001,1,Dial(Sip/3001)
exten => 3002,1,Dial(Sip/3002)
exten => 3003,1,Dial(Sip/3003)
exten => 3004,1,VoiceMail(3004)
exten => 3005,1,VoiceMailMain(s3004)

Oh, wow. CNET just mentioned a startup that’s aiming to run VoIP over SSL VPNs:

Net6 has developed technology that it says will get voice and video traffic to its destination securely and without delays. The way the technology works is that the Net6 device sends false TCP acknowledgements so that the sender continues sending packets. Murli Thirumale, Net6’s chief executive officer, admits that some packets may be lost along the way, but he said that has little effect on voice quality.

Oh, ouch. There is a fundimental mis-match between SSL VPNs (which tunnel traffic over a TCP connection encrypted using SSL) and voice over IP, which uses UDP packets. TCP, while generally wonderful for moving data from point A to point B, really sucks when latency is important, because it handles packet loss by stopping new traffic and patiently retransmiting the lost packet until it’s received. That’s exactly what you want for email or web browsing, but it destroys VoIP, because it’ll produce a big dead spot in the middle of the conversation, followed by a huge lag for the rest of the connection. You’d much rather have the network just forget about dropped packets and move on, and that’s basically the antithesis of TCP’s whole design. So, you really don’t want to use TCP for VoIP conversations.

For better or worse, SSL VPNs have been taking hold lately, mostly because IPsec VPNs are a total bastard to configure. SSL is a lot easier to work with, so SSL VPN companies have been getting a lot of buzz. VoIP has also been getting a lot of press (and VC) interest, so I suppose it’s natural for someone to come along and try to combine the two–it’s buzzword heaven. The only problem is that they mix like oil and water. In order to get things to work, you need to rip out most of the core of TCP and replace it with something evil.

Fortunately, the company in question has patented their approach; hopefully they’ll be aggressive enough with their patent to keep anyone else from even thinking about doing something this dumb.

For what it’s worth, there are actually a couple specs for integrating SSL and SIP directly. First, you can use SSL and TCP directly for the call setup side of SIP. Since the call setup doesn’t actually carry any voice traffic, TCP’s packet loss behavior isn’t a problem. Then, once the conversation starts, you can use encryption inside of the RTP packets that carry the voice call. Unfortunately, neither spec is widely supported yet. There have been rumors of an Asterisk implementation for almost a year, and I’m only aware of one phone that directly supports encryption: the Zultys 4x4.

WiFi Networking News is reporting that an industry group is building specs for roaming between WiFi and GSM networks. The group includes most of the big players: Nokia, Sony Ericsson, Motorola, T-Mobile, Cingular, AT&T Wireless, Alcatel, and others. The “Unlicensed Mobile Access” (UMA) spec is supposed to make it possible for users to use a WiFi-enabled cell phone and have calls seamlessly handed off between GSM, public WiFI, and private WiFi networks.

Personally, I’d love to be able to roam between my home wireless/VoIP network and the cellular network, and at least in theory that’s what this group is working on, but I have real doubt about any of the carriers implementing this in any reasonable manner. I can’t see any obvious business case for them letting users migrate calls off of the carriers’ high-priced networks and onto low-cost private networks. If wireless rates free-fall, like some have predicted, then it’s possible that they could use this to prop up their revenue, but that’s about the only case that I can see for it–most carriers seem very determined to keep people from migrating traffic off of their networks in any way, shape, or form. Witness the Verizon Bluetooth Debacle for an example–the carriers don’t seem to have a problem with working against their customers best interests. As consolidation continues in the industry, I fully expect to see more cartel-like behavior on their parts, and less innovation and flexibility.

One of the more frequent complaints that I’ve heard from people dropping their POTS line and moving to pure VoIP is that their TiVo stops working. TiVos have a modem in them. They need to download program guide information at least once every two weeks, and modems don’t work well over VoIP. There are ways around this–newer “Series 2” models have a USB port and support wired and wireless Ethernet adapters, and older models can be hacked with ”TiVoNET” cards that provide an internal Ethernet port. The problem is that TiVoNET cards are expensive and require opening your TiVo and voiding its warranty.

I think I have a unique way around this. It requires a local Asterisk server, a spare FXS port, and a modem, but I don’t see any obvious reason why it wouldn’t work. Since I have a series 1 TiVo and I’d like to drop my home phone line, I’ll probably check this out soon.

Here’s what needs to happen:

1. Connect the modem to your Asterisk box’s serial port. Install a getty that understands PPP (I’ve used mgetty in the past), and configure PPP to allow users to connect without a password. Turn logging up as high as possible.
2. Connect the modem to a dedicated FXS port on the Asterisk server.
3. Plug your TiVo’s modem into a different FXS port on the Asterisk server.
4. Force a connection attempt on the TiVo. Watch Asterisk’s logs to see what number it’s dialing.
5. Set up your dial plan in extensions.conf to map TiVo’s phone number onto the modem’s FXS port.
6. Have the TiVo dial again. It should connect to your modem instead of TiVo’s servers.
7. Using the PPP logs, fix things so that it actually logs in correctly.
8. Force another connection. At this point, it should log in and start exchanging IP packets with TiVo’s servers. Verify that it’s able to complete a full download.
9. Turn down logging on pppd.

It’s not particularly simple, but it should work, and you can do it without adding hardware to your TiVo. You’ll have to purchase at least one extra FXS port, possibly two, and they start at $50 for two and go up from there. Since TiVoNET cards start at $70 or so, this may not be a great deal, but it’s definitely good for hack value.

I’ve been using NuFone for VoIP connectivity since I first turned up Asterisk at home. I’ve been very happy with their service–in almost 5 months, I’ve never noticed an outage–but their support system has been driving me crazy. It’s been taking me 3 or 4 requests before I get a single response from them. Once I get in touch with them, they’re fast and efficient, but getting them to talk to me in the first place is been like pulling teeth. Reading the asterisk-users mailing list shows that some people have my problem, while others enjoy good support.

I think I figured it out. When I send them mail from my home email account, I don’t even get a reply from their automated tracking system. When I send them mail from my work address, I get a reply back almost immediately. Problem solved: their email system doesn’t want to talk to mine, but it’s okay with work’s. Most likely, they found a spam blocking list that puts me in the middle of ISP space, even though I’m really in a business DSL block.

Hopefully we can get this fixed soon.

Update (9/1/2004): It’s been a week, and I still haven’t heard back from them. However, I seem to have acquired a new 800 number–a call to some number I’d never seen before showed up in my Asterisk logs last week. So, my theory has changed a bit: my mail is reaching them, but theirs isn’t reaching me.

Either that or they’re completely uninterested in talking to me.

So, last night I sent a message directly to a couple staff members there pointing out the weirdness. I asked them to call me back on one of my 800 numbers. Tomorrow, if I don’t hear back, I’ll try IRC, followed by a call to their support number.

And if that fails, I’ll start looking for a new vendor. I may be a piddly little customer, but Google likes me. I’m the fourth site returned when searching for ‘NuFone’.

Update (9/16/2004): They seem to have fixed whatever was broken. I sent them two more requests this morning and they were both answered within minutes. This is a great improvement. At this point, I don’t mind recommending their service to others.

I’ve been predicting this for months, and it looks like it’s finally happened: the commodity-networking companies are starting to do VoIP. Yesterday, both Netgear and Linksys announced deals with Vonage.

I haven’t seen any hardware specs from Netgear yet, but Linksys has two products; a wired router and a standalone FXS-to-SIP gateway. Apparently, the Linksys hardware uses Sipura’s technology, but sells for less then Sipura’s more-or-less equivalent hardware. At a list price of $59, Linksys’s PAP2 is the cheapest SIP adapter on the market. Heck, staples.com has it in stock for $49, and Vonage will rebate $40 of that if you sign up with them.

D-Link has a similar product on their website, but I haven’t heard much about it. Froogle claims that Boris is selling it for $25, which is a good example of why I don’t trust Froogle (congratulations on the wedding, Boris). I don’t actually know if D-Link is selling the DVG-1120 directly, but there’s at least one review online. D-Link also has a SIP phone on their website, but the Asterisk-users mailing list claims that it’s not available in the US yet.

So, all of the “name-brand” cheap home networking companies are now selling VoIP adapters. Presumably, we’ll see a wave of no-name SIP hardware hit in around 6 months, and the cost will drop to around $25. That, combined with a month’s free service, should make Vonage and their ilk grow like weeds without having to pay $400 per head to acquire customers.