You, the audience

Who reads this blog? A better question might be, who might benefit from reading this blog?

  1. Penn Staters. Even though the content doesn’t always reflect it, the main purpose of this blog is to share interesting information about Penn State Voice-over-IP with Penn State people outside the department that designs and operates it. At one point, this would have only included the University Park campus, but now other Penn State locations are using VoIP for their campus PBXes or interconnects. I hope to dig into that topic more soon.

    I received an e-mail from a reader today, a Penn State faculty member, wanting to know what I recommended for a cordless phone solution. (Answer: at this point, an analog connection with a nice digital cordless phone is probably the way to go.) I hope that Penn State faculty and staff members can get some useful, non-technical knowledge from this blog.

  2. VoIP enthusiasts. My more technical posts are for VoIP enthusiasts and include the how-tos, Asterisk configs, protocol discussions, and interesting VoIP tech like Google Voice. I believe that most people who arrive here via web search are in this category.
  3. Systems administrators curious about VoIP. I have found that most of the Penn State people who read this blog are systems administrators and tech people from other departments–general IT folks who are not necessarily VoIP enthusiasts. So I hope it is helpful to include information such as the Essential Protocols series that is appropriate for technical types who may not know a lot about the workings of VoIP.

Anyone else? Don’t feel left out. Leave a comment if you subscribe or stop by to read from time to time and I haven’t described you above.

Google Voice in GMail

One step closer to SIP integration, or at least Asterisk integration using the chan_gtalk module: yesterday, Google added PSTN calling to their GMail-embedded Talk/Chat product.

Making a call from the GMail-embedded talk client uses a linked Google Voice account, thus call history appears in the Voice dashboard and the caller ID is the Google Voice number. Interesting.

This functionality doesn’t seem to appear in the standalone Google Talk client, nor does the web module appear directly in Google Voice. The only way to make a non-telephone-integrated call (that is, it doesn’t utilize your Gizmo5 account, land line, or cell phone) is to do so through GMail chat. I have to wonder why it didn’t appear in the Google Voice web interface first, or the standalone Talk client, but suspect that these will be coming. SIP integration still seems to be at least two or three steps away.

(Google Voice blog announcement)

Historic telephone booths to be removed from union, auctioned

Soon, a piece of Penn State and telecommunications history will be removed from the Hetzel Union Building and auctioned on eBay: 1950’s-vintage telephone booths.

HUB phone booths
Image courtesy PSU Public Information

I noticed that the pay phones had been removed and wrote to a HUB staff member to find out what was going to happen to the booths. She wrote,

The HUB phone booths will not be destroyed. They are going to be sold via the Penn State Lion Surplus eBay process. This can be accessed by going to their web site at http://www.surplus.psu.edu We are hoping that a student and/or alumnus would find them valuable and enjoy them for years to come.

The HUB underwent extensive remodeling from 1998-2000 and these phone booths were preserved from the old union building.

XLink Bluetooth cellular gateway

A few years ago, I found a product that pretty much completed voice integration on my home Asterisk-based VoIP system.

As it was, I could accept calls over a variety of trunks and then route them around the house or to my office or soft-phone, or let them go to voicemail and wait for me or be sent to my e-mail inbox. And yet, I was still carrying around in my pocket an independent voice communications device: my cell phone.

When I thought about how I might like to integrate the cell phone, I came up with a simple goal: when I am at home, I want Asterisk to handle the cell phone like it handles any other trunk. When I leave the house, I want to be able to pick up the cell phone and walk away and have Asterisk still do the right thing (that is, not try to use it and fail).

My solution actually ended up being an analog solution: the XLink Bluetooth gateway. The XLink connects to up to three phones via Bluetooth and presents them on an FXO (line) port. The idea advertised on their web site is that you now hook up your home analog set(s) and use the cell phone like you use a landline. That’s OK, but is much more powerful if instead you connect this to an FXS analog telephony adapter for use on your VoIP system.

