Category: Linksys

Link: List Of Tools To Monitor The Health Of Your Linux System

Achieving good performance from a computer or network is an important part of system administration.The monitoring and maintenance of the system is the most important task listed in the checklists for daily tasks of a system and network administrator. There are many commands line utilities created for this purpose.

This article describes how you can monitor services and attributes of Linux/UNIX servers using command line, such as:

  • CPU load
  • Bandwidth
  • Memory usage
  • Disk usage
  • Logged in users
  • Running processes
  • etc.

Let’s start.

Full article here:
List Of Tools To Monitor The Health Of Your Linux System (Unixmen)

Link: 6 quick tools to monitor system resources on Linux

System administrators need to monitor their server to ensure proper functioning. The practice enables administrators to detect possible issues in advance and recover the system, before it causes any trouble.

There are plenty of commands on Linux to monitor different system resources like cpu usage, memory usage, network, disk usage and so on. Popular ones are top, htop, iostat, nethogs etc.

In this post we are talking about simple command line tools that can monitor multiple system resources like cpu, memory, network, disk, processes etc all together in a real-time and interactive manner. These tools present a whole lot of statistical information on a single screen that is constantly updated.

Full article here:
6 quick tools to monitor system resources on Linux (BinaryTides)

Unbricking a Router With a Raspberry Pi using JTAG (links)

This is a tale of how someone remembered that he had a non-functional router, in this case an older Linksys WRT54G, and…

… decided he would have a go at repairing this ancient router. There was only one problem: the most popular utility for programming the router through the JTAG header required a PC parallel port.

Unfortunately, parallel ports are becoming as hard to find as floppy disk drives these days, but did that deter him? No way, he simply added Raspberry Pi support to the debricking utility, and used the Raspberry Pi’s GPIO pins to do the job.  Unfortunately, in the end he was unsuccessful, but only because he physically damaged the circuity on the router while attempting to upgrade the RAM – had he not attempted the hardware modification, this likely would have worked.  So, although we make no guarantees, if you have a bricked router, read the articles linked below and maybe you can bring it back to life.

Unbricking a Router With a Raspi (Hack A Day)
Debrick WRT54GL using Raspberry Pi (JTAG bit banging) (Oxblog)

Link: Interesting security technique for Asterisk and FreePBX users (may work with other SIP-based PBX’s also)

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in November, 2010.

NOTE: For some reason WordPress absolutely hates it when I try to edit this post, and turns links and other things into piles of steaming poo.  If things don’t look right here please e-mail me or leave a comment and I’ll check it out.  WordPress, I KNOW how I want my articles to look, why can’t you just leave them alone?

One problem faced by some SIP-based VoIP PBX administrators is the issue of security when you have external extensions (that is, extensions located anywhere in the world that’s not a part of your local network). You want to allow those extensions (the ones you’ve authorized) to connect to your system, but you prefer to keep everyone else out, and preferably not even tip them off that there’s a PBX there. The idea is, if the bad guys that would like to break into PBX’s don’t even realize that there is a PBX at your IP address, they won’t waste any time trying to crack into your system.

There have been other suggestions for how to handle this but many of them require your users to take some additional action(s) that they would not normally have to take, and users hate having to lift a finger to do anything to enhance their security. Which brings us to a rather clever technique that doesn’t require user to do anything other than use their phones as they normally would. It might be a tiny bit of a pain to set up initially, but the results may be worth it. I would call this medium level security because if someone is sniffing your packets, this alone may not keep them out, but most of the lowlifes that try to break into PBX’s don’t actually have sufficient access to sniff your packet stream (and also, they’d have to know the exact technique you’re using to be able to crack this). So without further ado…

Secure your VoIP server with the SunshineNetworks knock

(As of October 24, 2012, the above link appears to be DEAD — see the edit at the end of this article)

Note that while the article recommends changing the SIP port to something other than 5060, their basic technique (the “knock”) should still work even if you feel you need to stay on 5060. My only fear about changing the SIP port would be the possibility of losing communications with VoIP providers and with other systems I legitimately send/receive voice traffic to/from. They’re probably going to keep using 5060 even if I don’t. EDIT: My concern here may be unfounded — note the comment below from Alex of Sunshine Networks, who said that “changing the SIP port is quite safe. Your SIP server will send this SIP port along in it’s first SIP invite registration to the VoIP provider. So unless your VoIP provider is actively blocking out anything else than port 5060, it should work fine. We use this technique with 3 different major SIP providers in Australia and never had problems. So far we haven’t seen any unintended consequences.”

