I am in search of a simple "music on hold" (and background music) system for the office PBX.

I have already tried a CD player and WinAmp on a PC. The CD is short in duration and eventually wears out. WinAmp is better, but it requires a PC with a dedicated sound card (or every other sound source disabled), it doesn't run as a service out of the box and it does occasionally stop playing for no apparent reason.

All these were happening before the portable MP3 players days. So, the obvious today's choice would be an MP3 player with enough memory, set to shuffle and repeat. Using an AC to USB adapter should solve the power problem, as batteries don't last for ever, right? Unfortunately, most USB-powered MP3 players switch to data mode when connected, even if connected to power-only USB. And when in data mode, they just won't play songs! Experiments with several players and asking various salespersons confirmed that fact.

So, how can it be done? I got a suggestion to find a player powered from a non-USB source. Not an easy task, these days. The last such device I remember was an MPIO MP3 player (yes, it still works, but it's not mine). Although this was before USB totally dominated the peripherals market, I always held using a non-USB power adapter against it. Little did I know...

Then I accidentally came across the Creative MuVo V100. Its design is exactly such that it distinguishes connection to data USB vs power only USB and acts accordingly, that is play MP3s even when powered! Perfect, at least in theory. Preliminary tests show that, while it works as advertised, it, too (like WinAmp), occasionally stops playback for no apparent reason.

While tests continue, it seems I am still searching...

Update: Creative is in the clear. Apparently, MuVo works fine. When I tried another USB power supply all problems disappeared. It turns out even a simple device like that can be faulty enough to work at random! I am finally happy with my music on hold.

Two weeks ago I was asked again to install a couple of cameras to watch a newborn baby at home (with the sitter...).

Provided there is an ADSL in the premises, the task is trivial, tech-wise. In this case, the heart of the system is an AVM Fritz ADSL modem, 4 port switch, wireless Access Point with SIP, complemented by 2 VIVOTEK PT7137 wifi IP pan-tilt (but not zoom) VGA cameras.

The first problem in serving content from a non-static (dynamic) IP address is how to hit the correct IP, which is a moving target (I recently came across the fact that, in Greece, ISP OTEnet actually disconnects dynamic ADSL connections every 54 hours, just to change IP address!). The solution to this is dynamic DNS, in this case in the form of the free service DynDNS (other such services also exist). What dynamic DNS does is have a client program automatically update the current IP address of an ADSL connection to a host of the form <myhost>.dyndns.org. In this case (lucky me), both the router and the cameras have dyndns.org support built-in. If this wasn't the case, I could set up a dyndns.org client in a windows or linux pc to do the job. I could, alternatively, buy a static IP address, which I do not prefer for security and cost reasons. More than one dynamic DNS client can be set up for redundancy, if needed.

The other problem in serving content this way is that the Internet IP one's router uses is different from the local IP address of this same router and each of his local network devices (yes, it's too technical). The router takes care of back-and-forth IP translation for the outgoing connections (browsing, email reception & transmission, Instant Messaging etc.) automatically (using NAPT, Network Address Port Translation). However, when a local server needs to listen to Internet incoming traffic, this must be routed to it in a way that cannot be automated (not until UPnP, anyway, which is another story), so port translation must be manually programmed to the router and the method is called "port forwarding". What this does is tell the router what to do with any incoming traffic, depending on the Port it uses: drop it or forward it to a different internal IP and Port, where a server is standing by.

When similar content is served by more than one servers (in this case all the IP cameras transmit audio & video using the http protocol which by default "listens" and "transmits" on port 80), we have the third problem: We need to reference two (or more) different servers serving the same service (http) using the same single external IP address.

The solution here is in the way protocol calls are made: when our browser shows it connects to http://blog.dipot.com, it is actually connecting to http://blog.dipot.com:80, where 80 represents the connection's port number (which has possible values from 1 to 65535). The port value of 80 is implied, because it is the standard port number for the http protocol (other protocols by default, but not necessarily, connect to other ports). This essentially means that we can reference ~65000 different services (protocols) on the same IP address. So, what we do is agree between ourselves and the router to use these two (or more) addresses to call our two (or more) IP cameras (the "http://" prefix is important, because the specified ports are not usually intended for this protocol):
Camera 1: http://<myhost>.dyndns.org:12001
Camera 2: http://<myhost>.dyndns.org:12002
Camera n: http://<myhost>.dyndns.org:1200n

So, assuming the cameras addresses are 192.168.1.21, 192.168.1.22 (& 192.168.1.2n) and all transmit to port 80 (the default) we program the router to forward calls to ports 12001, 12002 (& 1200n) to 192.168.1.21:80, 192.168.1.22:80 (& 192.168.1.2n:80). It is important for the cameras IP addresses to be static, so we don't have another moving target to cope with.

In case the router didn't support forwarding to a different port than the incoming, we should then program the cameras to listen and transmit to ports 12001, 12002, ... 1200n, which is perfectly possible, if not simpler.

This came out larger and more technical than intended. All these, however, can be implemented in about 30' and are applicable to other services as well.

For router-specific instructions to program port forwarding, refer to the excellent guide "Free Help Setting up Your Router or Firewall".