Category: Internet/Web

Putting the Genie Back in the Bottle: More RedHat Legal Shenanigans with CentOS


As we celebrate the 10th anniversary of CentOS, the Community Enterprise Operating System, all is not well in Open Source Land. If you haven’t heard, CentOS “joined forces” with Red Hat while you were enjoying the Christmas holiday. And RedHat wasted little time attempting to morph CentOS into a Trademark Minefield much as RedHat has done with its other “open source” projects. If you look at the new CentOS.org web site, RedHat proclaims a New Look and New CentOS. New, indeed. You won’t see many changes other than a healthy mention of RedHat and a vast new Legal section proclaiming RedHat’s ownership of the CentOS trademark and severely restricting acceptable use of the CentOS product. It’s more than a little ironic that RedHat actually pulled off a similar stunt against CentOS back in 2005. The initial problem this time around is that RedHat doesn’t actually own the trademark, nor has RedHat attempted to register it. There are some good reasons why, and we’ll get to those in a minute.

The RedHat Legal Theory of Trademarks goes something like this. We just don’t want people to confuse other products with our brand even though we all use the same, freely available open source brands. Get it? Well let’s try again. RedHat doesn’t mind using Apache’s brand name, and SendMail’s, and MySQL’s, and about 40,000 other trademarked and copyrighted products of open source developers. But God help you if the word “RedHat” appears anywhere in your open source software aggregation.

Now RedHat would like to extend this philosophy to CentOS for the betterment of the community, of course. If successful, RedHat bullying would wipe out virtually all of the current CentOS packages available from the following providers, and thousands more would disappear as well. Here’s the list from CentOS’ own web site, but don’t expect the list to remain around very long. The mere existence of this list proves CentOS acquiescence in the development methodology employed by Amazon Linux AMIs that include CentOS as part of the AMI, AsteriskNOW, BlueOnyx, BlueQuartz, CactiEZ, CentServer, ClarkConnect, ClearOS, Elastix, FAN, FreePBX Distro, OpenNode, OpenVZ, OS Office, OVH, Parallels Virtuozzo Containers, PBX in a Flash, Proxmox images that include CentOS, SipX, SME Server, Snaplogic, trixbox, trixswitch, VicidialNOW, most of the Virtual Machines and hosted platforms that rely upon CentOS with any other included application. And the list goes on. To give you some idea of how pervasive CentOS is in the products of other developers, try Googling: built atop centos which returns over 21 million results.

In a nutshell, the new RedHat Terms of Service outlaw use of CentOS in any productunless the combined distribution is an official CentOS distribution.” In short, the open source community would be transformed into the functional equivalent of the Windows and Mac platforms. End-users could independently install CentOS and then acquire apps to run under CentOS, but CentOS could no longer be included with the application itself. Well, not so fast, Mr. RedHat.

Even though the evidence trail is quickly disappearing, there’s still plenty of CentOS history that suggests things may not work out quite as well for RedHat this time around. First, there is the CentOS “Social Contract” with the Open Source Software Community and The cAos Foundation’s Open Source Software Guidelines, both of which have conveniently disappeared from the CentOS web site. For history buffs, the cAos Foundation was the developer of the CentOS aggregation. If there’s one overriding principle in both trademark law and open source software development under the GPL, it’s this: YOU CAN’T UNRING A BELL. A license once given cannot be withdrawn at the whim of a new owner, even RedHat. Here’s an excerpt from their “Social Contract.” Pay particular attention to the last paragraph:

Another problematic issue is ownership of the trademark itself. You can certainly own a trademark without registering it with the U.S. Patent & Trademark Office. But… since inception, the cAos Foundation has gone to great lengths not to ever enforce, proclaim™, or protect its trademark in CentOS. The reason is simple. They viewed CentOS as a community project which was free for everyone in the community to use and integrate as they saw fit. Thus it is more than a little puzzling that a single developer would finally file a USPTO trademark application for “CENTOS” (note the capitalization and compare to RedHat’s view of the universe) six months ago claiming that he individually owned the mark. Quite the contrary, the cAos Foundation referenced its CentOS brand as early as 2004.

This, of course, raises some additional problems with RedHat’s claim of CentOS trademark and service mark ownership. From a legal standpoint, owners of trademarks are obligated to police the use of their marks to avoid Dilution either by third parties or by tarnishment. Without delving too deeply in the legal weeds, suffice it to say the CentOS mark suffers from dilution on both counts over a period of almost 10 years! This is as it should be actually. CentOS was intended to be a community resource for everyone in the community to be able to use, integrate, and build upon. Because of its inherent non-commercial character, it was never intended to be a brand for independent marketing.

A third trademark infirmity for the CentOS brand is the fact that it’s suffering from genericide. In Plain English, CentOS has become a household word. In the Linux community, it signifies a generic open source Linux operating system. Just as with aspirin and thermos bottles, “a majority of the relevant public [has] appropriated the name of the product… [and, in essence,] the owners are victims of their own success.”

And then there’s the matter of licensing. In addition to the “Social Contract” referenced above and upon which many developers relied, there’s also a financial angle. Individual developers reportedly have been given either express or implied authorization to integrate CentOS into their software products in exchange for financial contributions to the “CentOS project.” We’ll have more to say about that in our Petition for Cancellation and Opposition to Registration of the CentOS trademark, if the trademark is ever approved for publication. We trust many other developers will file petitions as well. You can review the procedure here. You can follow the CentOS trademark saga here. Be advised that an Opposition to Registration (section 202) must be filed with the Trademark Trial and Appeal Board within 30 days of the date a mark is approved for publication in the USPTO’s Official Gazette. A sample Petition for Cancellation (section 307) is available here. You do not have to be a lawyer to file it. You do have to pay the $300 filing fee. The safest way to monitor approval is by regularly checking the Status of the CENTOS Trademark and Service Mark Application.

Licensing issues aside, there’s a more serious issue moving forward. Most companies used CentOS so they wouldn’t have to pay for Red Hat Enterprise Linux. Now Red Hat has bought CentOS. Guess what? Is it just a matter of time until CentOS is crippled so that it cannot serve as a drop-in replacement for Red Hat’s Cash Cow? Duh! Did the CentOS development team care about this? Probably not. Might not have even considered it. They got money and cushy jobs out of the deal. But, just because Red Hat offers financial rewards to a handful of CentOS developers is no reason to scuttle the development efforts of thousands of independent developers over the last decade. Better think twice, RedHat. The open source community will be watching.

Originally published: Monday, January 20, 2014




Need help with Asterisk? Visit the PBX in a Flash Forum.


whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for all of us.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity. 


Some Recent Nerd Vittles Articles of Interest…

Adventures in Twitterland: You Can’t Make This Stuff Up

Today is Twitter’s Coming Out Party with what could be 2013′s Biggest IPO. By the closing bell today, the U.S. probably will have a couple new billionaires. As one commenter on USA Today’s site noted, “I can’t get into the IPO. I’m too busy tweeting.” Unfortunately, we’re not.

