Tech

The Junction Networks lab is pleased to announce that we have reviewed the Stromberg Carlson Candlestick and have added it to our list of certified phones. Our configuration guide can be found here.

All around, this phone is pleasurable to use and has a competitive price to other mid-range phones. It has a very authentic ringtone that makes it ideal for VIPs. Unfortunately, the phone is not able to store speed dials or integrate with contact lists as other SIP phones can do, but the retro clicking dialing experience makes manually dialing the number a small sacrifice. Additionally, the rotary dial does not have letters printed on it, which may be a small setback for some.

The major problem with the Stromberg Carlson Candlestick is that it cannot pass DTMF tones, which provides some difficulty for dialing conference bridges and auto-attendants. All other features that we would expect of a fully-fledged enterprise phone operate appropriately. We worked around the DTMF issue by a liberal use of the transfer functionality. There are also currently no published future plans for the Candlestick to support high definition telephony.

Sound quality of the Candlestick is surprisingly good if the user follows the phone's usage guidelines and surpasses the quality of some other SIP phones that we've reviewed. For proper usage, the user should maintain a 3" distance from the transmitter (the "stick") and rest the elbow of the arm holding up the earpiece on a desk to resist fatigue. Deviation from the 3" distance can result in the user sounding faint to the other party, but the quality is still better than a call on the cellular network.

It is difficult to imagine a more durable phone than those produced by Stromberg Carlson. The craftsmanship far surpasses any other phone or PBX that we've seen in our labs. The etching of the company name on the back of the transmitter shows a real dedication to quality by the manufacturer that was readily apparent. Our inner geek also appreciates Stromberg Carlson's insistence on using bakelite, the world's first synthetic plastic.

Stromberg Carlson really ups the voice hardware game and provides a true challenge to other manufacturers. We look forward to seeing what results from this competition.

Insecure Extension Passwords on Asterisk (VoIP PBXs)

Junction Networks has become aware of four separate hack attempts against our PSTN Gateway customers over the last few days. Three of these customers were Asterisk customers and one was another SIP-based VoIP PBX. After communicating with our customers, it appears that the hack has nothing to do with any sort of Asterisk vulnerability, but with insecure passwords set for extensions. This blog post captures the issue well. Blocking the offending IP addresses at the router level does not help as they will just continue the attack from another address.

The best solution is to create secure passwords for your extensions. The passwords that come with sip.conf must not be used:

;[polycom]
;type=friend             ; Friends place calls and receive calls
;context=from-sip        ; Context for incoming calls from this user
;secret=blahpoly
;host=dynamic            ; This peer register with us
;dtmfmode=rfc2833        ; Choices are inband, rfc2833, or info
;username=polly          ; Username to use in INVITE until peer registers
                         ; Normally you do NOT need to set this parameter
;disallow=all
;allow=ulaw              ; dtmfmode=inband only works with ulaw or alaw!
;progressinband=no       ; Polycom phones don't work properly with "never"

Instead of secret=blahpoly, we would recommend that the password be at least 12 characters. Here are some good sites for password generation:

PC Tools

GRC

Cut and paste the secure password into sip.conf and into the phone. Use a different password for each extension.

Additionally, we would recommend the above strong random passwords in conjunction with limiting the IP addresses extensions can connect from to particular networks. There is some documentation on how to do this in your sip.conf here: http://www.voip-info.org/wiki/view/Asterisk+sip+permit-deny-mask

If all of your phones are on the LAN, and your LAN is 192.168.0.0/24 the input would be:

;Deny every address except for the LAN.
deny=0.0.0.0/0.0.0.0
permit=192.168.0.0/255.255.255.0

From the asterisk-security mailing list, Olle Johansson, the maintainer of the Asterisk SIP module had this to say...

[asterisk-security] Person Trying to Register on my Asterisk multiple times
Johansson Olle E oej at edvina.net 
Fri Jan 23 15:51:46 CST 2009

...

Attacks are never fun. Use the ACL (permit/deny) in sip.conf to block this IP or range of IPs at least. 

Or use IPtables. There are a lot of IPtables scripts to prevent this kind of attacks if you look at the solutions for the very common SSH attacks that keep testing multiple usernames. Maybe someone on the list has a version for SIP attempts over TCP and/or UDP?

