The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.
The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.
[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.
The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.
Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.
[Daniel] picked up a cheap USB handset to use with his VoIP provider, and included in the box was a CD with all the software that would make this handset work with Windows. [Daniel] is running Linux on his main battlestation, rendering the included CD worthless. Using the handset under Linux would be a problem; although the speaker and mic worked, the buttons and screen did not. No problem, then: [Daniel] just played around with the command line until he figured it out.
The handset presented itself to the Linux box as a soundcard and HID device. The soundcard was obviously the speaker and mic, leaving the buttons and display as the HID device. [Daniel] checked this out by running a hexdump on the HID device and pressed a few buttons. His suspicions were confirmed, and he could easily read the button with a little bit of Python.
With the speaker, mic, and buttons on the handset figured out, [Daniel] turned his attention to the one bit of electronics on the phone he hadn’t yet conquered: the display. After firing some random data at the phone, the display blinked and showed a messy block of pixels, confirming the display was controlled through the HID driver. Loading up usbsnoop to see what the original software does to update the screed showed [Daniel] the data format the display accepts, allowing him to control everything in this VoIP phone.
[Ward Mundy] has found something great by combining a GXP-2200 phone with Raspberry Pi to create a private branch exchange. So the idea behind a PBX setup is kind of like a company intranet. All of the phones in the system are assigned an extension number and have access to the internal system functions like voice mail, and sharing phone lines to the outside world. We’ve talked about using an RPi as a PBX before, but the high-tech phone he’s using this time around pulls everything together remarkably well.
The GXP-2200 is available for under $200. It runs Android and has a full color touch screen pictured above. It is marketed as a multimedia phone and indeed it brings Skype and Google Voice to the party. But it also offers six SIP lines. The hardware even seems to be planned for this type of use as the phone offers a second Ethernet port to which the RPi board can be connected. In this example [Ward] simply screws the RPi to the phone’s plastic stand and connects the two using a six-inch cable. From there the PBX can be configured with the phone’s browser. How’s that for slick?
We’re not sure why this use didn’t immediately come to mind when we got our hands on a Raspberry Pi board, but the hardware is almost perfect as a PBX system. PBX, or Private Branch Exchange, is basically an in-house phone system. This guide which [Ward] put together shows you how to do some interesting things with it.
When talking about PBX setups the most common software package is Asterisk. That’s what’s at work here, rolled up with a bunch of other helpful software in an RPi targeted distro called Incredible PBX. All it takes to get up and running is to partition and burn the image to an SD like any other RPi distro. The configuration ends up being most of the work, starting with changing the default password, and moving on to customizing the environment to match your phone numbers and your needs. As with PBX setups on other embedded Linux devices, Google Voice is your best friend. The service will set you up with a free phone number.
This guide doesn’t delve into hardware connected hand sets. You’ll need to use a SIP phone. But that’s easy enough as there are free apps for most smart phones that will do the trick.
[Les] had thousands of dollars of expensive IP Telephone infrastructure at his fingertips, so he figured he might as well play around a bit – after all, what good is all that equipment if you can’t have a little fun?
Inspired by the “Awesome Button” featured on Make, he started thinking about what sort of feature he would like to have available at the push of a button. He must have had Travis Tritt on the brain the day he started building his creation, since he named it the “The Call Someone Who Cares Button”.
[Les] picked up an “emergency stop” button from eBay, wiring it to a TeensyUSB, just as it was done in the Make article. He mapped the button to the pause/break key, then whipped up a bit of C#code that listens for that key to be pressed. When toggled, the button sets forth a series of events that gets his boss on the line ASAP.
It’s a fun little project, and while I might have built a button that introduces fake static and echo into the line before dumping the call, I think it’s pretty cool all the same.
Since it seems that just about everyone has built some derivation of the Awesome Button, share yours with us in the comments, and be sure to stick around to see a quick video demo of the CSWC button in action.
Continue reading “Here’s a button, call someone who cares…”
[Gray] over at Geek Chique had a bit of an eBay mishap and was suddenly the proud owner of 16 Vocera B1000A badges. If you are not familiar, these badges are small, lightweight communications devices similar to the famous Star Trek communicator, which allow users to talk to other individuals via VOIP. He was working on getting the remaining badges up and running by reimplementing the server software, and figured that since one of the badges he purchased was not working, he might as well take it apart.
It took him awhile to get the well-made badges apart, requiring a rotary tool and some elbow grease to get the job done. Inside, he found that the device was split into two circuit boards, one being the “WiFi” board, and the other the “CPU” board. The WiFi board uses a Prism WiFi chipset, which was incredibly common at the time of construction. The CPU board sports small SRAM and flash chips as you would expect, with a Texas Instruments 5490A DSP running the show.
While it remains to be seen if tearing the device down helps [Gray] to get things up and running again, it never hurts to take a closer look to see what you are working with.