I haven’t personally tested this, so if you do, please consider leaving a comment to let me know how it worked for you. The two things I wonder are, do these rules survive a reboot, and can you have more than one secret phrase that would let people in (in case you want to use a different one for each external extension)? EDIT: Those questions are also addressed in Alex’s comment below. Also, those of you running PBX in a Flash should take note of Ward Mundy’s comment about changing an entry in /etc/sysconfig/iptables in this thread. In that same thread, there appears a method to view the “knock” each extension is currently sending — just do “sip debug” from the Asterisk CLI for an hour or so (long enough for all your endpoints to register, after which you can use “sip no debug” to turn it off), then run this at the Linux command prompt (not from the CLI!):

grep "From: " /var/log/asterisk/full|cut -f1 --delimiter=; | sort -u

For each of your remote extensions, you’ll see a line that looks something like this:

From: The Knock <sip:234@nn.nn.nn.nn>

“The Knock” may or may not be enclosed in quotation marks, but it apparently doesn’t matter (you don’t include them in the iptables rules). If you haven’t used a specific “knock”, it could be the actual user’s name, if you set that up when you first set up the endpoint. Anyway, I’d suggest running this BEFORE you actually implement the iptables rules, so you know ahead of time what each endpoint is sending.

EDIT (Added January 8, 2012): I am now using a slight variation on this technique on one of the systems I administer. Without going into too many specifics, I will just note that some SIP devices and VoIP adapters actually already send a unique string that you can use as a “knock” – you do not have to configure a new one, you just need to find out what the device is already sending and use that. For example, let’s say you have an VoIP device connecting to your Asterisk server as extension 234. All you have to do is go to the Asterisk CLI (NOT the Linux command prompt) and enter this:

sip set debug peer 234

(Replace 234 with the actual extension number). Now, assuming that the device is connecting to your server, you will start to see SIP packets scroll across your screen. Within a few minutes you should see one like this (IP addresses have been xx’ed out):

<--- SIP read from UDP:xx.xx.xx.xx:5061 --->

REGISTER sip:xx.xx.xx.xx:5060 SIP/2.0
Call-ID: e10700c2@xx.xx.xx.xx
Content-Length: 0
CSeq: 56790 REGISTER
From: <sip:234@xx.xx.xx.xx>;tag=SP8f427e45f1e19cb24
Max-Forwards: 70
To: <sip:234@xx.xx.xx.xx>
Via: SIP/2.0/UDP xx.xx.xx.xx:5061;branch=z4b9hGK-4f0473a8;rport
Authorization: DIGEST algorithm=MD5,nonce=”37cd169d”,realm=”asterisk”,response=”a726bfed5db321a7bc967b997b5157c2″,uri=”sip:xx.xx.xx.xx:5060″,username=”234″
User-Agent: xxxxxx/xxxxxx-x.x.x.x
Contact: <sip:234@xx.xx.xx.xx:5061>;expires=60;+sip.instance=”<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces

<————->

If you don’t see this you may need to increase the debug level. After you see a packet like this, you can turn off sip debugging:

sip set debug off

The string you are looking for is in the Contact: string above (the nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn is replaced by a unique string). So, where in the instructions for the “knock” they show a sample string such as:

iptables -I door 1 -p udp --dport 5060 -m string --string "mysecretpass" --algo bm -m recent --set --name portisnowopen

I would change the --dport parameter to 5060:5061 (since an VoIP adapter sometimes uses port 5061 for the second service provider — for an device that allows up to fours service providers, use 5060:5063) and the --string parameter to “<urn:uuid:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn>”, but using the actual string sent by the device, of course. I know the Sunshine Network people recommend using something other than port 5060 but I just can’t bring myself to go quite that far, and even their examples show 5060.

Some other SIP-compliant devices also send unique strings in their REGISTER packets. One that does NOT do so, as far as I am aware, is the venerable Linksys PAP2. And I also do not believe that any of the Sipura line of devices send such a unique string.

Naturally, if an intruder KNOWS you are using that technique, they could try a brute-force attack on the unique string. So I recommend only using this with “uncommon” extension numbers (not 200 or 1000, for example) and with a VERY strong secret/password on the SIP connection. But it is another line of defense against would-be intruders!

