This testing was conducted before the unfortunate things happened to my brother.
I had the opportunity to setup the SIP phones testbed in my office. It was not too difficult as first I thought. A lot of information can be gathered from the internet. I choose the openSER SIP Server since it was initially developed by German Institute ;-). I setup the phone call within a local area network. All the IP nodes are connected behind the NAT (Network Address Translation) device. Using SIP Softphones, such as Ekiga in Fedora machine and Linphone in SuSe machine, I managed to make a phone call after setting up the SIP server. But to my surprise, the quality of sound is not as good as I think. Then, I tested with two WiFi IP Phones from Linksys. Hmm… the quality of sound is as good as the normal GSM phone. I did a quick check on the Codecs used by the WiFi phone. Two ITU standards Codecs are available: G.711 and G.729. G.711 is the 64kbps high bit rate codec with no compression similar to the regular phone. G.729 offers toll quality speech with a low bit rate 8kbps but require more CPU processing time. I couldn’t get the ADSL modem and phone line with streamxy support at this moment. Then, by using a PSTN gateway, a SIP phone can call to any regular phone in our homes. But until now, no testing is conducted. Based on the documentation, the openSER SIP Server with additional tools can support all the above services. I found out that the handover of the WiFi phone is a bit frustrating. Although it can auto-detect the neighboring Access Point based on the configured network profile, but you always need to wait for about 5 seconds before getting the IP address and also re-associate with new Access Point. Perhaps, mobile IP can solve this issue. While you are in the middle of your conversation, you will probably lose you counterpart’s voice when you are switching from one AP to another AP. If you have more control on your network and APs, I believe that we can solve this problem. Much works to do!