xlink.pngWith this setup, you can treat the cell phone like an analog line in Asterisk, going through the ATA (I have the Cisco-Linksys-Sipura SPA3102). You can then set up an inbound route from the ATA–I just route it like any other call–and outbound routes–for example, for long distance calling, or 911.

What I like about this is that when I get home, I set my cell phone near the XLink (which happens to be in a convenient location) and then walk away. It connects by Bluetooth and now any calls I receive on the cell phone are presented to my home phones by Asterisk. When I’m ready to leave, I pick up the phone and go. The Bluetooth is disconnected and the XLink returns a reorder tone to the ATA if a call is attempted; the ATA understands the reorder tone and returns the proper failure code to Asterisk. In this way, Asterisk could even attempt routing to the cell phone when it is not there, and move on to the next possible route when the failure is detected.

The XLink really brings my home phone system together by including the cell phone without any additional work on my part except to take the phone out of my pocket when I come through the door.

For reliable telephone service, you need batteries, somewhere

In a recent post at mgraves.org, Michael Graves observed that today’s POTS [plain old telephone service] analog equipment seldom runs just off the phone line power, as it used to. It needs “wall power.” And folks who claim that POTS is more reliable than VoIP because the power comes over the phone line are likely forgetting this, or remembering their Trimline from thirty years ago that did indeed run solely on phone line power and worked during an electricity outage.

The telco knew the importance of reliable phone service and set up large banks of batteries at the central office that would power the lines at all times. If the electricity is out, the phone is still up, because the wall or desk phone they leased you (or later, that you bought yourself) ran off that line power. When cordless phones, FAX machines, and other more advanced analog sets came out, many did not or could not run off of phone line power and now required AC electric power. This new requirement undermined the reliability that the telco had put in place long ago.

To keep your advanced analog equipment online during a power outage, now you’d need the telco’s batteries as well as local batteries–an uninterruptible power supply, or UPS. This is what we have in place for PSU VoIP.

Our “central office”–actually, the data centers where the VoIP servers, gateways and other core devices reside–are covered by large UPSes and diesel generators. Anything between the core and the endpoint (your phone) that requires electricity is also on a UPS, including the PoE switch to which your phone is connected. Thus, if the electricity goes out, your VoIP phone will still be online.

Whether you go with POTS or VoIP, you need batteries, somewhere, to keep your phone service alive.

Using Google Voice

In June, Google opened Google Voice to the public–invitations no longer required. Great news for anyone who wants “a single number that rings you anywhere” and even better for VoIP enthusiasts who want multiple numbers that all terminate in the same place and free domestic calling.

Google Voice has a bunch of great features, including voicemail transcription, a good web interface and filters. These are all useful on their own, but let’s jump ahead and talk about what you can do with Google Voice and Asterisk.

First, some notes:

  • One Google Voice number is available per Google account, and you can create multiple Google accounts. I don’t know of any limit on this.
  • Only two Google Voice numbers may point at the same target number. For example, if you have a POTS land line, only two GV numbers may be configured to point at it. This includes numbers configured in the GV account whether they are used by any call groups/filters.
  • Google Voice no longer presents all calls with the “Press 1 to accept…” prompt, as it once did. (You can turn on screening to get this back.) This is good because in the past, you would have had to write a custom context to send DTMF to GV to accept an incoming call.
  • Google Voice no longer blocks DTMF. Incoming calls can send DTMF and it will be passed through to your IVR. GV does, however, block early media.

Uses

Front-end your free DID with something local and better – Google Voice has a very large pool of numbers available, so large that not only will you be able to find one in your local calling area, you’ll probably be able to choose from dozens of them and get a number that you like. Once you do, get your free DID from Sipgate or IPKall, set up the incoming trunk to your system, and point the GV number to your free DID. Now you have not only a free DID but one with a number you might actually use.

