Our sponsors and affiliates:


Join TorWUG

 

 

 Home

 About Us

 Our Sponsors

 Submit News/Articles

 Newsletter Sign-up

 Why become
  a member

 Why sponsor
 TorWUG

 Upcoming Events

 Events Archive

 White Papers
 and Articles

 Case Studies

 Newsletters Archive

 Technology Areas
   Overview

 

 Fundamentals

 

 Why Wireless

   Networks

 

 802.11 + Wi-Fi

 

 802.11 N - New Wifi
    Standard Called
    MIMO

 

 3G Cell Networks

 

 Bluetooth

 

 WiMax-802.16

 

 RFID

 

 UltraWide Band

   Applications

 

 Mobile Field Apps

   Devices

 

 PDA's

 

 RIM

 

 PALM

 

 Smart Phones

 

 Rugged Devices

 

 DeviceReviews

   Security

 

 WEP

 

 WPA

 

 802.1x

   Internet

 

 VOIP

 

 Hot Spots

 

 WAP

 

 WISP

 

 New Business Models

 News

 Development
 Tools

 Online Courses

 Discussion Forum

 Jobs in Wireless/
 Mobile Techs

 Contact Us

White Papers And Articles

Linux Wireless Telephony Gateway/Gatekeeper (LWTGG???)

After working with a variety of professional and not-so-professional wireless h.323 gateway/gatekeeper combinations, Taylor Systems decided that they couldn’t afford to use another vendor’s product and still maintain the simultaneous product and version control necessary to provide a reliable product set. The Answer? A Linux Open Source PBX product coupled with a custom built remote enabled administration application.

Prior to the involvement of Taylor Systems as a provider of wireless expertise, Ken Taylor supported Symbol Technologies’ 802.11 wireless h.323 based NetVision Phone (NVP) as it matured through several manufacturer’s Gatekeeper/Gateway (G/G) products. The issue that kept surfacing was the lack of control over the reliability of the product mix. Another problem related to the ability (or lack thereof) of the sellers and resellers of the technology to reliably integrate that technology into the client’s incumbent and probably proprietary telephony technology.

Another large stumbling block was the health of the incumbent LAN that the wireless technology was often irreverently bolted onto. In many cases the deployment of the wireless technology was straightforward. The LAN that it connected to was sometimes not capable of supporting a new, time sensitive, and sometimes bandwidth intensive application. The G/G function was generic and non-specific.

The wireless portion of this type of project cannot be underestimated. A proper site survey must be done to ensure that RF coverage is adequate. It is interesting to note that a site survey for voice is different from a site survey for data only. Number one, very few data transactions are completed in the smoking area, the stairwells, or the washrooms. It is very possible that voice activity will be performed in most of these areas. Number two, the voice survey needs to be done with a set of phones in a “walkie-talkie” type conversation to ensure that there is adequate RF reliability in that specific area. That commercial where the “tester” is wandering about the country saying “Can you hear me?” is, unfortunately, not all that far fetched. Realistically, any dropped voice packet will affect user acceptance and the usability of the service.

By itself, the h.323 based NVP / Access Point WiFi compliant combination functions well enough. The other components such as the LAN, LAN Switches, HUBs, Routers, and the designated G/G components often seemed to be ganging up on the telephony component. The Access Points (AP) in conjunction with the NVP component supported a proprietary Radio Frequency (RF) subnet mask that enabled the AP to prioritize voice traffic. Only recently, has the rest of the world, wireless and wired, caught up to the need for LAN traffic prioritization. It seems that not Ethernet bits are created as equal as the Ethernet Fathers had intended.

There have been a number of advances in the wireless arena with regards to multiple VLANs and Q-bits to enable most wired and wireless networks to successfully cohabitate.

The bandwidth requirements for voice are dependent, to a great extent, on the CODECs (Coder / Decoder) that the system uses as a compression (G.711 / G.729ab / GSM etc.) algorithm. While this discussion is beyond the scope of this particular paper, suffice it to say that one of the devices in the set will dictate the CODEC to be used. This CODEC will dictate to a great extent, the bandwidth required for the RF network, the most vulnerable component in the set.

Taylor Systems has taken a big step forward in reducing the cost and increasing the effectiveness of a Gateway / Gatekeeper function by utilizing industry standard components as a set, to support not only the NVP / h.323 devices but the SIP (Session Initiated Protocol) Ethernet Phones and the freely available SIP based so called “soft phones” intended to be loaded onto PCs equipped with sound and microphone capability.

By using Linux and the Asterisk (www.asterisk.org/) Open-Source PBX application, Taylor Systems has been able to reduce the cost of the G/G interface component, enable the client site to support industry standard SIP and h.323 VoIP devices such as the Symbol NVP. Standards is the name of the game and the Asterisk product does it very well. The problems associated with supporting a specific G/G component in conjunction with a standards based wireless telephony device are greatly reduced with an Asterisk product already specifically optioned to support the requirement.

The Taylor Systems development effort has made it much easier for the user client, especially the small user client to utilize this technology. By utilizing the base Asterisk Kernel, a relatively inexpensive PC based hardware component can be readily connected between the existing PBX or Key System and the existing LAN.

Extending that functionality to a remote location is as simple as extending the LAN. That location on the loading dock or the remote branch office across the street, or across the parking lot, just got much more cost effective and easier to provision because of a WiFi standards based 802.11 wireless hop. Providing data and voice services simultaneously to that “remote” location has now become fairly straightforward.

It’s not all free, there may well be a cost associated with bandwidth engineering, and ensuring that sufficient bandwidth is available on all LAN/WLAN components. On most small sites this is not usually an issue. As a general rule of thumb, the larger the site, the greater the issue. It is often a matter of setting client expectations or designing success into the system by means of a pilot project.

It is interesting to note that the asterisk product not only supports wireless VoIP capability but also functions very well as a conference bridge and an email system. That wirelessly connected PC on the end of the loading dock just received an Email with a .wav file attached to it about 10 seconds after a message was left on the Asterisk VMail system.

With reference to the Conference Bridge function, all the wireless phones just got turned into a kind of a channelized walkie-talkie system available on an as required basis. On several occasions in my experience, the client has wanted to replace an outdated and maintenance intensive multi-channel walkie-talkie system. I wonder what would happen if each of those walkie-talkie channels got replaced with a dedicated multi–user conference bridge. Not only would the wireless users be multifunctional but anyone with a land line could also dial in to the ongoing “Conference” call as required. That overhead paging system that no one can understand anyway just became a little more redundant. Management or technical expertise can be quickly brought to bear on a situation from any phone in or out of the building via the conference bridge.

This system has been functional at the Taylor Systems office for about 6 months. Taylor Systems is now looking for a beta site.


Top

The Toronto Wireless User Group is a member of the Oreilly User Group Program.

Expand Beyond

Vist the Oreilly site for a 20% discount on any title.

  This site was last modified Tuesday, July 3, 2007