Having just returned from a quick visit to New York earlier this week, we were greeted by the following message when we logged into our Twitter account:

Why is my account suspended? Well, it could be that you’ve violated “The Twitter Rules” or maybe Twitter suspects that your account was hacked or compromised. I’m reminded of the old playground adage: It’s For Me To Know and You to Find Out. Urban Dictionary has an interesting take on what that really means.

Imagine if you will that you’re walking down the street in your favorite town minding your own business when a cop grabs you by the collar and says, “You’re under arrest.” The natural inclination would be to ask why. Rather than tell you, the police officer hands you a copy of the municipal code with the admonition that you can always appeal.

Welcome to The World According to Twitter. Here you are assumed to know what you did wrong. And, if you don’t like the consequences, you can file “an appeal” after reading “The Rules”. All of that, of course, is perfectly fine if you actually broke “The Rules” and know what you did. Joseph Heller couldn’t have made this up. If you’ve read Catch 22, you’ll recall that “the term was introduced by Doc Daneeka, an army psychiatrist who invokes ‘Catch 22′ to explain why any pilot requesting mental evaluation for insanity — hoping to be found not sane enough to fly and thereby escape dangerous missions [during World War II] — demonstrates his own sanity in making the request and thus cannot be declared insane.”

We, of course, use Twitter for fun and to support our open source projects so there’s no financial hardship from Twitter’s antics while we endure “the appellate process.” But, put yourself in the position of a business person with thousands of followers and suppose you actually used Twitter to announce new products and merchandise sales. Don’t!

As you can see from the screenshot above, all of a sudden you have 0 Followers. So your entire business model is basically down the toilet at the sole discretion of Twitter. In case you’re curious, no, we haven’t violated any of Twitter’s rules. We still used to send a couple of tweets a day as we have since opening our account years ago. Has our account been hacked? Obviously not. We still can get into it, and there are no tweets from us offering you a million bucks for managing some African prince’s business affairs.

In becoming a public company today, one would hope this situation will be addressed. But then I’m reminded of our Comcast adventures and some of the horror stories you hear about Facebook, and it’s probably safe to conclude that the Borg was probably right: “Resistance is futile.” We’ve been patiently waiting 2 days for “our appeal” to be processed. We’ll let you know if we ever hear anything further. In the meantime, I’d hold off on that Twitter stock purchase.

If you happen to have a (working) Twitter account, do us and your friends a favor. Send a tweet to your followers about this article by clicking on the link below. Happy Tweeting!

1 p.m. Update. Surprise! Well, we’re back… kinda, sorta. Twitter let us out of jail but kept our pants and car keys. Following = 0, Followers = 0. No call. No email. Not even a tweet. Love means never having to say you’re sorry. Nice!

2:30 p.m. Update. Pants and car keys returned. Thanks a billion, Twitter. You’re the best.

Originally published: Thursday, November 7, 2013

WebRTC: Asterisk Joins the Brave New World of Real Time Communications

This week we’ll be wading into the world of real time communications and the Asterisk® 11 implementation of WebRTC, a JavaScript API that makes it easy to build click-to-call systems and softphone interfaces using nothing more than a web page. To simplify the task of creating an Asterisk 11/WebRTC platform, we’ve created a free virtual appliance for you that can be deployed in a matter of minutes on any Windows®, Mac®, Linux® or Solaris® desktop using Oracle’s VirtualBox®. In producing this WebRTC implementation, the Asterisk Dev Team has introduced an impressive new set of (stable) features formerly lacking in Asterisk: SRTP for secure communications, ICE, STUN, and TURN to allow NAT clients to better communicate with Asterisk. As the old saying goes, a picture is worth a thousand words. So let’s begin with a one-minute video that actually demonstrates Asterisk WebRTC in action. Using nothing more than a Chrome browser, we’re connecting to a web site hosted on the PBX in a Flash™ appliance to dial a news application that’s part of the included Incredible PBX™ 11 build.


Before we walk you through deploying your own WebRTC platform with Asterisk 11, let’s quickly cover some of the WebRTC basics as they apply in the Asterisk environment.

Rolling Your Own. If you’re one of the purists that prefers to roll your own server, then the starting point for your build should be the Asterisk Wiki. The other important component is sipml5, Doubango Telecom‘s terrific HTML5 SIP client. It’s the actual interface demonstrated in the YouTube video above. And this link provides a failsafe recipe for bringing up WebRTC on any Asterisk 11 server. Our appliance just saves you the one-hour hassle. We’ve chosen not to deploy WebRTC2SIP, the middleware that’s currently necessary if you want to add video support to Asterisk WebRTC. And our current build only works with the latest Chrome browser; however, WebRTC4all is available if you prefer Safari, Opera, Firefox, or Internet Explorer. All of the documentation for these components is provided in the links above for our pioneers.

Why WebRTC? Some of you may be asking, “What’s the big deal? Why would I want to deploy WebRTC?” The short answer is that it eliminates the need to install and configure a proprietary softphone on every customers’ desktop computer before they can communicate. Instead, all they need is a web browser that supports Real-Time Communications. By pointing their browser to a server address that you provide, the customer instantly gains a communications platform that’s as feature-rich as you choose to make it. And it’s comparable to the dedicated clients of old… without the cost or hassle of marrying a softphone to every customer’s particular desktop operating system! And your web page could easily provide a directory of supported contact names and numbers as part of the user interface.


The other beauty of WebRTC is it allows you to create your own (secure) Skype-like communications system without a Man in the Middle. And all you need is a browser at both ends. The WebRTC video above demonstrates a video conversation between a Chrome user at Google and a Firefox user at Mozilla.

Deploying PIAF-Green-WebRTC. So much for the theory. Let’s get your own server set up so you can experiment with this yourself. Here are the steps. It’s about a 10-minute procedure once you’ve downloaded our virtual machine appliance from SourceForge.

  1. Install Oracle’s VirtualBox on your Desktop computer
  2. Download PIAF-Green-WebRTC
  3. Import PIAF-Green-WebRTC into VirtualBox
  4. Start the PIAF-Green-WebRTC Appliance
  5. Using Chrome, Access the WebRTC Page Hosted on PIAF-Green-WebRTC
  6. Configure sipml5 to Make a Connection Using an Asterisk Extension
  7. Place Your First Call

1. Install Oracle’s VirtualBox. Download the VirtualBox installer for your desktop platform from VirtualBox.org. Run the installer and accept the default settings. For details, here’s a link to Oracle’s VM VirtualBox User Manual.

2. Download PIAF-Green-WebRTC. To get PIAF-Green-WebRTC installed on your desktop is quick and easy. Because the image tips the scales at over 2GB and due to the 2GB file size limit on many systems, we’ve chosen to split the download into two pieces. You need both of them! Just download them onto any flavor desktop from SourceForge. Once you’ve downloaded the two files, reassemble them into a single file known as an Open Virtualization Appliance (.ova). Then verify the checksums for the reassembled file to be sure everything is in its proper place. Finally, double-click on the .ova file which will initiate the import process into VirtualBox.

