Archive

WINDOW  ON  THE  FUTURE?  COULD SOFTPHONE 
BE  EVERYMAN'S  DESKTOP  TELEPHONE? 

	By William Flanagan, Editor & Publisher


A recent announcement from Inter-Tel (www.inter-tel.com) about their latest call processing software (for the Axxess and Eclipse platforms) pointed out that their converged voice and data offerings were compatible with the voice client shipping in Windows XP (bow toward Microsoft).  This means that most new personal computers can be an extension on an IP-PBX anywhere with IP connectivity.

Of course, the number of PBX features supported by Windows Messenger is fewer than Inter-Tel's own softphone (the Axxess softphone is a separate application whose user manual is over 80 pages--lots of features).  Over time, with gradual improvements, the free software may be "good enough" for most people who want plain old telephone service.  Call center agents and others who need to integrate the phone with computer records will continue to prefer the proprietary versions for some years.

One reason to prefer the vendor's own softphone is in the provisioning and setup.  Yes, it's another application to install on a PC, but the configuration, for example, to get the Axxess IP Softphone to work with an Inter-Tel Axxess call server is relatively simple:  the installer enters the ID of the softphone and the IP address of the server.  Ports default to fixed values--firewalls can be configured statically.  Proprietary protocols deliver all the PBX features.  

Setting up a generic softphone may require selecting the UDP and TCP ports.  If the signaling protocol is SIP (session initiation protocol, increasingly common in enterprise networks) the signaling ports are predetermined but the "bearer channels" or ports for voice packets are assigned dynamically in the range 1024 (or 5004) to 65535) by negotiation between an end point and its server. 

Ahh, there's a rub.  If the endpoint intends to communicate off-premises, its voice packets should have to pass through a firewall.  A few years ago, very few firewalls were aware of SIP (or H.323) signaling, so they couldn't listen to the call setup messages and "open a port" when needed for a call (and close it when the call ended).  At that time, many enterprises faced the choice between no packet voice and a wide-open firewall.  Usually the security concerns won out and packet voice (VoIP) was limited to the LAN.

Microsoft's web site offers some instruction for setting up voice service on Windows Messenger (not MSN Messenger, a different application).  Messenger's signaling packets for voice bear fixed TCP port numbers, so they pass through the firewalls and network address translation (NAT) fairly reliably.  The voice packets, assigned random UDP ports, may not get through.

The Universal Plug and Play Forum (www.upnp.org) defined a protocol that allows Messenger to tell a firewall which UDP port to open.  Messenger on WinXP can use this protocol to open ports on firewalls that support UPnP (certain Linksys hardware firewalls and the Linux IPtables software, for example).  However, the Messenger application also must close the port, so if Messenger quits abnormally the port may remain open and pose a security problem.  UPnP servers in XP, originally active by default, generate overhead traffic as they broadcast their readiness to accept messages on well-known ports--opening these PCs to security exploits from anywhere.  Unless there are known UPnP devices on the network, the two UPnP service processes (SSDP Discovery and Device Host) should be halted and disabled on all PCs.  

Analysis of UPnP points to another problem.  If an application on a PC (host) can order the firewall to open any port, a virus inside the firewall could open a LAN to the Internet.  

By contrast, a firewall that monitors call signaling messages to identify a port assigned to a new call--and when that call ends--doesn't merely follow orders from any PC.  The SIP procedure requires the control messages come from a server, not the user's PC, which means a server would have to be infected by a virus.  It's much easier for a user's machine, particularly a traveling notebook, to pick up a virus and bring it back inside the firewall.

So, for a while at least, the proprietary methods may have an advantage in security while communicating over the Internet, as well as simpler set-up procedures.