Make yourself local to your remote family – Got remote family who still use a land line with costly long distance plan? If you don’t want them to call you, move to the next tip. Otherwise, set up a Google Voice number local to them and point it to your “main” or common DID, the one on which you normally receive calls. Then give them the number and forget about it forever, because it will just work.

Set up an IVR or voicemail pilot – So now that GV allows DTMF to pass through, you could set up a GV number through a free VoIP DID to a new inbound route on your Asterisk system, such as a direct voicemail pilot or a backdoor to other functions (called a DISA in Asterisk).

Make free domestic calls – Here’s where direct SIP connectivity to Google Voice would be really nice, but alas, it’s not here yet. You have a few options, though:

Scripted within the dialplan – You can add some scripting to your Asterisk dialplan to take the number dialed, send it to Google Voice via the web dialer, initiate the call and connect it back to the caller. This NerdVittles article and the accompanying comments explain a popular method for doing so.

The web dialer – Initiate your calls through Google Voice’s web interface and pick up the phone when it rings.

The telephone interface – From a trunk that has unlimited local calling, call your local GV number, press 2 and dial your destination.

The telephone interface, automated – Add an extension definition like the one listed below to automatically dial your local Google Voice number on an unlimited local trunk, send the necessary DTMF and connect the call. Since I’m using FreePBX, the outbound-allroutes context is where outbound calls are handled and this extension definition would be added to [from-internal-custom] in the extensions_custom.conf file. To use it, dial 0048 (0-0-G-V) followed by the number you want to reach. Note: if you have GV set to require a PIN, you’ll have to add the PIN to the sequence of waits and DTMF below (in the D() option).

