Wi-Fi VOIP Handsets and Public Hotspots

Wi-Fi VOIP handsets are great if they are intended for use either with (i) private hotspots or (ii) public hotspots that do not re-direct users to an initial page where they must log in or at least agree (click through) to some terms of use. However, since these devices lack web browsers, they cannot be used with public hotspots that require the user to do something on a redirected initial web page. I’ve tried two experiments in the hope of finding a work around to this problem. One failed but the other succeeded.

The first experiment was to change the MAC address for the wireless adapter connected to my laptop to match the MAC address of the VOIP phone. I logged in and authenticated on my laptop. I then turned off the laptop and turned on the wifi voip phone. I was hoping that, with the same MAC address, the wireless access point would think that my VOIP phone was still my laptop but the access point was too smart for that. I even tried to manually assign the same IP address to the VOIP handset as was obtained by the laptop wireless adapter. However, this didn’t help either.

However, my second work around did succeed. What I did was set up two wireless adapters on my laptop. The first was set up in the default “infrastructure mode”. The second was set up for an “ad hoc” network (using a manually assigned private IP space address rather than a DHCP assigned address). I set up my Wi-Fi VOIP handset to also use “ad hoc” networking with a private IP address in the same subnet as the second laptop wireless adapter. I configured the first adapter to share its connection with the second (using XP’s built-in Internet Connection Sharing function). I then logged into the access point using the first adapter. My Wi-Fi VOIP handset was able to use the Internet connection obtained by the first wireless adapter. Some tweaking of the personal firewall software installed on the laptop was required in order to allow the transit packets to pass from one adapter to the other.

I should note that the above work around is too complicated for most users to set up. Ideally, an authorized user would be able to go to a web page, log in, and then manually enter a MAC address that would be recognized by the system for some length of time (hour, day, month?). The services offered could be restricted to just the SIP 5060 port. Alternatively, a wireless service provider could elect to simply allow communication on port 5060 without authentication but could limit the destinations to valid VOIP service providers. Also, hopefully manufacturers of VOIP handsets will wake up to the fact that a browser, even a small limited functionality one, is more important than building in email, SMS or other functionality.