So let’s begin by downloading the two halves from SourceForge: PIAF20631aa and PIAF20631ab.

The reassembly procedure depends upon your desktop operating system. For Windows PCs, you’ll need to drop down to the Command Prompt, change to the directory in which you downloaded the two files, and type the following command:
 
copy /b PIAF20631aa + PIAF20631ab PIAF-Green-WebRTC.ova

To check the MD5/SHA1 checksums in Windows, download and run Microsoft’s File Checksum Integrity Verifier.

For Mac or Linux desktops, open a Terminal window, change to the directory in which you downloaded the two files, and type the following commands:
 
cat PIAF20631a{a..b} > PIAF-Green-WebRTC.ova
md5 PIAF-Green-WebRTC.ova (use md5sum for Linux)
openssl sha1 PIAF-Green-WebRTC.ova

The MD5 checksum for PIAF-Green-WebRTC.ova is 946c149c6adb53602ccfcd3ace10e13b. The SHA1 checksum is 285a5b999c761fcbef13d1a97b4c335a81e1cb0d. If you have a match, proceed. Otherwise, rinse and repeat.

3. Import PIAF-Green-WebRTC into VirtualBox. You only perform the import step one time. Once imported into VirtualBox, PIAF-Green-WebRTC is ready to use. There’s no further installation required, just like an OpenVZ template… only better. Double-click on the .ova file you downloaded to begin the procedure and load VirtualBox. When prompted, be sure to check the Reinitialize the Mac address of all network cards box. Read and accept the license agreement. Then click the Import button. Once the import is finished, you’ll see a new PIAF-Green-WebRTC virtual machine in your VM List on the VirtualBox Manager Window. You need to make a couple of one-time adjustments to the PIAF-Green-WebRTC Virtual Machine configuration to account for differences in sound and network cards on different host machines.

Click on PIAF-Green-WebRTC Virtual Machine in the VM List. Then click Settings -> Audio and check the Enable Audio option and choose your sound card. Save your setup by clicking the OK button. Next click Settings -> Network. For Adapter 1, check the Enable Network Adapter option. From the Attached to pull-down menu, choose Bridged Adapter. Then select your network card from the Name list. Then click OK to save your setup. Finally, click Settings -> System, uncheck Hardware clock in UTC time, and click OK. That’s all the configuration that is necessary for the PIAF-Green-WebRTC Virtual Machine. If you blinked, you probably missed it.

4. Start the PIAF-Green-WebRTC Appliance. Once you’ve imported and configured your new Virtual Machine, you’re ready to go. Highlight the appliance in the VM List on the VirtualBox Manager Window and click the Start button. The boot procedure with CentOS 6.3 will begin just as if you had installed PBX in a Flash and Incredible PBX on a standalone machine. You’ll see a couple of dialogue boxes pop up that explain the keystrokes to move back and forth between your host operating system desktop and Incredible PBX.

Here’s what you need to know. To work in the Virtual Machine, just left-click your mouse while it is positioned inside the VM window. To return to your host operating system desktop, press the right Option key on Windows machines or the left Command key on any Mac. For other operating systems, read the dialogue boxes for instructions on moving around. Always shut down your virtual machine gracefully! Click in the VM window with your mouse, log in as root, and type: shutdown -h now. Or, from the VirtualBox Manager Window, Ctl-Click on the PIAF-Green-WebRTC VM and choose Close -> ACPI Shutdown.

Always run Virtual Machines behind a hardware-based firewall with no Internet port exposure!

To begin, position your mouse over the VM window and left-click. Once the virtual machine has booted, log in as root with password as the password. Change your root password immediately by typing passwd at the command prompt. Now set up a secure maint password for FreePBX as well. Type passwd-master. If you’re not in the Eastern U.S. time zone, then you’ll want to adjust your timezone setting so that reminders and other time-sensitive events happen at the correct time. Issue the following command to pick your time zone: /root/timezone-setup. Now type status and write down the IP address of your appliance. Finally, edit /etc/asterisk/sip_custom.conf and replace the secret=8000 entry with a very secure password. This is your WebRTC extension password. Restart Asterisk: amportal restart.

5. Access WebRTC Page Hosted on PIAF-Green-WebRTC Using the latest Chrome browser from a machine on the same subnet as your appliance, point to the WebRTC web page of your appliance using the actual IP address of your virtual machine: http://192.168.0.141/myphone/call.htm.

6. Configure sipml5 to Make a Connection to Asterisk. There are two configuration steps before you can log in and start making calls through your Asterisk server. First, click on the Expert Mode button. Fill out the form as shown below using the actual IP address of your server. Click Save when you’re finished, close this browser window, and return to the main WebRTC page.

Next, fill out the Registration section using the actual IP address of your server and the extension 8000 password that you created above. Private Identity is 8000, Public Identity is sip:8000@ipaddress, Realm is Asterisk ipaddress.

Once you’ve completed your entries, click Login to make a connection to your Asterisk server.

7. Placing a Call with WebRTC. Once you’re logged in, it’s just as if you had registered a softphone to your Asterisk server. Calls from other extensions can reach you by dialing extension 8000. And you can place outbound calls using the Call Control panel. To demonstrate how this works, try the following. To retrieve Today’s News Headlines, enter 951. Then click the Call button. To retrieve the latest Weather Forecast for your city, dial 949 and say the city and state when prompted. You can’t enter touchtone keys so just ignore the “press pound” instruction and wait for the timeout.

We have intentionally not walked you through configuring an outbound trunk even though one can easily be used to make outbound calls. Before doing so, make very certain that your appliance is behind a hardware-based firewall with no Internet port exposure. It’s your phone bill. Enjoy!

WebRTC Conference and Expo. The 2013 WebRTC Conference and Expo is returning to Atlanta on June 25. For everything you ever wanted to know about WebRTC, that’s the place to be. You can sign up now at WebRTCWorld.com. The Half-Price Early Bird discount ends on March 1. And you can save an additional 15% by using Coupon Code: AA.

Originally published: Tuesday, February 26, 2013



Need help with Asterisk? Visit the PBX in a Flash Forum.

 


Some Recent Nerd Vittles Articles of Interest…

The Bluetooth Revolution: Watch What We Can Do

If ever there’s been a sleeping technology giant still worth watching, it’s got to be Bluetooth. Originally developed by Ericsson, the Swedish telecommunications company, Bluetooth is a proprietary wireless technology for exchanging data over short distances using fixed and mobile devices. If you use it at all, it’s probably to answer phone calls and play music in your car using your smartphone or to walk around looking like a lunatic talking to yourself because you have a Bluetooth headset for your cellphone hanging out of your ear. Or you may be using our Bluetooth Proximity Detection utility to automatically forward calls from your PBX in a Flash server to your cellphone when you leave the office. Well, that’s so last week!