exten => _0048.,1,Dial(Local/YOUR-GV-NUMBER@outbound-allroutes,,rD(www2w${EXTEN:4}#))

More – Google Voice also has SMS features and voicemail transcription that could be integrated. How have you used Google Voice with Asterisk to add functionality to your home or small-business VoIP system?

VoIP providers for home use: 2010 update

Near the beginning of 2008, I published VoIP providers for home use, where I listed my favorite telephony service providers, some of which I have now abandoned because they no longer exist, are no longer cheap, or something better came along. Here are my current choices.

CallCentric – Last time, I said I was just starting to use CallCentric‘s services. As of this month, I’m just ending more than two years with them. I had a DID and used them for some incoming calls and redundant 911 service. I have no complaints; I’m canceling because I no longer need the services. CallCentric is pretty slick and has excellent technical support, fairly low rates for DID (but 2c/min. for outbound domestic calls, which is about double what many others offer), a nice incoming FAX option, super reliability and excellent sound quality. From my location, they often had the lowest latency of any provider I was using. Pay with credit card or PayPal. Oh, and here’s a neat trick: I found that CallCentric DIDs don’t seem to obey the privacy bit on incoming calls. So if someone sets the privacy bit to block their caller ID, you still get it. Probably a misconfiguration, but it could be helpful if you want or need that.

CallWithUs – My current favorite termination provider, to anywhere. I first looked into CallWithUs as a cheap provider for international calling and found that their domestic rates are excellent, too. Their web site speaks of their “keep it simple, stupid” business philosophy and I find that to be another great reason to work with them. Pay with credit card or PayPal, prepaid only. They also offer PBX hosting and VPN connections for low costs, neither of which I have used but would definitely try if I needed one of those services.

Sipgate – Sipgate’s One service offers a free DID in California with unlimited inbound. Front-end that with a Google Voice DID in your area and now you’ve got a free local DID on its own trunk for use however you like. Sipgate has one of the coolest web dashboards I have seen, FAX services (inbound free), and the ability to register multiple devices to their service, which could be useful. I haven’t used any of their paid services yet. My connection to Sipgate has roughly 120 ms latency but little if any jitter, so the quality is fine.

Gizmo5 – I’m still using the Gizmo5 connection with a Google Voice number routing over it, but you can’t sign up for a Gizmo5 account anymore, and web speculators think it’ll be rolled into a Google Voice+SIP offering at some point.

And there’s more…

Google Voice isn’t really a provider but has already received a few mentions above. I’ll have a post dedicated to GV soon. Stay tuned also for a post on XLink, which has been a valuable part of my home VoIP setup for a couple years now.

XMPP (Jabber) caller ID popups with Asterisk & FreePBX

Asterisk has had a Jabber module for a few years, officially supported since 1.4. The module enables two dialplan functions: JabberStatus, to get presence information, and JabberSend, to send a message. There’s more XMPP/Jabber functionality in Asterisk 1.6, but I’ve been sticking with the long-term support release at this point.

The two Jabber functions would be really useful in a call center where agents have some desktop with XMPP services. The presence function (JabberStatus) can be used in call routing logic, for example, and the JabberSend can be used for screen pops of caller information, perhaps bundled with external data from a CRM package.

Anyway, I wanted to implement caller ID popups on my home system that would IM that info to my wife and me when a call comes in. (She is a willing participant in my nerdy experiments.) Given the above two dialplan functions, the procedure is straightforward:

    1. Execute during the incoming call context
    2. See if buddies are online (and available)
    3. Send an IM to each available buddy with a message that includes the CALLERID variable

Since I am running FreePBX, I wanted to do it the FreePBX way, which means not to mess around with the [from-trunk] (incoming) context directly. Unfortunately there is no direct configuration of the XMPP module from within FreePBX so I have a 15%-FreePBX, 85%-config-files solution.

  1. Make sure the res_jabber.so module is loading. Review /etc/asterisk/modules.conf and verify either autoload=yes with no noload => res_jabber.so, or that without autoload, you are issuing a load => res_jabber.so.

  2. Configure an XMPP account (Gmail, Google Apps, jabber.org, local XMPP server, whatever you like) and set up the details in /etc/asterisk/jabber.conf. The config file is well-documented so I won’t go through it step by step. If you don’t have it, there’s a sample jabber.conf in the Asterisk source tar and a bit of info on the voip-info wiki. Be sure to add the buddies you want to be able to IM with buddy= lines.

  3. Restart Asterisk and use jabber show connected from the CLI to see that your user is now logged in. Review log files and fix until it successfully connects.

  4. Edit /etc/asterisk/extensions_custom.conf and start a new extension under the [from-internal-custom] context. This is going to be a bogus extension number that just issues the Jabber commands and ends. The idea is that it will later be a member of a default incoming calls ring group. I used extension 1099 as it fits in my dialplan and doesn’t interfere with anything else:

    [from-internal-custom]
    ...
    exten => 1099,1,JabberStatus(label,someuser@jabber.org,SOMEUSERSTATUS)
    exten => 1099,n,NoOp(Value of SOMEUSERSTATUS is ${SOMEUSERSTATUS})
    exten => 1099,n,JabberStatus(label,otheruser@jabber.org,OTHERUSERSTATUS)
    exten => 1099,n,NoOp(Value of OTHERUSERSTATUS is ${OTHERUSERSTATUS})
    exten => 1099,n,Execif($[${SOMEUSERSTATUS} < 6],JabberSend,label,someuser@jabber.org,Incoming call from ${CALLERID(all)})
    exten => 1099,n,Execif($[${OTHERUSERSTATUS} < 3],JabberSend,label,otheruser@jabber.org,Incoming call from ${CALLERID(all)})

    Replace label with the [label] set up in jabber.conf for your XMPP connection. Replace someuser@jabber.org with the user ID of a buddy you defined in jabber.conf, and the variable name SOMEUSERSTATUS with whatever you like. The ExecIf statement which checks SOMEUSERSTATUS < 6 sends a message to the buddy if he/she is online. You could use < 3 to IM the buddy only if he/she is in the Available or Chatty state. Do the same for any other users you want to IM on an incoming call.

  5. Reload the dialplan at the CLI with extensions reload and then pick up an extension and dial 1099 or whatever you set up, above. This will trigger the Jabber commands and if you are online, you should get a popup stating that there’s an incoming call from your extension. Experiment and tweak to your liking.

  6. Now to integrate this into FreePBX, we’re going to add 1099 to the list of extensions rung on an incoming call. On my system I ring all extensions when an external call comes in. So to ring all extensions and trigger the Jabber functions as well, I just added 1099# (must include the #) to the bottom of the Extension List on my default ring group.

  7. If you want, you can also add your new custom extension number to the Custom Extensions module in FreePBX, just for tracking purposes.

If you’ve got a more complicated setup with different ring groups per DID or something else, it’s easy to repeat the steps and make additional custom extensions that IM different people or send different messages, then integrate these custom extensions into your FreePBX ring groups. At this point you should be able to apply the config in FreePBX and then wait for an incoming call. As your phones begin to ring, you’ll get an IM if you’re online.

Essential protocols and services that support VoIP #3: PoE

Jumping to the other end of the protocol stack, we visit Power-over-Ethernet, which specifies how a switch or other power-sourcing device provides DC power to remote devices, alongside the data, over the network cable.

I’ll let the wikipedia writeup explain the technical details. Essentially, it’s an electrical/wiring protocol, not a data protocol.

Devices at PSU that use PoE include Cisco phones and wireless access points, and probably others. Older Cisco phones, such as the 7910, 7940 and 7960, use Cisco’s pre-standard PoE implementation. Newer phones use the standard IEEE 802.3af implementation.

PoE is not dangerous to devices that do not need power through the Ethernet cable. Power is only sent if the correct resistance is detected, and otherwise is switched off for that port.

Desktop VoIP phones today are typically offered “power brick sold separately.” In a deployment of 15,000 IP phones, we could occupy 15,000 power outlets and waste a lot of money on power bricks, or provide power at the switch port and save wiring and money. Moreover, VoIP equipment in the telecom closets is protected by a UPS, meaning that if the phone is drawing power from the network switch (as opposed to the wall outlet) it benefits from the battery backup as well.

Essential protocols and services that support VoIP #2: DHCP, TFTP and NTP

DHCP – Unless you’re deploying only a few IP phones, you won’t want to configure the endpoints individually. And some phones can’t be configured entirely by hand. (For example, to factory reset and apply new firmware to the Cisco 7906, the only method seems to be to use DHCP, as I describe here.) DHCP provides IP and router information to the device, as well as the following useful options:

  • DNS server list
  • Network time protocol (NTP) server(s), where the device will get accurate time
  • TFTP server, where the device will get firmware and, typically, configuration files
  • Vendor-specific options, such as Cisco’s option 150, which can list multiple TFTP servers

Without DHCP, the aforementioned information would all have to be entered by hand, using the phone’s keypad. On some devices, the IP address information is entered through the keypad and then the phone is further configured using a web or telnet interface.

TFTP – Trivial file transfer protocol has a long history of being used for automatic device configuration. It’s a very simple protocol, neither authenticated nor encrypted, and basically provides commands to upload or download a known file (no “browsing” capability) over UDP. Its simplicity allows it to be embedded into the device so that even without firmware, the loader can use TFTP to get a device image and configurations. The Cisco IP phones also use TFTP occasionally during operation to retrieve ringtone files or background images.

NTP – Network time protocol keeps everything on the VoIP network tightly in sync. Devices that use DHCP for address configuration also get a list of NTP servers as one of the options; servers and other core components have to be manually configured with the addresses of NTP servers. For the phones, NTP is mostly a convenience service that sets the clock that is displayed at the top of the screen. Accurate time on call-processing servers and voicemail is an obvious necessity, especially for correct generation of call-detail (billing) records. Also, when maintaining a cluster of servers and other core devices, troubleshooting problems using time-stamped log files is far easier when the logs are in sync.