EDIT (Added October 24, 2012): The original article, and most of the original site for that matter, seems to have gone offline. While I’m not going to repost the original article here without permission, I will give you a few more details and a couple of excerpts. First, they advised that you change the SIP port to something other than 5060 – they suggested using something in the range 20001 through 49000, though I am not sure why. They uses port 34122 in their examples, and noted that if you are running PBX software that has a “SIP Settings” module, if your find a setting for “Bind Port”, that would be the one to change. Of course if you do this, you then have to change the SIP port on ALL your SIP-based phones and VoIP adapters.

With regard to the “knock” itself, they said this:

Technical information :
… Technically, our knock consists of a secret passphrase which is sent together with the first SIP packet from the phone to the server. SIP packets are text files, very much readable like http packets are. The SIP headers in a REGISTER invite packet have a lot of information, and one of those headers is called the “Display Name”. This display name is used only internally in your Asterisk server and has no other use, so we figured we could fill in anything and the Asterisk functionality would still work fine. We decided to use it as a port knock password.

How does it work :
The Asterisk administrator sets up a simple iptables rule. The iptables rule checks for a secret phrase inside packets sent to the SIP port ( 5060 by default, 34122 after having changed it ). Unless it finds this secret phrase, it will drop the packets to this port. All the remote phone has to do is fill in the “User Name” SIP property on his SIP phone with the secret phrase, and he will be able to connect.

What you then needed to do was to go to into your Asterisk server and from a Linux command prompt, issue the following command:

iptables -N door

Then for EACH “knock” string you want to use, you would do this from the command prompt (note this is only one line, and note that 34122 is the example port and “mykn0ckstr1ng” is an example “knock”):

iptables -I door 1 -p udp –dport 34122 -m string –string “mykn0ckstr1ng” –algo bm -m recent –set –name portisnowopen

If you have anyone that needs to register with your server but cannot send the “knock”, but is at a fixed IP address, you’d add a line like this for each instance (again the port and ip address would probably need to be changed, and note that an entire subnet can be specified as in this example — just leave off the /24 if it’s a single ip address):

iptables -A INPUT -p udp –dport 34122 –source 10.10.1.0/24 -j ACCEPT

Then you would enter these three lines, but again using the correct port rather than 34122. In the first line you see the number 4000 — that is amount of time in seconds that the port will be open, and should be greater than 3600 because that’s the default registration timeout for many sip phones and VoIP adapters. The original article notes that you could use 86400, which is a full day:

iptables -A INPUT -p udp –dport 34122 -m recent –rcheck –seconds 4000 –name portisnowopen -j ACCEPT
iptables -A INPUT -p udp –dport 34122 -j door
iptables -A INPUT -p udp –dport 34122 -j DROP

And finally, to make iptables use these rules, you’d enter:

service iptables save

The original Sunshine Networks article notes that…

This code keeps port 34122 closed ( DROP ) unless someone has opened the door ( door ) in which case they are allowed to pass the door for a little more than 1 hour ( 4000 seconds ). Each time the phone re-registers , the SIP secret pass header is sent, and the door is reopened for 4000 seconds. Since the default SIP reregistration time on many phones is 3600, the 4000 seconds will make sure that as long as the phone is connected to the SIP server, or needs to be connected, the dynamic firewall rule is always active.

Once you have done this, if you configure the Display Name or User Name setting with the “knock” string, it should be able to get through your firewall. Any phone that doesn’t have this string won’t. Of course you can always make the “knock” something that a phone already sends (in a SIP register packet), as noted in the previous edit, and then you don’t have to reconfigure the phone at all. If a phone or device tries to connect without sending the “knock”, the firewall won’t allow it (assuming you haven’t previously created some other rule that allows the traffic to pass) and the connection will fail, or at least that is how it’s supposed to work (I make no guarantees because I didn’t come up with this).

If you enter the command cat /proc/net/ipt_recent/portisnowopen you will get a list of IP addresses that have successfully used the “knock” to connect. Remember that after you implement this, it can take up to an hour for a device to attempt to reconnect.

If anyone ever spots the original article back online, please let me know and I’ll remove this edit. I’d rather you get the information direct from the original source anyway, and the short excerpts I have provided here don’t give the complete overview that the original article provided.

EDIT (February 23, 2014): It appears that there is an archived copy of that original article on the Wayback Machine, although we do not know if it is the most recent edit of that article prior to the site disappearing.

