My Inadequate Attempt at a Guide to Using AT&T’s CallVantage Service to its Full Potential
Note to self: do not actually attempt any of the techniques described below or risk breaching the AT&T TOS. The following proof-of-concept writeup is provided for educational purposes only.
Obtaining the SIP Settings
The AT&T CallVantage service makes use of the SIP protocol for communication between their network and the analog telephone adapter (ATA, TA) at home. The dirty little secret AT&T doesn’t want you to know is that you are able to use their VoIP to POTS termination service with any SIP device: soft phones, IP phones, other TAs, etc.
AT&T provided me with the
Linksys RT41P2-AT TA. Since it can serve as more than simply a TA, the folks at Linksys programmed a handy interface to allow the configuration of normal SOHO router settings (port forwarding and the like). The setup I have is typical of many homes: cable modem -> router -> LAN -> TA -> analog phone. For the time being, we’ll need to attach to one of the TA’s LAN ports and access this interface at
http://192.168.15.1/. The default password is admin.
Once we’re logged in, go to the administration tab and change the password to something less obvious. Then, go ahead and activate remote administration to allow access from your LAN. Once this is done, the only network connection we’ll need connected is the one from the LAN to the TA’s WAN port. You’ll now access the TA via its web interface on your LAN. For example, if your router assigned the TA the IP of 192.168.0.101, then you may access it at:
https://192.168.0.101/.
You’ll notice the valuable SIP settings are nowhere to be found on the web interface. Never fear, security by obscurity has always worked. Point your browser to:
https://192.168.0.101/sip.htm. What’s this? How do I know the password? Well, you can call AT&T and make a feeble attempt at convincing them that you need access to these settings, and they will supply you with the password, which constantly changes as a function of the TA’s MAC address and the current time.
Or you can simply disable Javascript in your browser and see the settings plain as day.
But wait, the password box is full of asterisks! Foiled again... or are we? Take a look at the source, and you’ll see that while the box is full of asterisks that usually signify a protected password, the plain-text password is completely revealed in a hidden field.
Smooth move, guys. Regardless of poor programming practices, digging through source can be an unnecessary pain. To simplify the process, I’ve whipped up some quick Perl that will grab the relevant info and print it in a simpler format:
1 #!/usr/bin/perl
2 # Tool to give AT&T CallVantage users current SIP information from Linksys TA
3 # Enter your TA's username and password below
4 $addr = "10.0.0.104";
5 $user = "admin";
6 $pass = "admin";
7
8 # Grab the source of the "protected" SIP settings page
9 $body = `curl -k -u $user:$pass https://$addr/sip.htm 2>&1`;
10
11 # Loop through each line and parse out the important bits
12 foreach $line ($body) {
13 chomp($line);
14
15 # Simple parsing, no validation (yet)
16 ($displayname) = ( $line =~ /value="(.*)".*sip_displayname1/ );
17 ($username) = ( $line =~ /"(.*)".*sip_phoneNum1/ );
18 ($authuser) = ( $line =~ /"(.*)".*sip_account1/ );
19 ($password) = ( $line =~ /hidden.*"(.*)".*sip_psw1_hidden/ );
20 ($domain) = ( $line =~ /"(.*)".*sip_proxyaddr/ );
21 ($proxy) = ( $line =~ /"(.*)".*sip_proxyaddr/ );
22 ($proxyport) = ( $line =~ /"(.*)".*sip_proxyport/ );
23 ($outproxy) = ( $line =~ /"(.*)".*sip_outproxy/ );
24 ($outport) = ( $line =~ /"(.*)".*sip_outport/ );
25
26 }
27
28 # Print the gathered information in a simple-to-read/copy format
29 print "Display Name: tt$displaynamen";
30 print "Username: tt$usernamen";
31 print "Auth User: tt$authusern";
32 print "Password: tt$passwordn";
33 print "Domain/Realm: tt$domainn";
34 print "SIP Proxy 1: tt$proxy:$proxyportn";
35 print "SIP Proxy 2: tt$outproxy:$outportn";
Change the variables at the top to reflect your TA’s information, and the output should appear similar to this:
1 user@host:~$ ./voip_settings.pl
2 Display Name: 5089261283
3 Username: 5089261283*22701202
4 Auth User: 5089261283
5 Password: 68735A8DE07FCD7
6 Domain/Realm: 12.194.243.8
7 SIP Proxy 1: 12.194.243.8:5620
8 SIP Proxy 2: 12.194.239.134:5060
Setting up the Softphone
While you can lug your AT&T TA adapter, its power brick, and an analog phone around with you to any place with an open Ethernet jack, don’t you think you drag enough crap around already? There are plenty of full-featured soft phones that turn just about any computer into a phone system (a la Skype, but better).
Since SIP is an open protocol, there are plenty of offerings available. Some are free, other open-source, and even more are available for purchase from software vendors. We’ll stick with one free – though not open-source – offering from the folks at CounterPath. Their free X-Lite soft phone is available for the big OSs – Windows, Linux and Mac – is simple to setup, and lacks "bloat." Download the latest version for your OS and install it. Enter the settings you’ve obtained from the TA into System Settings -> SIP Settings -> Proxy (Default), and you should be good to go.
If you’re having issues with sending touch tones (for instance, entering conference pass codes), change the DTMF settings: Menu -> Advanced System Settings -> DTMF Settings -> DTMF Code Length in Samples = 3520.
A VoIP Proxy for the Ages
More and more workplaces have placed restrictions on Internet access from employee’s workstations. While necessary in many cases, it could prove to be a problem for our VoIP setup, which communicates via UDP. To remedy the situation, we will create a simple, secure proxy to tunnel VoIP (and perhaps more) traffic outside the restricted internal network.
First, we must install and configure the
OpenVPN server at the receiving end. (Make sure you’re setting it up on a connection that can handle the round trip VoIP traffic without a problem.) Download, compile and install the source or grab the latest binary for your distribution. My test server is a VMware guest running Ubuntu 5.10 server, and I was able to grab the software from the Ubuntu repository:
1 sudo apt-get install openvpn
Once installed, the next step is to configure the server for a simple point-to-point VPN connection. The folks at OpenVPN have posted a
guide, but the steps I took were slightly different, so I’ll cover the entire process here as well.
With this configuration, a VPN tunnel will be created with a server endpoint of 10.8.0.1 and a client endpoint of 10.8.0.2. Encrypted communication between client and server will occur over TCP port 443, the standard HTTPS port. The reason for this choice is that most network firewalls and proxies expect encrypted end-to-end traffic over this port, so we won’t be raising any flags by creating abnormal network activity. Besides, if they worried enough, they would quite easily be able to differentiate legitimate HTTPS traffic from our tunnel’s activity.
Generate a static key:
1 openvpn --genkey --secret static.key
Move the static key to the server’s configuration directory. We will also need to copy the key to the client over a pre-existing secure channel.
Now we will create the configuration file for the server and place it in the appropriate directory (in this case, /etc/openvpn. My configuration file is:
1 # Use a dynamic tun device.
2 dev tun
3 # 10.8.0.1 is our local VPN endpoint
4 # 10.8.0.2 is our remote VPN endpoint
5 ifconfig 10.8.0.1 10.8.0.2
6 # Our pre-shared static key
7 secret static.key
8 # Use TCP over "HTTPS" port 443
9 proto tcp-server
10 port 443
Make sure that TCP port 443 is open on the server (and forwarded correctly if the server is behind a NAT device such as a home router). We are now ready to start the server:
sudo /etc/init.d/openvpn start
Onto the client: for this example we’ll be setting up OpenVPN on a Windows workstation. Fortunately, there is a great
OpenVPN GUI package that will take care of 90% of the configuration for us. Download the latest installation package and install on the client (all default options will be sufficient).
Now that the OpenVPN client software and virtual network interface have been installed, we’ll need to make two additional changes. As I mentioned before, we’ll need the static key generated earlier on the server. Secondly, we’ll need a slightly-modified configuration file for the point-to-point VPN we’ve created:
1 # Use a dynamic tun device.
2 dev tun
3 # Remote hostname/IP address
4 remote myhome.no-ip.org
5 # 10.8.0.2 is our local VPN endpoint
6 # 10.8.0.1 is our remote VPN endpoint
7 ifconfig 10.8.0.2 10.8.0.1
8 # Route traffic to the AT&T subnet over the VPN
9 route 12.0.0.0 255.0.0.0 10.8.0.1
10 # Our pre-shared static key
11 secret static.key
12 # Use TCP over "HTTPS" port 443
13 proto tcp-client
14 port 443
Place the configuration file in the configuration directory (ex: C:\Program Files\OpenVPN\config). Start the GUI, click Connect, and you should see the connection negotiate successfully.
You’ll notice that I’ve added a route for the traffic destined to the AT&T network. This will tell the OpenVPN client to update the Windows routing table to reflect the changes in route while bringing up the virtual network interface. When the VPN connection is taken down, everything is returned to its original state. In order to route the traffic through the OpenVPN server to the Internet, we need to enable routing on the Linux host:
1 sudo echo 1 > /proc/sys/net/ipv4/ip_forward
2 sudo iptables -t nat -A POSTROUTING -s 10.8.0.2 -o eth0 -j MASQUERADE
Once those changes are applied, the server will be capable of routing your VoIP traffic over the VPN tunnel.