What’s coming in tomorrow’s vehicles (unless the federal government gets too crazy) is literally a revolution in the way vehicles interact with your smartphone. Rather than buying all of your existing cellphone technology again in every car you own, Bluetooth will give you a dashboard with the rich feature set of your existing smartphone without another monthly cellphone bill. That’s right. All of the data will be delivered to your dashboard via Bluetooth using middleware that translates existing information on your cellphone to a display on your dash. And you’ll be able to control the flow and type of information using a touchscreen in your car or truck that bears an uncanny resemblance to the display on your iPad or Android Tablet. See why you might really need a quad-core processor on your next smartphone?


I’m sorry. Did we say in tomorrow’s vehicles? You actually can get it right now in the Prius V with Entune. Of course, Toyota would like to replace your cellphone carrier and charge you monthly fees for services you’re already paying for on your cellphone, but that will sort itself out shortly. Why? Because there are some new open source experiments underway using Android instead of our old friend Micro$oft.

Meet The Watch. Suppose you were a nerd and just graduated from college with nothing to do except beg for a job flipping burgers. But then you had this idea to create a Bluetooth-enabled watch that could display content from your cellphone while you were driving, or running, or swimming. Well, you’d probably turn to KickStarter and try to raise $100,000 so you could build your dream watch. That was six weeks ago. They raised nearly $1 million the first day. And, by the time the fund-raising campaign ends in mid-May, it looks like this project will have raised nearly 10 million dollars!

Nice Surprise. So now you have the background on coming attractions. But there’s more. There’s the company that inspired Steve Jobs doing what they once did better than anyone on the planet, quietly churning out incredible products while nobody was looking. Meet Sony and the SmartWatch.

If you want a glimpse at what tomorrow’s vehicles will look like, the Sony SmartWatch is the one to follow. It’s in living color. It’s feature-rich. And it just works! Released in the United States three short weeks ago, there already are nearly 50 available Android applications (mostly free) that you can display on your watch. Here’s a sampling to give you some idea of the scope. We loaded a dozen on our SmartWatch in minutes!

You actually manage and download apps for your SmartWatch using Sony’s LiveWare Manager which lives on your Android phone. And, yes, almost any Android phone will work although a higher end device with more memory is a definite plus. You won’t want just a couple of apps once you get started.

We, of course, took one look at this watch and decided it was a perfect platform on which to display network management information about your PBX in a Flash communications servers or any other server. Keep reading!

One of the terrific apps for the SmartPhone is called Traffic Cams which does just what you’d think. It displays live web cam images from traffic cameras using GPS technology to figure out which ones are closest to you. Very slick! As you can see, we have some stunning ones within a mile of our home. And if you depend upon bridges to get to where you need to go, you’ll soon learn how indispensable these traffic cams really are. The camera shown above actually faces due east. For a real treat, come visit Nerd Vittles at 6:30 a.m. EDT (this time of the year) and enjoy the sunrise. Stunning!

HINT: The image shows the local time if you are timezone-challenged. It is refreshed every 3-4 minutes during the day.

Update: Wondering why this bridge is so empty? Check our SmartWatch! Pays to use more than one traffic camera when you set this up.

A bonus from the app is the ability to display your own 200×200 images on the watch from any public web site. So we whipped together a quick-and-dirty script that extracts status information about your PBX in a Flash server and converts it with ImageMagick (Don’t Forget: yum install ImageMagick) into a couple of jpeg images. Using FTP, these images then can be uploaded to a public web server and displayed on the phone. If you like the code and want to see what else is possible using the SmartWatch, come follow our progress on the PBX in a Flash Forum. Enjoy your new watch! Here’s a short list showing where to get a great deal on one.

Originally published: Monday, April 30, 2012




Need help with Asterisk®? Visit the NEW PBX in a Flash Forum.


whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest…

Introducing NeoRouter VPN: A Star Is Born

In our last article, we introduced PPTP VPNs for interconnecting remote users and branch offices to a central network hub. Known as a hub-and-spoke VPN, the advantage of this design is it lets remote users participate as peers in an existing home office LAN. It’s simple to set up and easy to maintain. The drawback is vulnerability to man-in-the-middle attacks.

Today, we want to turn our attention to the more traditional client-server VPN which still relies upon a central server but uses a star topology to connect remote nodes. The major difference is that only registered devices participate in the virtual private network so there is no direct access to other machines on the LANs of the registered devices. If you have servers scattered all over the countryside, this is an excellent way to manage and interconnect them. All data and communications between the nodes can then be routed through the encrypted VPN tunnel for rock-solid security.

With NeoRouter’s free software, you can set up your VPN server using a PC, a Mac, a Linux or FreeBSD machine, OpenWrt Backfire, and Tomato. VPN clients are available for PCs, Macs, Linux and FreeBSD PCs, OpenWrt, Tomato as well as Android phones and tablets. There’s even an HTML5 web application in addition to a Chrome browser plug-in. With the OpenWrt and Tomato devices or if you’re an extreme techie, you can broaden your NeoRouter star configuration to include bridging of remote LANs. See pp. 47-50 of the NeoRouter User’s Manual. And you can interconnect up to 256 devices at no cost. For $999, you can enlarge your VPN to support 1,000 devices. Screen sharing, remote desktop connections, HTTP, and SSH access all work transparently using private IP addresses of the VPN nodes which are automatically assigned to the 10.0.0.0 private network.

You may be wondering why we’ve moved on from Hamachi. Suffice it to say, LogMeIn has put the squeeze on the free version to the point that it’s now next to worthless. In fact, you’d be hard-pressed to find any mention of a free version of Hamachi (other than a trial edition) on LogMeIn’s current web site. Here’s a feature comparison which says it better than we could:

Today we are introducing the first of two NeoRouter VPN solutions. First, we have a simple installation script that works with any PBX in a Flash 2™ server. See also our more recent column for the dedicated server edition of NeoRouter VPN known as VPN in a Flash. It’s suitable for use on a dedicated server or running as a virtual machine. For smaller VPNs, we prefer the add-on module for PBX in a Flash. For larger deployments, you probably should opt for the dedicated machine. It also isolates your VPN server from your PBX which generally is the better network strategy. Regardless of the installation scenario you choose, keep in mind that neither option requires exposure of your entire server to the Internet. Only a single TCP port needs to be opened in your hardware-based firewall and IPtables Linux firewall.

NeoRouter Setup with PIAF2™. We’re assuming you already have a PBX in a Flash 2 server set up behind a hardware-based firewall. If not, start there. Next, we’ll need to download and run the installer for your new NeoRouter Server. It also installs the client. Just log into your server as root and issue the following commands:

wget http://incrediblepbx.com/install-neorouter
chmod +x install-neorouter
./install-neorouter

The installer will walk you through these five installation steps, but we’ll repeat them here so you have a ready reference down the road.

First, on your hardware-based firewall, map TCP port 32976 to the private IP address of your PIAF2 server. This tells the router to send all NeoRouter VPN traffic to your PIAF2 server when it hits your firewall. If you forget this step, your NeoRouter VPN will never work!