Mini-review of Sangoma U100 USBfxo device

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

This article was originally posted in June, 2010.

I recently had the experience of trying to help someone make a Sangoma USBfxo device (model U100) work on a server that runs FreePBX and Asterisk. The advertised features of this device are as follows:

  • Dual FXO ports
  • Easy installation, no need to open up computer to install PCI/PCIe card
  • Supports up to 2 simultaneous calls
  • Compact plastic enclosure
  • Low power consumption, takes power from USB bus
  • USB 2.0 compliant (compatible with USB 1.1)

The first thing I would note is that although you don’t have to open up the computer, it’s definitely not “plug and play.” At the very least you have to install driver software, and on an Asterisk server you will also need to install and configure DADHI or ZAPTEL (unless this has already been done). Depending on your level of expertise, this might be easy, or quite daunting. I would certainly take issue with the claim of “easy installation” although I can understand how a true Linux geek might consider it a walk in the park. It wasn’t so much that there were any major hitches in the installation as that it was time consuming and required quite a bit of mental effort to figure out what needed to be done — someone who has just set up a PBX using a “load and go” distribution like Elastix, PBX in a Flash, AsteriskNOW, Trixbox, etc. might not find it all that easy to get this thing working.

The major issue we had was with the performance. We initially discovered that it was “clipping” speech severely, causing audio artifacts that are difficult to describe in print, but unpleasant to hear. We got in touch with Sangoma customer support and finally traced the problem to the built in hardware echo cancellation. By disabling the hardware echo cancellation, the speech was clear, but of course we then had mild echo. Enabling echo cancellation in Zaptel fixed that on a temporary basis, but about a week later Sangoma customer support e-mailed us and suggested that we try OSLEC, the open source echo canceler. We might have actually done that had we not discovered another issue in the meantime, that made us decide we didn’t want to mess with this unit anymore.

This new issue was that initially, it did not pick up incoming caller ID on incoming calls. We discovered that this could be fixed by changing the gain settings in Zaptel, but even when we did that it still wasn’t 100% reliable (I’d say it worked about 90% of the time). And, the downside of that was that we had to reduce the incoming gain, so that it was harder to hear callers.

We’ve used Sipura SPA-3000’s before for this same function, although they are only single line units (they have one FXS port and one FXO port) and have never had any of these issues. The main reason we tried the USBfxo was because we wanted two FXO ports, and also liked the idea that it was powered off the USB cable, and didn’t require us to have yet another device with a “wall wart” to plug in. But the difficulties with Caller ID, volume levels, and the fact that Sangoma had apparently given up on getting the hardware echo cancellation to work without distorting the audio led us to get frustrated with this device fairly quickly. The non-techies that had to make and receive calls that went through this device were not very understanding of the issues, especially since the SPA-3000’s (now superseded by the Linksys SPA-3102, which is essentially an updated version of the Sipura SPA-3000) had always worked much more reliably. We finally gave in and found another Sipura SPA-3000 on eBay and put it into service, and within a relatively short time (part of which was spent locating and installing updated firmware) it was working like a champ. Unlike the Sangoma, it detects the Caller ID 100% of the time, and we can tweak the transmit and receive gain to comfortable levels.

My personal opinion is that Sangoma should be ashamed to put their name on the USBfxo.  The hardware echo cancellation, in a word, sucks.  And one of the big reasons you’d buy a brand like Sangoma in the first place is because of the supposedly superior echo cancellation.  Echo cancellation is supposed to cancel echo, not make it sound like your words are clipped.  My guess is that the hardware echo cancellation is far too aggressive and they don’t give you any way to “tune” it — you can either enable or disable it, but that’s all.  The USBfxo is a great idea, but it needs to go back to the drawing board. Sangoma’s motto (shown on their Wiki pages, etc.) is “Because it must work!”, but apparently that motto does not imply that it must work well!

Also, a note to Sangoma customer service — next time a customer is dropping hints that they’d like you to take your defective unit back and send a replacement, you might want to be a bit more responsive to that request. We were willing to work with you up to a point but the message came through loud and clear that you really didn’t want to replace this dog of a device unless you absolutely had to.  We didn’t sign up to be beta testers, we just wanted the damn thing to work. Given Sangoma’s (perhaps undeserved) reputation we really thought you’d be more agreeable to making sure that we got a unit that worked, not making us try a bunch of different things and then ultimately told to try OSLEC, effectively giving up hope that the hardware echo cancellation would ever work properly.

