Recently at Oppedahl Patent Law Firm LLC we chose to explore possible work-from-home approaches. This blog article and some subsequent articles talk though some of the things that we are working on, in case it may be of interest to some readers. In this article we talk about setting up what we call “bat phones”, meaning phones that can be plugged in at the homes of employees and the phones work exactly as they would work in the office. In a subsequent article we talk about setting up VPN access so that an employee might be able to take his or her desktop computer home, and plug it in, and have it work just as if it were in the office.
I must first confess that I am misusing the technical term “bat phone”. It turns out that “bat phone” has a very specific meaning namely one of three phones located in Bruce Wayne’s study in Wayne Manor, in the Batcave, and in Commissioner Gordon’s office in Gotham City. Within our firm the term “bat phone” is used much more loosely, and simply refers to a VOIP phone that can be plugged in at an employee’s home or other remote location and it will work identically to its function if it were plugged in at our office.
There are several things that must be done for a VOIP phone to be able to work just as well at home as in the office.
NAT traversal. In an employee home, or in other locations outside of the office, there is almost always at least one NAT (“network address translation”, Wikipedia article) router interposed between the (intended location of the) VOIP phone and the office or telephone server. It turns out that NAT is simultaneously very wonderful and very evil. NAT is very wonderful if the only thing that you want to do is checking email and visiting web sites. NAT may be compared with the New Testament miracles of feeding the multitudes (Wikipedia article) in which Jesus is reported to have taken a small number of bread loaves and a small number of fishes and multiplied them to feed large numbers of people. With NAT, a home or office that receives only a single routable IP (internet protocol) address from an internet service provider is able to multiply this into as many as 253 non-routable IP addresses. The so-called “NAT addresses” (Wikipedia article) are instantly recognizable because they are of the form 192.168.x.x or of the form 172.[16-31].n.n or of the form 10.n.n.n. For those whose needs are limited to checking email and visiting web sites, NAT addresses are wonderful because you can have up to 253 computers and cell phones and printers and other hosts that can function, each with its own IP address, even though only a single IP address was obtained from the ISP.
Although NAT is thus very wonderful, indeed nearly miraculous, NAT is also very evil. NAT only serves TCP (transmission control protocol, Wikipedia article) connections well. If the connection is by means of other protocols such as UDP (user datagram protocol, Wikipedia article), NAT is often a complete disappointment. Among other things NAT generally guarantees that a VOIP phone will fail.
For a VOIP phone that is going to be plugged in at an employee home, nearly all of the data packets that are going to need to pass back and forth are UDP packets, not TCP packets. Because the employee home surely uses NAT, the VOIP phone won’t work unless heroic efforts are taken to trick the NAT router into somehow passing the UDP packets correctly to particular devices among the up to 253 devices that are benefiting from the (metaphorical) miraculous multiplication of the loaves and the fishes.
The problem is that if some random UDP packet were to arrive at the NAT router from the Internet cloud, in general the NAT router has no idea which of the up to 253 connected devices might be interested in receiving that UDP packet. This problem of figuring out what to do with inbound UDP packets does not even arise if the activity going on is simple checking of email or visiting of web sites. But where Voice over IP (VOIP) is concerned, the problem of figuring out what to do with inbound UDP packets is a problem that arises with every incoming or outbound telephone call.
The heroic efforts to deal with this problem involve what is called “keep-alive”. A typical keep-alive approach has the VOIP phone and the telephone server passing so-called “keep-alive” data packets back and forth between the phone and the server, regardless of whether any telephone call is actually taking place. The general idea is to trick the NAT router into thinking that something important must be continuously going on between the phone and the outside world (and eventually with the distant server) and so the NAT router must never even for a brief moment permit itself to forget which of the 253 devices is a VOIP phone and must be interested in receiving such incoming UDP packets.
The first challenge is that most telephone servers (for example PBXs) have a default configuration that assumes that any of the connected telephones must be on the same local area network in which case there are no NAT routers and no need for these heroic efforts such as keep-alive packets. The second challenge is that most VOIP telephones likewise have a default configuration that assumes that the server or PBX to which they communicate is on the same local area network in which case there are no NAT routers and no need for these heroic efforts such as keep-alive packets.
If we are going to put a VOIP phone at an employee home, both the phone itself and the server (or PBX) needs to be configured to do this aggressive “keep-alive” activity, constantly sending absolutely empty content-free and otherwise completely unnecessary UDP packets back and forth for no better reason than tricking the one or more NAT servers along the data path into constantly keeping track of the particular non-routable IP address that is associated with that particular VOIP phone. Most of our phone are Grandstream phones and the NAT setting of “keep-alive” inside the phone is shown at right. As I say, the default setting is “no” keep-alive, on the assumption that the phone is connected by a direct local area network connection to the server. So we have to change this setting. If your phone is made by some company other than Grandstream, the screen would look different and the terminology might be slightly different but the general meaning is the same.
At the PBX, one important setting has be turned on for each individual extension that might get connected to a phone at an external location, namely “NAT” must be turned on for that extension. This is shown at right with the box checked for NAT for a telephone extension in our Grandstream PBX. But in addition, with our PBX there is a system-wide setting that has to “just right” for successful connection of phones at external locations, namely the so-called “NAT” settings of the so-called “SIP settings” in the general “PBX settings” of the PBX. As shown at right, the PBX is itself “behind a NAT” and it needs to have been told what its own routable IP address is. This is done in the “external host” field. But then there is also a box called “use IP address in SDP”. SDP means “session description protocol” (Wikipedia article). What I can tell you very simply is that if you have a Grandstream PBX, the default setting of this check box is “unchecked” and if you want to be able to use phones at external locations, you need to check this box. It is as simple as that. We could discuss what SDP means and what an external host is, but we will not. The answer is you must check this box.
In addition the PBX needs to be told how to distinguish between a phone that is “on the local area network” and a phone that is further away. The “local network address” table needs to say what the range of IP addresses is for phones that are “on the local area network”. In this case the phones that are plugged in locally all have IP addresses of the general form 192.168.115.x and so this must be entered into this table, as shown in the second screen shot.
So if you accomplish everything just stated, you can “beat the NAT”, meaning you can successfully get UDP packets to pass back and forth between a far-away phone and the PBX despite the presence of multiple NAT servers between the two devices.
SIP server settings in the phones. When you plug in a phone at some employee’s house, when it boots up it tries to “register” to the server (for example to the PBX). For this to work, the phone needs to know the (routable) IP address of that PBX. So you might just look around and find out what that IP address is, and program that IP address into the phone in the “SIP server” field. The challenge is that the PBX may be at a location that has only a dynamic IP address rather than a much more expensive static IP address. If so, then the IP address may change from time to time depending upon the whims of the internet service provider. How to deal with this problem? The answer is to use a DDNS service (Wikipedia article). We like NoIP.com which costs $25 per year which is a lot cheaper than the annual cost to get a static IP address from our ISP (about $240). The functional result is that when we plug in a phone at some employee’s house, the phone does a DNS lookup of a domain name (in our case something.oppedahl.com). That domain name is a CNAME pointing to a domain name provided by the DDNS service provider (in our case something.ddns.net). That domain name has an A record yielding the (routable) IP address that is the dynamic IP address given to us by our ISP. Our main router in our office is configured so that any time our ISP changes our dynamic IP address, our main router will pop off a message to the DDNS service provider so that it will update the A record accordingly. The alert reader will appreciate that it is important that our CNAME have a very short TTL (time-to-live) so that any time our ISP changes our dynamic IP address, the new value will be promptly available for any phone that might get plugged in after the change happened. In our case we have set the TTL for the CNAME record to sixty seconds.
With these settings attended to, we find that an employee can go to his or her desk in our office and unplug a VOIP phone and put it into their car and take it home, and the phone will work just fine when plugged in at home.
Eavesdropping. A traditional analog landline is extremely easy to eavesdrop upon in ways that are very nearly undetectable by the user. A classic analog wiretap, for example, could be connected at many off-premises locations and the user would never know. Persons with very little technical skill can accomplish classic analog wiretaps and the equipment to make it happen costs very little — under $100.
The default settings of VOIP phones and servers are likewise such that eavesdropping could be carried out, although the would-be eavesdropper has to be somewhat more sophisticated and needs to have access to somewhat more expensive tools. But such eavesdropping can happen and very likely does sometimes happen.
One really nice thing about VOIP is that with a few mouse clicks you can nearly effortlessly encrypt almost everything about the connection between the phone and the PBX. I have blogged about this here. Briefly what you do is “turn on” TLS (transport layer security, Wikipedia article) at both ends of the connection (in the phone and in the PBX) and you “turn on” SRTP (secure real-time transport protocol, Wikipedia article) at both ends. You can see a little padlock on the screen of the phone during such encrypted telephone calls (example at right).
So if you are setting up work-from-home, it is a Best Practice to turn on TLS and SRTP at the phone and at the PBX. This makes it nearly impossible for a would-be eavesdropper to accomplish very much by sniffing the data packets that go back and forth between the phone and the PBX. The would-be eavesdropper can work out the physical locations of the phone and PBX, and can work out when a phone call is taking place, but will not be able to work out the phone numbers at the two ends of the phone call and will not be able to hear what is being said.
Of course you will also want to encrypt the connection between your PBX and your telephone service provider. I have blogged about this here. But that is not linked to whether or not you are trying to accomplish work-from-home. Even when employees are in the office using their phones in the office, you would have wanted to encrypt the connection between your PBX and your telephone service provider.
Testing your connection. Of course when you plug in any VOIP phone, especially in a place where you have not plugged it in before (for example at the home of some employee) you will wonder whether or not you have successfully “beaten the NAT”. The absolute best way to do that is to call up the Oppedahl Patent Law Firm LLP VOIP test server at +1 720 230 1331. Then punch 4 to select an echo test. Speak into the phone and listen to hear your speech repeated back to you. If you can hear your own speech repeated back to you, this this means you win. You have “beaten the NAT”.
Busy lamp fields. What about the employees whose work involves answering the main office telephone number? They need to know who is on the phone already. This is accomplished by means of what is called a “busy lamp field” or BLF. The phone with the BLF sidecar (see image at right) works just fine when taken home and plugged in. The little blinky red and green lights and LCD screen tell you who is on which extension and whose phone is in use. So the employee can answer incoming calls on our main office telephone number almost as well from home as in the office.
Cost-free. I should emphasize that nothing discussed in this article has any recurring cost. Your monthly phone bills should not go up as a consequence of doing any of the things discussed here. (If they do, then you need to fire your telephone service provider and hire a better one. We like VOIP.MS.)
Likewise nothing discussed in this article should even present any one-time cost. You should not have to spend even a penny on new physical equipment or physical upgrades to your equipment. It should just be a matter of doing a few mouse clicks, and Bob’s your uncle.
Physical portability. It will be appreciated that this “beating the NAT” approach is very portable. An employee working from home on Monday could use the VOIP phone at one location such as the employee’s home. If it later were to develop that the employee needs to work from a different location (the home of a relative, perhaps) then it is simply a matter of moving the phone to the new location and plugging it in again.
What is your firm’s approach for office phones in a work-from-home environment? Please post a comment below.
4 Replies to “Setting up remote access – telephones”