Thursday, September 1, 2011
The picture caller-ID
I call it “poor man’s video telephony”, and it is essentially sending someone’s picture along with the caller-ID. I personally believe it is superior to video telephone, because you can control when the picture has been taken, make sure you have shaved properly in the morning, or have proper makeup, light, no hangover and so on. And still the other side can see who they are talking to! Plus you can do other things while hanging in a one-hour telephone conference, like getting some emails done.
In ISDN it seems to be possible to send a picture along with the caller-ID; but is has never really been used outside of the lab as far as I can tell. In SIP things are a lot easier, but again still I have not seen any SIP provider sending picture information along with the INVITE. So at the end of the day it is the responsibility of the PBX or even of the base to come up with a picture, based on the caller-ID.
Thanks to the iPhone and other smart phones, adding a picture to an address book entry has become real easy and popular. However, the problem is that the resolution can be brutal for a small device like the m9. Think about a 10 mega pixel photo! The m9 just has 16 MB RAM, so decoding the whole image is not an option. So right now, we put some limits to the resolution. And you can load pictures on the base, probably just a handful. More powerful is to load the pictures on the PBX (like the snom ONE), and then when the call comes in, the snom m9 loads the picture from the server.
In DECT, loading a picture is not trivial. DECT has timeslots with 32 kbit/s capacity, and you have to get the picture through that pipe unless you want to do something really fancy with multiple timeslots. So for an 80 x 60 pixel image, with let’s say 16 bits per pixel, you have 76800 bits, which can be loaded in 2.4 seconds. This is still okay. However, if you would have to load a let’s say 800 x 600 image, this would take 240 seconds. This would have a negative impact on the customer happiness! So what the m9 does, it takes the picture, decodes it (must be JPEG format to keep things simple), and then scales it to a format of 80 x 60 pixel. I believe the scaling is done “on the fly”, so that the internal memory is always 80 x 60 pixel, and there is no need to allocate huge amounts of memory. This may take a while, as the snom m9 CPU is just a small embedded ARM. However compared to the time it would take to transfer the image into the handset, it is well spent time!