Another suggestion to Sangoma (or any other manufacturer that may be listening) — most of us who did not cut our teeth on Linux would probably prefer not to have to mess with ZAPTEL or DADHI.  The nice thing about the Linksys/Sipura devices is that they sit out on the network and appear as just another SIP-based device, and in FreePBX you configure them pretty much as you would any other SIP trunk.  I’m not saying that installing any of these devices is the proverbial “piece of cake”, especially if you have never done it before, but when you have to start installing and configuring drivers, that goes outside of the realm of what I would consider easy to install. What someone really needs to come out with is an inexpensive four to six-port SIP based FXO device that sits out on your local network, like the SPA-3000/3102.

If you are in need of one or two FXO ports for your Asterisk server, my advice would be to first try one or two Sipura SPA-3000 or Linksys SPA-3102 devices (following these instructions if you are a FreePBX user) — if those do not work the way you’d like, you can always resell them on eBay and then try a more expensive solution.  If your server doesn’t have card slots (as is increasingly the case, as users turn to small computers like the Acer Aspire Revo to use as small, power-efficient PBX’s) then your choices are limited to external devices such as the aformentioned units. However, if your system can accept internal cards, then you can buy cards that provide FXO ports from several manufacturers, including Digium and Sangoma (if you need eight or more FXO ports than I believe there are other external options, but they are quite a bit more pricey and I have not really investigated them, so I won’t comment on them at this point.  However, if any manufacturer would care to send a review sample, I’d be more than happy to give it a try!). 😉

The one caveat I will add is that not every device will work on every line.  If you have a very long line from a traditional telephone company, your requirements (and experience with a particular device) may be quite different from someone who is sitting 500 feet from the central office, or someone who’s trying to take the output of a cable company’s VoIP adapter and pipe it over to the FXO card or device using twenty feet of copper wire. Just because the Sipura devices have worked better for us does not mean they will for you. I’m guessing that some people have purchased the exact same Sangoma device that we tried and were able to get it working well enough for their needs, but I just cannot recommend this device — at least not until Sangoma fixes the echo cancellation, and makes it read the incoming Caller ID reliably 100% of the time, preferably without having to change the incoming gain in DADHI or ZAPTEL.

EDIT: For more comments/opinions on this device (and on this review), see this thread on the PBX in a Flash forum.

BETA Perl script for Caller ID popups when using Linksys/Sipura devices

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Creative Commons License photo credit: bcostin

PLEASE NOTE: This  article has been updated as of December 30, 2008.  This now works with a Mac or Win32 computer (and Linux computers with libnotify installed or readily available, such as those running Ubuntu) and has been updated to reflect that fact. Also, please note that previous versions may have failed on devices/phones with more than two lines – this is (hopefully) fixed as of version 0.7.

If all of the following are true:

You have a Macintosh computer with OS X installed, or a PC with any 32-bit version of Windows installed (basically Windows ’98 through XP), or any version of Linux with libnotify installed

Growl icon
Image via Wikipedia

You have Growl (if you have a Mac) or Snarl (if you have a PC) notifications installed (EDIT: There is now a version of Growl for Windows but at the moment I only have an experimental version of the script for that – see bottom of this page for more information.  It MIGHT work with 32-bit OR 64-bit Windows 7 – feel free to test it).

You have a Linksys or Sipura VoIP adapter on your local subnet or home network and receive calls over it

You would like to see Growl, Snarl or libnotify popups on your computer when a call comes in, showing the caller’s name and number, along with the line that the call came in on and the time and date the call arrived (in case you are out when the call comes in)

You have previously run Perl scripts on your computer, OR are reasonably good at following instructions and problem-solving

AND you are willing to run a script that comes with NO WARRANTY whatsoever (if it breaks, you can keep all the pieces)

Then download this file (now at version 0.92), unzip it and read the Instructions.txt file in the folder appropriate to your computer.

This script is being offered under the GNU General Public License, so if you want to modify it to work on other platforms, you can do that under certain conditions (see the Instructions.txt file for details). Mainly, I’d hope that you’d contribute the modifications back (and please leave a comment on this article if you do that).

I don’t have any kind of regular web page up for this yet, for one thing it’s very rough (very little error-checking) and for another I’m very tired, having spent way too many late nights trying to get this to work. So this post will be more terse than most of my posts, but I think most everything you need to know is in Instructions.txt (and for Mac users, the “How to run at login.rtfd” file) inside the .zip file. Feel free to repost this information to other forums if you think anyone else might be interested.