Second, we’re going to use your server’s public IP address as the destination for incoming traffic to your NeoRouter VPN. If this is a dynamic IP address, you’ll need an FQDN that’s kept current by a service such as DynDNS.com.

Third, each administrator and user is going to need a username to access your NeoRouter VPN. You can use the same credentials to log in from multiple client machines, something you may or may not want to do. We’re going to set up credentials for one administrator as part of the install. You can add extra ones by adding entries with one of the following commands using the keyword admin or user. Don’t use any special characters in the username and password!

nrserver -adduser username password admin
nrserver -adduser username password user

Fourth, make up a very secure password to access your NeoRouter VPN. No special characters.

You’re done. Review your entries very carefully. If all is well, press Enter. If you blink, you may miss the completion of the install process. It’s that quick.

Fifth, after your NeoRouter VPN is installed, you can optionally go to the NeoRouter web site and register your new VPN by clicking Create Standalone Domain. Make up a name you can easily remember with no periods or spaces. You’ll be prompted for the IP address of your server in the second screen. FQDNs are NOT permitted.

When a VPN client attempts to login to your server, the server address is always checked against this NeoRouter database first before any attempt is made to resolve an IP address or FQDN using DNS. If no matching entry is found, it will register directly to your server using a DNS lookup of the FQDN. Whether to register your VPN is totally up to you. Logins obviously occur quicker using this registered VPN name, but logins won’t happen at all if your server’s dynamic IP address changes and you’ve hard-coded a different IP address into your registration at neorouter.com.

Setting Up a NeoRouter Client. As mentioned previously, there are NeoRouter clients available for almost every platform imaginable, except iPhones and iPads. Hopefully, they’re in the works. So Step #1 is to download whatever clients are appropriate to meet your requirements. Here’s the NeoRouter Download Link. Make sure you choose a client for the Free version of NeoRouter. And make sure it is a version 1.7 client! Obviously, the computing platform needs to match your client device. The clients can be installed in the traditional way with Windows machines, Macs, etc.

CentOS NeoRouter Client. As part of the installation above, we have automatically installed the NeoRouter client for your particular flavor of CentOS 6, 32-bit or 64-bit. In order to access resources on your NeoRouter server from other clients, you will need to activate the client on your server as well. This gets the server a private IP address in the 10.0.0.0 network.

To activate the client, type: nrclientcmd. You’ll be prompted for your Domain, Username, and Password. You can use the registered domain name from neorouter.com if you completed step #5. Or you can use the private IP address of your server. If your router supports hairpin NAT, you can use the public IP address or server’s FQDN, if you have one. After you complete the entries, you’ll get a display that looks something like this:

To exit from NeoRouter Explorer, type: quit. The NeoRouter client will continue to run so you can use the displayed private IP addresses to connect to any other online devices in your NeoRouter VPN. All traffic from connections to devices in the 10.0.0.0 network will flow through NeoRouter’s encrypted VPN tunnel. This includes inter-office SIP and IAX communications between Asterisk® endpoints.

Admin Tools for NeoRouter. Here are a few helpful commands for monitoring and managing your NeoRouter VPN.

Browser access to NeoRouter Configuration Explorer (requires user with Admin privileges)

Browser access to NeoRouter Network Explorer (user with Admin or User privileges)

To access your NeoRouter Linux client: nrclientcmd

To restart NeoRouter Linux client: /etc/rc.d/init.d/nrservice.sh restart

To restart NeoRouter Linux server: /etc/rc.d/init.d/nrserver.sh restart

To set domain: nrserver -setdomain YOUR-VPN-NAME domainpassword

For a list of client devices: nrserver -showcomputers

For a list of existing user accounts: nrserver -showusers

For the settings of your NeoRouter VPN: nrserver -showsettings

To add a user account: nrserver -adduser username password user

To add admin account: nrserver -adduser username password admin

Test VPN access: http://www.neorouter.com/checkport.php

For a complete list of commands: nrserver –help

To change client name from default pbx.local1:

  • Edit /etc/hosts
  • Edit /etc/sysconfig/network
  • Edit /etc/sysconfig/network-scripts/ifcfg-eth0
  • Edit /etc/asterisk/vm_general.inc
  • reboot

For the latest NeoRouter happenings, follow the NeoRouter blog on WordPress.com.

GPL2 License. The install-neorouter application is open source software licensed under GPL2. The NeoRouter Server and Client software is freeware but not open source. This installer has been specifically tailored for use on PBX in a Flash 2 servers, but it can easily be adjusted to work with virtually any Linux-based Asterisk system. If you make additions or changes, we hope you’ll share them on our forums for the benefit of the entire VoIP community. Enjoy!

Originally published: Wednesday, April 18, 2012




Need help with Asterisk? Visit the NEW PBX in a Flash Forum.


whos.amung.us If you’re wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what’s happening. It’s a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest…

  1. We’ve built a script to rename your PIAF2 server in all the right places. You can download it here. []

Travelin’ Man 3: Securing a PIAF2 or VoIP in the Cloud Server

We're big fans of playing with our own VoIP hardware. It has the advantage of allowing the installation of everything behind a secure, hardware-based firewall thereby eliminating almost all of the security issues associated with VoIP telephony. With PBX in a Flash™ and its Zero Internet Footprint™, you can run a secure VoIP server in your home or office with no port exposure to the Internet. This setup, of course, assumes that you have the necessary bandwidth to support Internet telephony and that you possess the necessary skill set to maintain your own Linux® server running Asterisk®, FreePBX®, Apache®, SendMail®, PHP®, and on and on. Not everyone does. And, of course, there are thousands of organizations in which employees and their phones are not colocated with the home office VoIP communications server. And, believe it or not, there are folks that run their VoIP server on the public Internet without any firewall protection. For all of you, today's your lucky day.

Lest you think that we've bitten off more than we can chew, we want to acknowledge the dozens of thought-provoking comments on the PIAF Forums that ultimately led to today's new release. That is the hidden beauty of open source development. So, thank you dad311, atsak, tbrummell, Hyksos, markieb, Ramblin, darmock, lowno, blanchae, bmore, vcallaway, jroper, mag, briankelly63, mbellot, phonebuff, The Deacon, Astrosmurfer, frontline, ou812, LostTrunk, lgaetz, kh40s, rossiv, and all of our other gurus that make the PIAF Forums a great place to learn something new every day.

Thanks to our good friends at RentPBX, who provide terrific technical and financial support to both Nerd Vittles and the PBX in a Flash project, you don't have to roll your own. And your phones can be anywhere because your communications server sits on the public Internet. If cost is a factor or for those outside the United States that need a U.S. presence to take advantage of services such as Google Voice, the $15 a month price point using the PIAF2012 coupon code makes RentPBX more than competitive with what it would cost you in electricity, Internet bandwidth, and hardware resources to do it yourself... minus the headaches. You get a stable PBX in a Flash or Incredible PBX platform from the git-go. In addition, issues of jitter and latency all but disappear from the VoIP equation because you can choose the site of your hosted PBX from a worldwide list of Internet POPs including five regions in the U.S. as well as Canada and Europe. Many sit within a few milliseconds of the Internet backbone.