It's always good to have a bit less obvious peer names than the ones they test. Don't use usernames or extension numbers. Make sure you separate the namespaces. Kevin usually suggest Ethernet MAC addresses, which are harder to guess, but still relates to something even though they do have a well-known pattern.

Finally, it's important to make sure you have good passwords. There's no reason to have simple passwords in something you only install in software in devices or applications. There's no user who has to learn to remember the MD5 auth secrets.

That's my 10 cents. Please, list, fill in and correct me when wrong!
/O

Okay, not really, but Tina Gasperson is claiming at LinuxPlanet (with her tongue firmly in cheek) that Open Source software saves the lives of cows, since it can be developed at home. You see, you'll buy fewer shoes.

But is open source really greener? Gasperson makes her most serious argument in that open source tends to be developed to require less in hardware resources, while proprietary software frequently isn't. Some Linux distributions, like Knoppix, can be stored and run off a USB key fob. That is pretty cool, but I don't really hear a lot of people rushing to the store for computers without hard drives as a result. So, is it really greener?

One of the big problems I have with "greenness" is that it's such a vague concept, without a lot of concrete metrics. To be "green", a product just has to be more ecologically friendly than something else, but that doesn't have a lot of concrete definition. For software, some metrics should be power consumption, packaging (online downloads don't require any!) and documentation distribution, which open source does traditionally do better with than proprietary software.

And, like Gasperson suggests, open source does require fewer showers.

Yesterday, Wired carried a report of several prominent Twitter accounts getting hacked. The first problem with Twitter's security is that they weren't throttling invalid password attempts on their accounts, so it was just a matter of time and poor passwords before a malicious party got in. Unfortunately for Twitter, the hacked account was a staffer with the ability to change the password on every user account. Barack Obama, Britney Spears and Fox News were compromised, along with quite a few others. It was a classic and simple hack.

The second problem Twitter had is the same problem that every network administrator deals with -- the users. It is so important for all users of a system, but particularly those with administrative access, to follow good password procedures. Here are some good guidelines to remember:

• The longer your password is, the more computation is required in cracking it. Passwords should be at least 8 characters.
• Passwords should use a mix of characters - numbers, upper and lower case letters and special characters if the system allows for it. L33tsp3@k 1s v3ry us3ful h3r3.
• Passwords should not be dictionary words and certainly should not be named after a person or a pet, even if you tack on some numbers at the end. "Fluffy12" is not nearly as good of a password as "il1k3d0gs!".
• Passwords should not be shared, unless completely unavoidable. If several people at a company are sharing a password for a company account, it should be changed immediately if one of those people leaves the company.
• Passwords should be changed on a regular basis, but not so frequently that the user has to write down the changed password on post-it notes to remember it. Naturally, written down passwords should be avoided - if a user has too many passwords to remember, invest in encrypted password storage software. It's worth it.

For those of you that are administering Junction Networks accounts, this security is really important. Can you imagine the damage that a malicious user could do to your company if your account was compromised? Our interface gives the ability to route your company's phone numbers, set up your auto-attendant and manage users - so a malevolent user could easily delete all of those things (or worse, reroute them to something really inappropriate).

Without security, any system becomes unusable. We cannot stress it enough. To change your administrative user password with Junction Networks, log into OnSIP, then click on "Account" and click "Change admin password".

I was over on Freeswitch's website this morning and noticed a link to a list of 104 Cisco and Avaya alternatives for IP PBXes. I thought it was an interesting list. Even though it does not seek to evaluate the IP PBXes, it is pretty astounding to note just how many options are out there. The Asterisk team should be particularly proud, given how many names on the list are Asterisk derivatives.

Although there were zero doubts in this corner, the sheer number of choices out there is a testament to the importance of VoIP for the future of communication.

Here's a little trick to help make things easier as we find the holiday season upon us. Will your office be closed over the holidays? Would you like to keep your customers in the loop of your holiday schedule? Would you like calls to automatically roll over to voicemail when no one is scheduled to be in the office? You can do all of that with Junction Network's OnSIP Hosted PBX by using business hour rules and announcements.

To keep your customers in the loop on your holiday hours:

1. Create a new recording under 'Resources' or by dialing *94 from any OnSIP phone. Record your holiday hours message as a recording.

2. Create a new 'Announcement' under the 'Apps' tab. Name it something easy to remember like 'holiday'

3. Re-record your attendant menu greeting to say something like "Press 4 to hear our holiday hours"

4. Edit your attendant menu so that 'on the press of 4' the caller now hears your new Announcement created above.

To roll calls over to voicemail when no one will be in the office:

1.) Create a business hour rules for the week of 12/25 and 12/31. Business hour rules are free.