For those Mac users that wish this were an app: I understand that there is an app called Platypus that allows Perl scripts (and any other types of scripts) to be converted to OS X app bundles. However, what it does not seem to include is any way to specify the command line options, or to load any missing Perl modules. So for now, this script will probably only be usable by those with sufficient knowledge to run a Perl script on their Mac. If I were a bit more knowledgeable, I’d build a preference pane to go in System Preferences, and then have the script read that for its configuration options. But I still have no idea how to make an app install missing Perl modules, particularly when OS X does not come with “make” installed until and unless the Developer Tools are installed (adding something like 3 GB of stuff that is mostly useless to non-developers to your hard drive!).

EDIT: I read somewhere that you can install make without installing the bloated Developer Tools package if you instead install Fink. Then, from a terminal prompt, you can type fink -b install make and supposedly that will do the trick. However, I am told that Fink has not been updated for Snow Leopard, but there is a make package in Rudix that should work with Snow Leopard (mind your paths – Rudix installs make in the /usr/local/bin directory and by default CPAN expects it in /usr/bin, so you may want to adjust the path during CPAN setup, or make a symbolic link in /usr/bin). Since I have not personally tried either of these I have not updated the instructions in the download to reflect this, but if it works you can skip the whole process involved in installing the Developer Tools.

Because this is a Perl script, it lends itself to custom modifications. For example, let’s suppose you have this script running on a Mac, and you are sending Growl notifications to the Mac, but you also have a home theater PC that runs XBMC and/or Boxee, and you’d like to send Caller ID notifications to it as well.  Assuming that Boxee and/or XBMC is configured to allow control via a Web interface, at a fixed IP address and port (192.168.0.150 port 8080 in this example), you could add a line such as this to the script (this is all one line; select and copy to get it all if it gets truncated on your display):

eval {get "http://192.168.0.150:8080/xbmcCmds/xbmcHttp?command=ExecBuiltIn&parameter=XBMC.Notification(Call%20from%20%22$displayname%22%2C$phonenum%20calling%20$lineid[$count]%2C15000%2C%2Fhome%2Fusername%2Fphone.png)"};

The above assumes that you have placed the icon file phone.png (shown at right — right click on the icon and save it) in the user home directory on the destination system (the one running XBMC or Boxee), and that you change ‘username’ to the actual name of the user’s home directory. Note that the icon path requires %2F in place of forward slashes (therefore %2Fhome%2Fusername%2Fphone.png really means /home/username/phone.png) Phone icon - right click and copy imageand this refers to the icon directory and filename — if you choose not to use an icon then leave that part out, along with the %2C that comes just before it.  If you are running XBMC or Boxee on the same system that’s running the script then you should be able to replace 192.168.0.150 with localhost or 127.0.0.1. The above line should be inserted just above the comment line “# Make output string in chosen format” near the end of the Perl script. Keep in mind that this won’t work if you don’t enable control via Web server in XBMC or Boxee, and make sure the port number matches the port in your added line.  Depending on the skin you use, this is generally accomplished by going to Settings, then Network (and in Boxee, then Servers). Then check “Allow control of XBMC via HTTP” (in XBMC) or enable the Web server (in Boxee) and verify the port number is correct.

Starting in Version 0.7 there is a minimal logging function, allowing all detected incoming calls (whether answered or not) to be saved to a text file and/or a comma-quote delimited file. I probably could support other simple formats, but don’t even think about asking for anything more complex (like a rather humorous friend of mine who asked for MySQL integration – considering that he knows how little knowledge I have about Perl programming, and that I have even less knowledge about databases, I’m sure he thought it extremely amusing to make that request). The one thing I really don’t like about offering these scripts in Perl is that it requires the user to know how to install modules from CPAN (or an alternative source if using Win32), but I barely know how to do this stuff in Perl and don’t know any other languages (well, except for QBASIC under MSDOS, but that’s even less compatible across platforms than Perl!).

Starting in Version 0.9 you can use a plain-text file of number-name substitutions, so (for example) if calls from a particular number always display a cryptic Caller ID name, you can change them to say “Uncle Bob” (or some other name if Bob’s not your Uncle, or it’s someone else’s number!). Read the sample config file to see the file formats. Note that the plain text file of number-name substitutions is a separate file, not a section of the optional configuration file, and also note that you must enter the numbers exactly as your VoIP provider sends them (in other words, if they send 8005551234 and you use 18005551234 or 800-555-1234 it will NOT match!).