What you don't have with a hosted PBX solution is a hardware-based firewall sitting between your server and the Big, Bad Internet. With PBX in a Flash, the risk is lessened because the IPtables Linux Firewall is baked into the fabric of PBX in a Flash. For a comprehensive overview of how IPtables works, read this article. It explains IPtables better than any book you could buy.

Today we're pleased to introduce Travelin' Man 3™, a completely new security methodology based upon FQDN Whitelists and DDNS. In a nutshell, you get set-it-and-forget-it convenience and rock-solid VoIP security for your Cloud-based PBX or any PBX in a Flash server that's lacking a hardware-based firewall and you get both transparent connectivity and security for your mobile or remote workforce. We'll quickly cover the mechanics of this new IPtables methodology that allows you to secure your hosted PBX without compromising flexibility. The nitty gritty details of IPtables and firewalls we'll leave for you to explore at your leisure.

And, speaking of leisure, we always get the question: "Have you tested it?" For frequent readers of Nerd Vittles, you already know the answer. We eat our own dog food! In the case of Travelin' Man 3, we gave it a healthy workout just last week from the deck of the Carnival Fantasy as we passed by Cape Canaveral and in Key West with 4G service, and finally in several ports with WiFi access in the Bahamas. The beauty of the new design is you'll know instantly if it's not working because you'll never get your VoIP SIP phone to connect back to your VoIP server. We had zero problems using nothing more than an Android phone for both DynDNS updates and Bria SIP phone service. Being a pioneer isn't always easy, but... Somebody's gotta do it™. :wink:

Unlike previous iterations of Travelin' Man, version 3 lets you configure remote phone access from the server and keep one or hundreds of phones in sync even with changing IP addresses using dynamic DNS update software at the sites of the remote phones. Whether the site is a remote office or a floating hotel room, any PC or Mac whether it's a desktop or netbook can automatically manage the dynamic DNS updates while keeping all of the local phones securely connected to the VoIP Cloud. And any jail-broken iPhone can manage the updates as well. With Android phones, it's even better. You have your pick of several great apps: DynDNS Client, Dynamic DNS Client, or Dynamic DNS Updater. We've found the DynDNS Client to be nearly perfect. As we'll explain in a minute, this version of Travelin' Man is not compatible with prior versions so you'll need to choose either the manual methodology of previous iterations or version 3 which does it automagically.

A New Approach to WhiteLists. Our new approach to IPtables is to lock down your server using a WhiteList of safe IP addresses and fully-qualified domain names (FQDNs) that should be given access to your hosted VoIP server. Then we'll periodically check to see if the IP addresses associated with the FQDNs have changed and make the necessary adjustments automatically. If any intruder attempts to access any port on your PBX, their packets are simply discarded by IPtables so the bad guys never know your server exists.

We've experimented with BlackLists for VoIP security, and the bottom line is they just don't work because of inherent problems with reliability and completeness. You spend your entire day updating lists of the bad guys only to discover that they've morphed to thousands of new IP addresses. Think Whack-A-Mole. IP addresses can easily be changed, and zombies have made attacks from third-party PCs a daily occurrence. Earlier this month, Nerd Vittles was hit with a denial of service attack from 30,000+ zombie PCs. This was in spite of the fact that we already block well over 100,000 IP addresses with the world's finest blacklists. Now it's 130,000. :roll: Of course, none of the owners of these PCs had any idea how their computers were being used. I'm reminded of a famous judge's secretary who received a knock at her door one Sunday morning from the FBI. They informed her that she was using her computer to host porno movie downloads. I won't offend your tender sensibilities by repeating what she actually told those "young men."

There's also the problem of dynamic IP addresses which means an address that was used by a bad guy yesterday may be handed out by the same ISP to your grandma tomorrow. And it didn't take the bad guys long to poison blacklists with IP addresses that you actually need for services such as DNS or network time services. If you've ever had an IP address that ended up on one of the major blacklists, you know what a hassle it is to get your IP address unBlacklisted. The Soup Nazi has nothing on these folks.

Bottom Line: Public web sites are pretty much forced to use BlackLists because they want their sites to be generally accessible. With a VoIP server, we have the luxury of choice, and WhiteLists are much more effective for server security.

Overview. Our recommended design works like this. Block everything. Then permit packets from known hosts and non-routable IP addresses only, and limit known hosts to only the services they actually need. For example, a VoIP provider such as Vitelity that is providing a DID for your inbound calls doesn't need web access to your server. They need SIP and RTP access. Nothing more. The same goes for a remote user: SIP and RTP access so their SIP phone works. Nothing more. You, as Administrator, need complete access to the server but only from a specific, defined IP address. We, of course, don't want IPtables to have to inspect and filter every single packet flowing into and out of your server because that would bog things down. And we don't want users on your private LAN and remote users with dynamic IP addresses to have to wrestle with updating their phones just to stay connected. So, we've opened up all non-routable IP addresses and, once we've verified that a remote site is authorized access, then subsequent packets flowing into and out of the server for that IP address will be passed along without additional packet inspection. And once we set up the FQDN for a remote user, local dynamic DNS update clients can be used to automate the process of keeping IP addresses current. Then, every few minutes, we'll let your server check whether there's been a change in any users' dynamic IP addresses. If so, we'll simply refresh the IP addresses of all FQDNs using an IPtables restart to bring the phones back to life. To end users, The Phones Just Work™.

Finally, a word about security for VoIP in the Cloud servers. If you run a virtual machine from any hosting provider with wide open access to SIP, IAX, and web services, it's just a matter of time before your server is going to be compromised, period! If you foolishly use credit card auto-replenishment for one or more of your hosting providers then you might as well mail a blank check to the bad guys and wait for them to cash it. Today's tools will take you less than a minute to permanently lock down your server. So... JUST DO IT™.

To give you some idea of how far the Android platform has come, here are a couple screenshots of our Samsung 4G Skyrocket smartphone running three simultaneous VoIP apps all day, every day: Bria SIP extension to our PIAF2 server in Charleston, CSipSimple extension to our RentPBX VM in California, and GrooveIP session with Google Voice. Try that on your 3G iPhone 4S. :wink:

We're officially releasing this for RentPBX users running PBX in a Flash 2™ or Incredible PBX 3™. These folks have been our pioneers for a very long time, and we like to take care of them first. Properly installed, Travelin' Man 3 should work fine on any PIAF2™ or Incredible PBX 3 system. We'll make a backup of /etc/sysconfig/iptables before replacing your IPtables setup with the PIAF2 default setup. It assumes ALL of your traffic is flowing on eth0. If that's not the case, don't use it without major modifications! We would hasten to add that Travelin' Man 3 is licensed as GPL2 open source software. So it's available NOW to everyone to use or to embellish as they see fit. We hope every provider of VoIP services offering virtual machines in the cloud as well as those without a hardware-based firewall to protect your Asterisk server will take advantage of the opportunity to customize and deploy this code for their particular IPtables environment. To paraphrase Bill Clinton: "It's your phone bill, stupid!"