2.) Set it up so that when users will not be in the office, Tuesday and Wednesday for example, you set the business as 'closed'.

3.) Put them in place on Monday (or any time that week before the holiday) and let them run for the week.

You can create as many Business Hour rules as you need and apply them at any time, but it's a manual process. Business hour rules are day-of-week and hour-of-day based. Be sure to return to normal operation (normal recordings and normal business hour rules)upon your return.

SIP via UDP vs. TCP

One of the things I enjoy doing is taking complex subjects and explaining them in such a way that nearly any interested party can understand. I spent nearly an hour last night explaining the Big Bang theory to my 12 year-old son. I think, eventually, we got there. The task before me today is to explain why SIP, the protocol of VoIP, is best left as a UDP service as opposed to a TCP service. This is nearly as formidable as explaining the Big Bang to a sixth grader.

First, we need to build some vocabulary. TCP and UDP are connection protocols in use today for data traversing the Internet. Data travels across the Internet in packets. Think of them like letters. Like letters, they have an envelope with a to/from address on them. TCP and UDP are just two types of envelopes. The IP addresses are the to/from addresses. They both carry data and both use IP addresses, but just the outside envelope is different. Think US mail vs. FedEx. The address on the envelope is the IP address for where the packet came from (source address) and where it's going (destination address). TCP is so prevalent on the Internet that it's typically combined with IP, and written as TCP/IP.

TCP would be the 'FedEX' part of the analogy from above. Whenever two servers 'speak' TCP, they set up a formal connection. Every time a packet is sent from one side, the other side sends a packet back acknowledging the packet's arrival. If no acknowledgment packet arrives after a certain amount of time, or if the acknowledgment states that there was a problem, then the packet is re-sent. It can sometimes take a few seconds for a packet to be fully successfully transmitted. TCP is optimized for accurate delivery, not timeliness, and is the protocol for WWW sites and e-mail among others.

UDP is the opposite. It is a protocol optimized for getting packets there in a timely fashion with little overhead, but with just as little accountability. It's more like throwing a bottle in the ocean. Ok, a very rapidly moving ocean, but you get the point. With UDP, you just address the envelope and drop it on the network. There's no handshake, and no setup. Just the data packets. UDP is meant for real-time conversations where you are more interested in keeping the stream going then making sure that you have every single packet.

Right this very moment, Junction Networks has over 3,500 devices attempting to connect with Junction Networks. These devices are everything from individual SIP phones, to SIP devices, to other PBXs. Most of the connection attempts are simple SIP registrations. A SIP registration is when a SIP device tells the server, in this case Junction Networks, that it's available for calls and what its IP address is. This communication happens anywhere from every minute to every hour, for EVERY device. That's a LOT of packets. If these were TCP packets, each time a phone wanted to tell us that it's available, it would have to go through the whole TCP connection setup. That would be a HUGE amount of overhead for a VoIP carrier. In a LAN environment, it would be manageable, but for thousands of individual devices and hundreds of them attempting to register EVERY SECOND, a TCP connection would grind servers to a halt.

Next, once the phones are registered and a call is set up, it's really UDP's time to shine. A phone conversation is a stream of packets meant to be created, sent and received in real time. A lag, any lag, would mean a degradation in the quality of the phone call. Imagine hearing something on the call one to two seconds after the person on the other end says it. You're replying to what they're saying, but they've already moved on. It would be totally disconcerting. And, since it's real-time, there's no catching up. Better to drop a packet and have a millisecond of silence than seconds of lag.

In short, VoIP traffic is best left as UDP traffic for both server load and call quality reasons.