Starting in Version 0.91 you can use a plain-text file of number-path/file substitutions, so (for example) if calls from a particular number are always from Uncle Bob, you can display Uncle Bob’s picture as the icon whenever a call arrives from that number. Read the sample config file for more information. Note that the plain text file of number-path/file substitutions is a separate file, not a section of the optional configuration file, and also note once again that you must enter the numbers exactly as your VoIP provider sends them.

Version 0.92 sets a rather short timeout on page fetches (still much longer than should be necessary to get the data), in an attempt to resolve a problem where very occasionally the script would just go into a coma, not exiting cleanly but still using memory and CPU cycles, without doing anything useful. I have been running this version for over six months now and have yet to see the script go into a coma, as it often seemed to do in previous versions.

(EDIT added September, 2010:) NOTE regarding EXPERIMENTAL version to work with Growl for Windows.  You should still download the main archive to get the instructions and such, but if you’d prefer to use Growl for Windows rather than Snarl, you can try this experimental version of the script. If you do try it, please let me know if it works as expected (and thanks to Andy Singh for his help with getting this working under Windows 7). Please read the Perl source code to find the module requirements (mentioned on or near line 15 of the script) as they differ slightly from the Snarl version.

Linksys and Sipura adapter users – check your RTP Packet Size and Network Jitter Level

 

Important
This is an edited version of a post that originally appeared on a blog called The Michigan Telephone Blog, which was written by a friend before he decided to stop blogging. It is reposted with his permission. Comments dated before the year 2013 were originally posted to his blog.

Edit: Reader Christopher Woods notes in a comment that the following is also applicable to at least some models of Linksys phones, e.g. SPA942 and SPA962.

Do you use a Linksys or Sipura VoIP adapter? Do the people you are talking to ever complain about your voice breaking up, or missing or dropped syllables, or unexplained clicks or noise?

There is an obscure setting in Linksys/Sipura VoIP adapters that is usually set incorrectly for most applications, at least on a factory-fresh adapter. Go to the SIP tab and check the RTP Packet Size – for most users, it should be set to 0.020 rather than the factory preset of 0.030. If you are running a connection where latency is critical (say you have a cable or satellite box that requires a phone connection to “phone home”, or you are trying to use a FAX machine) then you may even wish to set this to 0.010, which further reduces latency, at the expense of using a bit more bandwidth. In any case, the default 0.030 is not the correct setting when using the most commonly-used codecs. For more discussion of this issue, see this thread at DSLreports.com, which discusses how the RTP Packet Size and Network Jitter Level settings can be tweaked to achieve lower latency, along with the tradeoffs.

Be aware that the RTP Packet Size setting is found under the SIP tab, and that setting is applied to all lines served through that adapter. However, the Network Jitter Level can be set individually for each line, under the Line tabs. One interesting comment in the above-mentioned thread is that if a provider forces you to use a low-bandwidth codec, decreasing the RTP Packet Size may increase the quality of your calls, but again at the expense of increasing bandwidth used.

Changing the RTP Packet Size on one VoIP adapter resolved a few strange issues with audio quality. In this case the adapter was being used to connect to an Asterisk box on the same local network, so bandwidth usage wasn’t an issue. We set the RTP Packet Size to 0.020 and the Network Jitter Level to low, and it made a noticeable difference in the reduction of strange noises and breakups heard by the party on the other end of the conversation. However, changing the Network Jitter Level isn’t as critical as changing the RTP Packet Size, and in fact, changing the Network Jitter Level may be entirely the wrong thing to do on certain types of connections (probably not a good idea if your adapter is connected through a Wireless ISP, for example).

I must thank Paul Timmins for being the first to point out that the Linksys PAP2 has a default packet size of 0.030, which is incompatible with the uLaw (G711u) codec (or at least in violation of the standard). With that lead, I then discovered other articles (including the discussion thread linked above) that said essentially the same thing. So check those adapter settings, folks!

(And by the way, this advice probably does apply to some other makes of VoIP adapters, and even some IP telephones, but since I don’t have any readily available to look at, I can’t say for sure. If you know of any others that need to have a similar setting tweaked, please feel free to add a comment to this post).