Deploying Travelin' Man 3. Here's how to deploy Travelin' Man 3 on your server. In Step #1, we run secure-iptables. This locks down virtually all IP ports and services in the original IPtables configuration for PBX in a Flash to either the IP address or the FQDN of the administrator. Be advised that this setup uses the default ports for all PIAF2 services, e.g. SSH, WebMin, HTTP, etc. If you use custom ports, you'll need to modify the script accordingly. If the administrator is on the move or has a dynamic IP address on his or her desktop or notebook PC/Mac that will be used to administer the cloud server, then use an FQDN, not a static IP address, when you run secure-iptables.

Step #2 is automatic and is part of secure-iptables. It opens SIP and IAX port access for "trusted providers" such as Google, Vitelity, etc. This is covered in detail below. We also open accessibility from non-routable IP addresses. You obviously can close or limit private LAN access, if desired. We included it for the benefit of those running and administering PBX in a Flash on private LANs where internal security is not a concern.

In Step #3, we'll let you set up additional access for other providers, users, and phones. You get your choice of up to 9 separate services to enable, and each account gets a name and a file to keep track of the latest IP address entry: somename.iptables. These are stored in /root. Don't delete them! New accounts can be added using either a static IP address (add-ip) or an FQDN (add-fqdn). These accounts also can be deleted whenever necessary (del-acct). You can rerun secure-iptables whenever you like, but it automatically deletes all custom user accounts. Here's the list of services from which to choose. Mix and match as desired to meet your own requirements.

1 - SIP (UDP)
2 - SIP (TCP)
3 - IAX
4 - Web
5 - WebMin
6 - FTP
7 - TFTP
8 - SSH
9 - FOP

Just a word of caution. IPtables stores its setup in /etc/sysconfig/iptables, but it actually runs from an image in memory on your Linux server. As part of the load process, IPtables converts all FQDNs stored on disk to static IP addresses. This speeds up firewall processing enormously. While it's possible to add IPtables rules in memory without writing them to disk (as in the original Travelin' Man design), don't do it with Travelin' Man 3! You will lose these settings whenever IPtables is restarted by running any of the above scripts or whenever a refresh of FQDN IP addresses becomes necessary. Whatever you do, never ever run the command: service iptables save. This command is used to write the IPtables entries in memory to disk. In doing so it writes only static IP addresses to disk. This will erase (a.k.a. ruin) your Travelin' Man 3 FQDN setup and force you to start over with Step #1. Otherwise, none of your FQDN's would ever get refreshed because they've all disappeared and become static IP addresses. You've been warned.

Locking Down Your Server. While there's still time, let's spend a minute and lock down your server to the public IP address of the PC that you use to administer the system. If you don't know the public IP address of the desktop machine you use to manage your server, then click on this link using a browser on that machine, and our web site will tell you the IP address.

Now log into your virtual machine as root using SSH and issue the following commands:

cd /root
wget http://incrediblepbx.com/travelinman3.tar.gz
tar zxvf travelinman3.tar.gz
./secure-iptables

When prompted for the FQDN or IP address of your Administrator PC, use the FQDN if you have one. Otherwise, type in the IP address and press the Enter key. Agree to the terms of service and license agreement by pressing Enter. When the iptables file displays, verify that you have typed your FQDN or IP address correctly, or you will lock yourself out of your own server. Press Ctrl-X to exit the editor, and then press Enter to update IPtables and save your new configuration.

WARNING: If you use an FQDN for your Administrator PC and it points to a dynamic IP address, be sure to also add this same FQDN using add-fqdn. Otherwise, IP address changes will not be detected, and you may lock yourself out of your own server.

Nobody can access your server except someone seated at your PC or on your private LAN with your login credentials. You can repeat this process as often as you like because each time the script is run, it automatically restores your original IPtables configuration. Now let's grant access to your SIP providers and those using remote SIP or IAX phones.

Using DynDNS to Manage FQDNs. The key ingredient with Travelin' Man 3 is automatic management of dynamic IP addresses. When a user or even the administrator moves to a different location or IP address, we don't want to have to manually adjust anything. So what you'll first need is a DynDNS account. For $20 a year, you can set up 30 FQDNs and keep the IP addresses for these hostnames current 24-7. For $30 a year, you can manage 75 hostnames using your own domain and execute up to 600,000 queries a month. That's more than ample for almost any small business but, if you need more horsepower, DynDNS.com can handle it. What we recommend is setting up a separate FQDN for each phone on your system that uses a dynamic IP address. This can include the administrator account if desired because it works in exactly the same way. When the administrator extension drops off the radar, a refresh of IPtables will bring all FQDNs back to life including the administrator's account. Sounds simple? It is.

Preparation. Before we make further modifications to IPtables in Step #3, let's make a list of all the folks that will need access to your VoIP Server in the Cloud. For each entry, write down the name of the person, server, or phone as well as the type of entity which needs server access. Then provide either the static IP address or FQDN for each entry. If one or more of your IP addresses are dynamic (meaning the ISP changes them from time to time), we'll cover managing dynamic IP addresses in a minute. For now, just make up a fully-qualified domain name (FQDN) for each dynamic IP address using one of the available DynDNS domains. For static IP addresses, use the FQDN or the IP address. HINT: FQDNs make it easy to remember which entry goes with which provider.

Make a list of your providers NOT in this list: Vitelity (outbound1.vitelity.net and inbound1.vitelity.net), Google Voice (talk.google.com), VoIP.ms (city.voip.ms), DIDforsale (209.216.2.211), CallCentric (callcentric.com), and also SIPgate.com (sipgate.com), VoIPStreet.com (chi-out.voipstreet.com plus chi-in.voipstreet.com), Les.net (did.voip.les.net), Future-Nine, AxVoice (magnum.axvoice.com), SIP2SIP (proxy.sipthor.net), VoIPMyWay (sip.voipwelcome.com), Teliax, and IPkall. The providers listed above are already enabled in the secure-iptables setup script. We call them Trusted Providers only because we trust them and have personally used all of them. We consider them reliable folks with whom to do business. It doesn't mean others aren't. It simply means these are ones we have tested with good results over the years. The only providers you'll need to add are ones we haven't provided. Also be sure to check whether the FQDNs of the providers above cover the server for your account. If not, you'll need to manually add those FQDNs as well. Keep in mind that trusted providers will have full SIP and IAX access to your server so stick with tried-and-true providers for your own safety. The PBX in a Flash Forum and DSL Reports are good sources of information on The Good, The Bad, and The Ugly.

Finally, list with a name each phone that will be connected to an extension on your server. If you have 10 traveling salesmen, then you might want to name them all by last name and also provide FQDNs with their last names, e.g. smith.dyndns.org and jones.dyndns.org. No spaces or punctuation in names or FQDNs! We strongly recommend using FQDNs wherever you can because it means zero work for you when a provider changes an IP address. Here's the table we use:

Name
Type: Person, Provider, Server, Phone
IP Address Type: Static or Dynamic
FQDN or IP Address
Services Desired: SIP, IAX, Web, FTP, SSH, etc.

Step #3: Adding Authorized Users. Now take your list and add each account to your server while logged in as root and positioned in the /root directory. For static IP addresses, use add-ip. For dynamic IP addresses and FQDNs, run add-fqdn and plug in the FQDN for each account. When one of your accounts needs to be removed, just run del-acct from the /root folder on your server and plug in the name of the account to delete. If a user changes from a static IP address to a dynamic IP address or vice versa, just delete the user and then add them again with the new IP address or FQDN. All of the accounts are stored in /root and have names like this: name.iptables.

Step #4: Setting Up DynDNS Client Updates. There are actually two pieces in the Dynamic DNS update puzzle. At the end-user side, you need to deploy a DynDNS update client on the same subnet as the phone of your user. See the links above to download the update software you prefer. In the case of cellphones with SIP phone capability, this could be as simple as installing the DynDNS update client directly on the phone itself. Plug in your DynDNS credentials as well as the FQDN associated with the particular phone, and the rest is automatic.

Step #5: Setting Up IPtables Auto-Refresh. Finally, we need a way for your server to discover when a refresh of FQDNs becomes necessary because someone's IP address has changed. The simplest way to do this is to automatically run a simple script (ipchecker) that polls the DNS authoritative server to determine whether the dynamic IP address associated with an FQDN has changed. If so, we'll update the account.iptables file to reflect the new IP address and then restart IPtables. This will refresh all IP addresses associated with FQDNs. If all or most of your users spend time sleeping each day, you may wish to run the script only during certain (waking) hours of the day so your server has less of a load. The other consideration is how often to check. The guideline here is how long can any user live without their SIP phone being connected to your server. 10 minutes may be reasonable for some. 60 minutes may suffice for others. For us, it's 3 minutes. It's your choice. The way Travelin' Man 3 works is, whenever at least one account has an IP address change, it will trigger a restart of IPtables to do an IP address refresh for all of the FQDNs.

The top of the ipchecker script in /root looks like this:

#!/bin/bash

# Insert the account filenames to be checked below
# Remember to increment the account[#] for new entries

account[0]=larry.iptables
account[1]=curly.iptables
account[2]=moe.iptables

# ipchecker (c) Copyright 2012, Ward Mundy & Associates LLC.

You'll need to edit the script (nano -w /root/ipchecker) and modify the section in bold to reflect the actual FQDN account names you've created on your server that are associated with dynamic IP addresses only. You don't want to monitor accounts with static IP addresses or FQDNs that never get updated. When those extensions are off-line, it's not because their IP address changed, and restarting IPtables won't really help to improve the situation. Be sure to increment the account[n] array for each new account that you want to monitor and use the exact format shown in the example above. Before you enter an account in the script, display the contents of the file using cat /root/accountname.iptables. Make certain that the file includes BOTH an FQDN, then a space, and then an IP address. If not, delete the account (del-acct) and add it again using add-fqdn.

Once you've entered all of your accounts with dynamic IP addresses, save the script: Ctl-X, Y, then Enter. Run the script manually now to be sure it works as you intended: /root/ipchecker. Be advised that typos that list accounts that don't exist will cause problems. Error checking consumes processing cycles by requiring additional queries so we've left it out. That means it's solely up to you to check your account names for accuracy. And, remember, only include accounts that have dynamic IP addresses with FQDNs.

Step #6: Automating FQDN Refreshes with Cron. Finally, you'll need to add an entry to the bottom of /etc/crontab using nano. If you wanted the script to run 24 hours a day at 10 minute intervals, here's the command:

*/10 * * * * root /root/ipchecker > /dev/null

If you wanted the script to only run between the hours of 8 a.m. and 9 p.m. (server time zone) at 10 minute intervals, then you'd use something like this:

*/10 8-21 * * * root /root/ipchecker > /dev/null

On our RentPBX complimentary account which we use while traveling, we actually set the interval to 3 minutes. Since the DNS lookups use dig, changes on Android phones using the DynDNS client are almost instantaneous even with automatic switching between WiFi and cellular service. Finally, be sure to type date on your server and verify which time zone your cloud server thinks it's in! Adjust the times in /etc/crontab accordingly.

Be sure to check back here periodically for updates and follow the latest happenings about Travelin' Man 3 in this thread on the PIAF Forums. Enjoy!

Originally published: Thursday, March 29, 2012

March 30 Update: We've released a 1.1 version based on some excellent recommendations from those that already have tried Travelin' Man 3. This new version lets you choose from 9 different web services to activate for each new user. Read all about it including how to update if you installed the original version yesterday. New downloads will get the updated 1.1 release.

December 3, 2012 Update: We've been alerted to a pretty serious security issue with the methodology that CentOS uses to start and restart iptables. In a nutshell, if you have an FQDN in your iptables file or in your Travelin' Man 3 FQDN rules that cannot be resolved to an IP address, iptables will not load properly when your system is booted. This basically would leave your server with no iptables firewall protection. The matter has been reported to the iptables Dev Team, and we are awaiting a response. In the meantime, you should regularly monitor your server to make certain that iptables is functioning properly. iptables -nL will tell you which rules are active. If you don't see any of your VoIP-specific rules, then restart IPtables: service iptables restart. Watch the display for the location of the offending rule. Then edit /etc/sysconfig/iptables and either fix or remove the rule and restart IPtables again. Once iptables is actually working, you can avoid the problem with a failed FQDN by using the following command instead of service iptables restart: iptables-restore /etc/sysconfig/iptables. Unfortunately, this will not catch or fix an issue which occurs during the boot process. You also should edit line 64 of /root/ipchecker and replace the service iptables restart command with: iptables-restore /etc/sysconfig/iptables. New downloads already have the patch.

UNLESS YOU DISCONTINUE USING FQDN'S WITH IPTABLES, IT IS ABSOLUTELY ESSENTIAL THAT YOU MONITOR YOUR SERVER DAILY IF YOU ARE RELYING EXCLUSIVELY UPON IPTABLES AS YOUR FIREWALL PROTECTION MECHANISM AND YOU ARE USING FQDN'S AS PART OF YOUR CENTOS SECURITY METHODOLOGY!




Need help with Asterisk? Visit the NEW PBX in a Flash Forum.


whos.amung.us If you're wondering what your fellow man is reading on Nerd Vittles these days, wonder no more. Visit our new whos.amung.us statistical web site and check out what's happening. It's a terrific resource both for us and for you.


 
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. You now can get an almost half-price DID from our special Vitelity sign-up link. If you're seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road while you get an incredible signup deal as well. The going rate for Vitelity's DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For PBX in a Flash users, here's a deal you can't (and shouldn't) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this link to order your DIDs, or you won't get the special pricing! Vitelity's rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage and any balance is fully refundable if you decide to discontinue service with Vitelity.
 


Some Recent Nerd Vittles Articles of Interest...

Ringbinder theme by Themocracy