This post gives me the background I need to answer why BitTorrent will NOT bring down the Internet and VoIP if/when they switch to UDP, contrary to
this article. Taking on explaining BitTorrent is going to be much harder than the Big Bang.

There is a great post over at Bradley Holt's blog about using Google Talk's XMPP service in conjunction with SIP from Junction Network's OnSIP Hosted PBX.

Here is my take on XMPP and SIP. XMPP is an XML-based open standard with, among other things, built-in protocols for subscribe and publish, e.g. subscribe to someone's presence information and publish your own presence. SIP, another open standard, is good for a bunch of rapid-fire, short messages back and forth. It's kind of like DNS on steroids. SIP is currently (and for the foreseeable future) the de facto standard for VOIP.

Internally we have been running an XMPP server for presence and instant messaging for a few months now at our domain: junctionnetworks.com. Additionally, using open XMPP servers like Google Talk, I can see the presence of my XMPP 'buddies' at other domains as well. If you are connected to an XMPP server, you can chat with me at mike-at-junctionnetworks.com. That address is my e-mail, SIP and XMPP address. That's what I call real unified communications. We are making these XMPP services available to all of our customers at either their current onsip.com domain or even (eventually) at their own domain. (This is something we offer today for SIP calling.)

XMPP and SIP are two great tastes that taste great together. We have written an SIP to XMPP gateway which allows us to gateway SIP information to an XMPP server. Once you have that, you can then receive instant messages and screen pops on inbound calls. Our current project is to wrap all of this up in an easy to use web-based interface for the end user. One interface will handle your presence, chats and phone calls. We'll be writing more about that in the coming weeks. The point is that we are excited to see our customers looking to use the same technology and standards that we are building toward. As always, we will keep with our corporate themes of no walled gardens, open source and open standards.

This morning I saw this excellent blog post by Garrett Smith which points out a few tips on making the transition to VoIP easier for SMB.

His main point is bandwidth, bandwidth, bandwidth. Although it seems obvious, adequate bandwidth is an absolute requirement for VoIP. VoIP is very sensitive to packet loss and latency, which results in quality of service issues (i.e., echo, dropped calls, etc.). Do all of your employees stream music while checking their e-mail and utilizing web applications? That's going to affect the quality of your phone calls if you don't have the bandwidth to be able to handle it.

Fortunately, in modern computing, bandwidth is one of the cheaper things that you can buy, so resolving this problem is potentially pretty easy. (Who remembers paying $1,500+/month for a 1.5 MB T1 a few years back? Good riddance to that!) But Smith's advice of doing a network analysis before buying into VoIP is super important - and easy to forget when you're excited about saving money and integrating your phone into your business life in a way that only IP telephony can do.

But it's not just the Internet bandwidth that matters - the speed of your LAN also counts. If you're using significantly older equipment, you may not have the throughput locally to handle additional traffic. If you have any equipment that is still 10baseT (and we've seen this), you probably already have speed issues with your existing data connections. Adding VoIP will be a disaster.

But there's good news here too - if you've built or upgraded your network in the last 5-8 years, it's pretty unlikely that that you're going to run into that problem. If you've signed your contract with your ISP within the last 5 years or so, you probably also have adequate bandwidth. But it certainly never hurts to get some numbers into your hand before you make the leap and add your telephony traffic to your data connection.

VoIP is excellent in many regards - but like any technology, it must be implemented correctly.

When we heard about an Open Source router at Junction Networks, we were naturally very intrigued. We love the Open Source movement and have invested heavily in it, so being able to recommend an open source router would have made us very happy.

Alas, we cannot. At least not an out-of-the-box Netgear WRG614L, which is the router touted on myopenrouter.com. We have a historic problem with Netgear routers in that they implement an ALG for SIP that cannot be turned off. (What's an ALG? Read about it here.) Unfortunately, out of the box, the WRG614L continues to have this problem, so it will not work successfully with the OnSIP Hosted PBX. We chose to test the Netgear of all the open source routers because we'd hope this had been fixed.

However, being open source, it's entirely possible for someone to change the WRG614L so that the SIP ALG can be turned off. Have you done it? We'd love to hear about it.