Upload
lecong
View
216
Download
1
Embed Size (px)
Citation preview
Meru Best Practices Guide
MERU BEST PRACTICES GUIDE | VOICE
Author | Vijay Rajanarayanan | Technical Marketing Engineer
Date | July 2010
Version | BPG_Voice_V1.0
BPG | VOICE
OVERVIEW ................................................................................................................................................................................. 3
MARKET SEGMENTS............................................................................................................................................................ 3
Healthcare .............................................................................................................................................................................. 3
Hospitality............................................................................................................................................................................... 3
Retail ........................................................................................................................................................................................ 3
PAIN POINTS AND CHALLENGES FOR WIRELESS LAN DEPLOYMENTS ...................................................... 3
Shared Medium..................................................................................................................................................................... 4
Roaming .................................................................................................................................................................................. 4
TYPICAL VOICE DEPLOYMENT COMPONENTS IN A WIRELESS NETWORK ............................................... 4
DEPLOYMENT CONSIDERATIONS .................................................................................................................................. 5
Seamless Roaming on Virtualized WLANs.................................................................................................................... 6
Coverage for Seamless Roaming................................................................................................................................ 6
Power Considerations..................................................................................................................................................... 6
Multicast Considerations............................................................................................................................................... 6
Security Considerations...................................................................................................................................................... 7
Quality of Service (QoS) Considerations........................................................................................................................ 7
DSCP Tagging................................................................................................................................................................... 8
Additional QoS Rules ..................................................................................................................................................... 9
Power-save Considerations................................................................................................................................................ 9
Push-to-talk Considerations................................................................................................................................................ 9
VLAN Considerations........................................................................................................................................................ 10
Co-existence with Legacy and n Clients ...................................................................................................................... 10
MERU INTEROPERABILTY SOLUTIONS...................................................................................................................... 10
Ascom................................................................................................................................................................................... 11
Cisco...................................................................................................................................................................................... 12
Polycom/Spectralink......................................................................................................................................................... 12
Vocera.................................................................................................................................................................................... 12
CONCLUSION......................................................................................................................................................................... 13
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 2
TABLE OF CONTENTS
This document is intended for system engineers and network designers using Meru Wireless LAN
infrastructure to implement an enterprise solution. This document focuses on providing guidelines to
deploy voice solutions in Meru infrastructure for maximum reliability and performance.
Voice has become a critical component of all enterprises. With the various advanced communication
schemes available, VoIP has become of utmost importance to almost all verticals. The evolution of
Wireless VoIP has been a giant step in help moving an enterprise to an All Wireless Enterprise
resulting in a great reduction of infrastructure costs.
Mobile Voice over Wireless LAN Applications helps the employees/end user in an enterprise
environment to be more productive while they are in different locations at their work place and at
the same time reduce infrastructure costs to a great extent by eliminating the need of expensive
cabling across the facility. Voice plays a major role in day to day operations of any enterprise. Hence
it is the absolutely necessary to have a wireless voice infrastructure solution that is capable of
delivering an end-user experience in par if not better than a wired infrastructure solution.
Healthcare deployments are usually the ultimate example of what a mission critical solution means.
voice is a very important component of the healthcare enterprise solution. Nurses have to make
effective voice communication with the doctors to update patient status and communicate other
critical messages. It is of utmost importance to have a stable, reliable solution that not only provides
toll quality voice but also effectively interoperate with other components in the network
infrastructure.
Hospitality has become a huge vertical where voice has become very important in their day to day
operation. There are a lot of business critical voice applications running over WLAN infrastructure. It
is very important to have an ease of use for the end user with minimum or no down time. Care
should be taken to make sure that all other devices in the network infrastructure work without any
interop issues.
Retail enterprise market has started using mobile voice devices to communicate effectively in huge.
voice should work effectively with most commonly used devices like wireless handheld printers and
barcode scanners.
OVERVIEW
HEALTHCARE
MARKET SEGMENTS
MERU BEST PRACTICES GUIDE | VOICE
HOSPITALITY
RETAIL
PAIN POINTS AND CHALLENGES FOR WIRELESS LAN DEPLOYMENTS
Wireless voice solutions have become prominent of late and is gaining a huge momentum in enterprise
networks. However deploying voice in any enterprise network is always a challenging task. There are
numerous end-users and IT complaints when deploying voice with traditional Wireless LAN networks.
The network administrator usually hears complaint about dropped calls, choppy and one way audio,
spotty audio and coverage issues. Whenever data is also used with voice, there are usually conflicting
requirements to deploy voice and data. While deploying a traditional microcell Wireless LAN there are
some limitations that are very difficult and sometimes nearly impossible to overcome. Microcell
changes AP channel and power levels in an attempt to minimize co-channel interference. If APs can
hear each other, there is co-channel interference. Lowering RF power results in worse signal to noise.
All these issues will have an effect on the voice quality in the network.
BPG_Voice_V1.0 | Page 3
There are a few critical requirements to ensure a good voice experience over WLAN. These include
high availability, reliability, mobile toll quality voice, client device and soft phone application choice.
There are also a number of fundamental challenges that impact the requirements for a great voice
experience. The two major challenges are shared medium and roaming in any Wireless LAN Voice
deployment.
SHARED MEDIUM
The fundamental problem with wireless is that it is a shared medium and unless you control who is
using it at a time, there will be contention. Voice quality needs low latency, jitter and packet loss.
Voice devices usually talk all at once and that causes a lot of latency due to the back-off schemes in
Wireless LANs. Excessive latency can cause delay and filling up of jitter buffers, leading to packet
losses and poor call quality. In the presence of data devices and other bandwidth hogging devices,
the voice devices can suffer due to the unavailability of the medium. All these issues cause
deployment challenges in the wireless environment.
ROAMING
In any wireless voice solution, mobility is a very important factor. The clients connected to the
infrastructure sometimes make poor roaming decisions. Frequent roaming by the client results in the
loss of connectivity and in turn, poor voice quality and dropped calls. This is one of the major issues
that one can see while deploying voice over Wireless LAN networks.
Voice solution in an enterprise can be deployed with different handset vendors. Different
handset vendors require different components to deploy their voice solution in the
enterprise. Even though different vendors do require different individual components for
their individual solutions, there are some common components used in these network
infrastructures. The below network diagram depicts the typical deployment of an enterprise
solution supporting voice.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 4
TYPICAL VOICE DEPLOYMENT COMPONENTS IN A WIRELESS NETWORK
Figure 1: Typical Enterprise Deployment Supporting Voice Clients
DEPLOYMENT CONSIDERATIONS
In order to get the best performance, it is highly recommended to follow a set of guidelines and
considerations. The following section describes different guidelines on how to deploy voice over
Wireless LAN in an enterprise environment for achieving the best quality and reliability.
SEAMLESS ROAMING ON VIRTUALIZED WLANS
In any voice solution the most important thing to account for is the dropped calls even when the
person using the device is constantly moving. Meru Networks unique Virtual Cell/Virtual Port
architecture provides all the users with a seamless mobile experience. It is highly recommended to
deploy any Meru infrastructure solution with Virtual Cell/Virtual Port turned on for achieving the best
of class user experience. Virtual Port architecture provides a unique BSSID for each client throughout
the network. The client always sees only a single Access Point from its perspective. Wherever the
client is in the network, it thinks it is connected to same Access Point or its “Virtual Port”. There are a
few guidelines that need to be followed when designing a Virtual Port – especially when voice
solutions are involved.
MERU BEST PRACTICES GUIDE | VOICE
Meru infrastructure solution uses unique single channel architecture. This architecture allows the
network designer to install the wireless network without any complex channel planning and site
survey. Because all the Access Points are seen in the same channel, it eliminates the component of co-
channel interference. On top of the single channel architecture when Virtual Cell/Virtual Port is added,
it provides the end user with seamless roaming experience with zero hand-off. In Virtual Port mode,
each client is assigned a unique BSSID or a unique “Virtual Port” and holds on to it across the entire
network. Wherever the client goes in the network, it seems as if it is talking to the same port and
moving with it. It gives the end user wire-like experience in a wireless environment.
In any enterprise where voice is used, it is very important to have a very good voice quality even if the
devices are mobile and constantly moving around. In a Virtual Port mode of Meru infrastructure
deployment, the controller makes the decision of when to hand-off the voice device to the next AP. The
voice device does not see any missed packets or dropped calls due to re-association and it maintains
high quality voice call even if it is consistently moving across the network.
BPG_Voice_V1.0 | Page 5
Figure 2: Seamless Roaming of Voice Clients in Virtual Cell/Virtual Port
By default roaming threshold on most of the voice devices are set a little bit more aggressively than
as required by the Meru infrastructure. In the Meru infrastructure, since the controller initiates all
hand-offs, it is recommended to have the roaming thresholds of the voice devices to be as least
aggressive as possible. This would help in the proper control of the voice devices by the controller. If
the roaming threshold is set too aggressively, there is a chance that the voice device can have
problems like roaming issues or in some cases falling completely out of the network.
In some cases when the density of clients are very high, channel layering is recommended. In this
case all the clients are not going to be in the same channel. When they move out of this area into
the regular network, the clients might experience a hard roam. When designing this portion of the
network, extra care should be taken to make sure there are no coverage holes.
Coverage for Seamless Roaming
Ideal AP Placement and coverage is a very important factor in the Virtual Cell/ Virtual Port
deployment. Voice is very sensitive to coverage holes and extreme care should be taken that there
are no coverage holes in the network infrastructure.
For ideal deployment of voice clients, the following parameters are recommended.
dBm Cutoff -65dBm
SNR 25 (Assuming the Noise Floor is -90dBm)
It is highly recommend that at any given location in the wireless infrastructure, we can have no
coverage gaps. The clients should hear the APs at least with -65dBm signal strength to get good
coverage. In most deployments, due to necessity or the lack of it, there is little to no coverage in
stairways and other common areas like restrooms. In these cases it is recommended to educate the
endusers about the lack of coverage in these areas. If voice needs to work in these areas effectively,
it is recommended to have additional access points in these locations to increase coverage.
Power Considerations Meru Networks unique single channel architecture requires all access points to be on the same
channel. When all APs are in the same channel, it is absolutely critical for adjacent access points to
hear each other. During the deployment of any Meru infrastructure, it is always recommended to set
the APs to the maximum possible transmit power. In this way, the APs adjacent to each other can
hear one another. Since the APs transmit at the maximum possible power, it is also recommended
that the clients are also set to transmit at the maximum possible power. In some cases the client
cannot transmit with the same power of the APs. In such cases one has to make sure that there are
enough AP overlapping in the coverage area, so that the packets transmitted by the client is
reachable to one of the APs in the infrastructure.
Multicast Considerations When Virtual Port is enabled in the Meru infrastructure, all the multicast packets are converted to
unicast packets in the Access Point and transmitted over the air. This results in a much more reliable
solution for voice. When a packet goes as multicast in the air, if the packet is lost due to collision,
there is no way to recover it. However if the packet is transmitted in air as unicast, since a 802.11
MAC level acknowledgement is necessary for each packet, even if the packet is lost due to collision,
it will be retransmitted resulting in the packets reaching the destination ultimately. This results in
better reliability and improved user experience. In order to get reliable performance when using
multicast with Virtual Port there a set of recommendations that has to be followed.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 6
• For multicast to work in the Meru infrastructure there is a “one to one” mapping requirement for a
VLAN to ESSID. For example if there are two ESSIDs in the system, the ESSID that has to do
multicast needs to be in a separate VLAN than the other. Creating an ESSID and VLAN is beyond the
scope of this document. Please refer to the System Director configuration guide for more details.
• It is always better to have separate ESSIDs and VLAN for voice and data. This helps in better
control for voice – especially if some voice specific settings like power-save features are necessary
for voice – but may not be needed for data.
SECURITY CONSIDERATIONS
The security of any WLAN solution is always a critical consideration in every WLAN deployment.
When voice solutions are required in any WLAN deployment, care should be taken to make sure that
the voice devices supports the required security schemes. Not all voice solutions support all security
profile. The various security profile that a Meru infrastructure supports and recommendations for
each of these are discussed below:
• Clear/Static WEP – These are the simplest forms of encryption schemes. It is highly
recommended not to use this mode at all for voice solutions unless and otherwise
absolutely necessary.
• WPA-PSK/WPA2-PSK – WPA uses TKIP for encryption and WPA2 uses AES encryption.
PSK stands for Pre Shared Key and a common master key is given out to connect to the
network. It does need additional back-end components like RADIUS or Certificate Servers to
authenticate. Almost all the commercially available voice solution supports the use of WPA-
PSK scheme of encryption. This type of encryption scheme is one of the recommended
settings and can be used in a single site deployment or in a place where the voice devices
do not leave the particular site.
• WPA-PEAP/WPA2-PEAP –The shared key mechanism of authentication used in WPA-PSK/
WPA2-PSK does not provide a per-user or per device authentication, every device and every
AP that is part of that WLAN uses the same shared key. WPA-PEAP/WPA2-PEAP uses
TKIP/AES but adds 802.1 X/EAP-based authentications to the certification. There are
additional back-end components like RADIUS or Certification Servers needed to
authenticate. With PEAP, each user can be authenticated separately or be authenticated
based on sites and locations. In a huge deployment with multiple sites, it is recommended
to use the WPA-PEAP/WPA2-PEAP scheme. Some voice devices do not support the PEAP
type of encryption. In these cases, it is recommended to use WPA/WPA2-PSK encryption
schemes.
When in a wireless infrastructure if a need to use of WPA/WPA2 – PEAP arises, it is necessary to
use backend components like RADIUS Servers for authentication purposes. The configuration of
RADIUS servers is out of scope of this document and is not discussed.
QUALITY OF SERVICE (QOS) CONSIDERATIONS
In any enterprise solution, the ultimate need is to provide the services reliably with the highest
quality. Quality of service is the ability to provide different priority to different applications, users, or
data flows to guarantee a certain level of performance to a data flow.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 7
DSCPIP Precedence Unused Bits
DSCP Tagging
It is of utmost importance to have QoS correctly configured for voice to work as expected.
There are various levels of QoS Priorities in the Meru infrastructure.
Figure 3: Layer 3 QoS DSCP
0 and 3 – Best Effort traffic
1 and 2 – Background traffic
4 and 5 – Video traffic
6 and 7 – Voice traffic
As shown in table above, voice is given the highest priority of 6 and 7. The voice queue is given the
highest priority and is always transmitted out first. So it is important to make the voice packets go
into the correct queue with highest priority.
For any network packet, the IP header DSCP values can any of these 10 decimal values mentioned
below
0 - Default
8 - Class Selector 1
16 - Class Selector 2
24 - Class Selector 3
26 - Assured Forwarding
32 - Class Selector 4
40 - Class Selector 5
46 - Expedited Forwarding
48 - Class Selector 6
56 - Class Selector 7
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 8
In most voice solutions, the voice packets are tagged as expedited forwarding. A deeper dive into
this reveals the following:
46 in Binary equates to 101110. WMM APs looks only at the 1st 3 bits for prioritization and queuing.
The 1st 3 bits of the DSCP tagging equates is “101” which translates to video in Meru infrastructure.
In this case, the voice packets are going to hit the video queue and this can result in choppy voice
quality. In order to get the best voice quality, care should be taken to make sure the IP DSCP header
is tagged correctly. This has to be done on IP PBX or the SIP Server through which all the voice
packets communicate. All the packets that come into the controller should have a DSCP tag of either
48 or 56 for good voice quality
Additional QoS Rules
Meru infrastructure can detect flows of SIP and H.323 version 1. In this way it can prioritize the flow
of packets. In addition to these default QoS rules, additional QoS rules can be added to improve the
user experience. For example QoS rules can be added based on packets coming out a particular IP
address. This would help in different scenarios to improve the end user experience for voice
solutions. The configuration guides for the four major voice solution vendors gives you an insight of
how to configure vendor specific solution QoS rule. Please refer to these guides for further
information how to configure these QoS rules.
POWER SAVE CONSIDERATIONS
Power save is a very important feature for mobile voice clients. The mobile voice devices are usually
very small for easy portability and they do not have very powerful batteries. Most wireless voice
devices use some form of power save mechanism to reduce battery drain. There are two common
modes of power save mechanism. PS Poll mechanism is the traditionally most common used
mechanism for power save. This is available and supported in almost all wireless voice devices. The
other mechanism is the UAPSD or Unscheduled Automatic Power Save Delivery which is the later
technology.
The Meru infrastructure supports PS Poll mode of power save mechanism in the non V-cell mode in
AP300s. When a deployment needs to use V-Cell/V-Port mode, it is recommended to turn the PS-
Poll mechanism off. Even though battery life in this case is reduced a tad, the voice quality is good.
The Meru infrastructure supports UAPSD starting System Director version 4.0 and later. UAPSD
clients use unscheduled trigger packets to wake up and go to sleep resulting in lesser use of battery.
Most of the new voice devices available in the market today supports UAPSD. When both the
infrastructure and voice solutions supports UAPSD it is recommended to use it as it improves both
voice quality and battery life
With UAPSD it is critical that DSCP tags are set correctly and match both upstream and
downstream. It is also critical that any QoS rules on the system do not cause a mismatch if
overriding DSCP. A DSCP mismatch can result in a failure of UAPSD, poor battery life, or poor
quality call and in some cases disconnects from the network.
PUSH-TO-TALK CONSIDERATIONS
Push to Talk is one of most important applications of a voice solution. Most of the major enterprise
class voice solution vendors support Push to Talk. Push to Talk usually uses multicast. When Push to
Talk is used there are certain things that need to be addressed.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 9
In a Virtual Cell/Virtual Port mode, the multicast packets goes out as unicast over the air. This results
in better reliability of the multicast packets to reach the required destination. Even though the
reliability is higher in this case, the overhead involved is greater as well. It is important to place the
Access Point close by so that they can hear their neighboring APs and the transmissions are going at
the highest possible data rates. At the same time it is important to make sure the environment is not
very dense. Care should be taken to make sure that management traffic overhead is not very high.
VLAN CONSIDERATIONS
It is always a very good practice to isolate different VLANs for different applications. Hence it is
recommended to have a separate VLAN for all voice applications. When multicast is used in the
Infrastructure as required by most Push to Talk deployments, Meru infrastructure requires one to one
mapping of ESSID to VLAN. It is recommended to have all wireless voice clients connected to the
same ESSID. This ESSID must map to a unique VLAN.
If in an enterprise network, voice solutions from multiple vendors are used, it is recommended to
have a VLAN for each vendor specific voice solutions. This is recommended due to the fact that to
make multicast work there is a need for one to one ESSID to VLAN mapping and each vendor might
have specific ESSID related configuration parameters. Please refer to the vendor specific
configuration guides for configuration parameters. Please note for many handset vendors, it is
recommended if not required to have handsets in the same subnet/VLAN as the voice gateway.
CO-EXISTENCE WITH LEGACY AND N CLIENTS
Voice applications are very sensitive to jitter and latency. However it does not need high bandwidth
or throughput requirement. In the presence of higher bandwidth requirement applications like video
applications or FTP services, when a dual band AP and clients are used, it is recommended to move
all 5 GHz capable clients to 5 GHz band and configure the APs accordingly. voice devices can remain
in the 2.4 GHz band as long as the interference from the other legacy devices is minimal. If a co-
existence with b-only devices is required in 2.4 GHz band, it is recommended to turn the protection
mechanism ‘on’ for those environments. System Director version 4.0 and later supports the use of
Band Steering. When Band Steering is enabled, based on the mode that it is set to, the higher
throughput clients are automatically steered into the 5 GHz band and the voice clients are steered to
2.4 GHz band. By applying this mechanism, the voice client will have lesser competition for air time
with the higher bandwidth clients and thereby improve its performance.
Meru Networks WLAN infrastructure works with different wireless network devices. Meru Networks
work with different partners called Wireless Interoperability and Network Security (WINSTM) partner
who provide a wide range of mobile devices, market-specific applications, and complementary
capabilities that enable our customers to maximize and extend the value of their Meru WLAN
deployments. The following section touches briefly on the four major voice solution vendors that
work with Meru infrastructure and the major components that are necessary for setting up an end to
end voice solution.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 10
MERU INTEROPERABILITY SOLUTIONS
ASCOM
Ascom Wireless is one of the leading providers of voice solution especially in Healthcare
space. Ascom Wireless is a Meru WINSTM partner. There are specific components that are
used while deploying Ascom voice solutions in an enterprise WLAN.
• Ascom PDM – Ascom PDM or the Portable Device Manager is a hardware box
that usually sits on the network. This is not an essential component for the
Ascom phones to operate, but it is typically seen in most Ascom voice solution
deployment. This device is used to configure the Ascom phones remotely over
the wireless network. Some Ascom PDMs can also double of the Integrated
Messaging Server or the IMS used for messaging within the phones.
• Ascom VoIP Gateway – Ascom VoIP gateway is an optional hardware component
that is deployed in the network. This gateway usually interacts with the PBX. The
gateway supports H.323. The gateway is capable of SIP but it is not supported
by Ascom. This is an OEM product Ascom does not directly develop.
• External SIP Server – This is an optional component. An External SIP Server is
necessary when an Ascom VoIP Gateway is not used. We do not need both an
Ascom Gateway and an external SIP Server.
• External PBX – The external PBX can be either Analog or Digital PBX. This
usually interacts with both wired and wireless voice devices that might be
present in the network infrastructure.
While deploying a wireless network when Ascom phones are used, we should ensure that all
Ascom specific parameters are precisely configured on the Meru system. For more details on
how to configure the Meru infrastructure for Ascom voice solution, please refer to the Ascom
Deployment Guide.
CISCO
Cisco has been the market leaders for most networking equipment. Even though Cisco is not
a WINSTM partner Cisco phones work well with Meru infrastructure and have been deployed
at different customer sites. When implementing a Cisco wireless voice solution, specific
components are necessary for network deployment.
• Cisco Call Manager – Cisco Call Manager is absolutely necessary in all Cisco
based WLAN deployment. Cisco uses SCCP or the Skinny Client Configuration
Protocol. The Cisco Call Manager is used to configure/maintain the Cisco
Handsets. In addition to this the Cisco Call Manager also plays a pivotal role in
establishing calls.
• Cisco Unified Border Element (CUBE) - The CUBE is usually a Cisco Router. This
is typically used to communicate with the external SIP Server or the Gateway. In
some cases the Cisco Call Manager by itself can act as a CUBE when it runs on a
router.
• External PBX – The external PBX can be either Analog or Digital PBX. This
interacts with the Cisco Call Manger and the CUBE network to establish external
calls.
While deploying the Meru Wireless Network with Cisco phones, we should ensure that all
Cisco specific parameters are precisely configured on the Meru system. For more details on
how to configure the Meru infrastructure for Cisco voice solution, please refer to the Cisco
Deployment Guide.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 11
POLYCOM/SPECTRALINK
Polycom/Spectralink along with their OEMs have a very large customer base of enterprise
class Wireless LAN voice solution. Polycom/Spectralink is a Meru partner WINSTM partner.
There are specific components that are used while deploying Polycom/Spectralink voice
solutions in an enterprise Wireless LAN.
• SVP/OEM Server – Polycom/Spectralink or its OEMs use a special protocol to
provide Quality of Service for their wireless phones. This piece of hardware is
the server that provides Quality of Service and Call Admission Control for the
wireless phones. This is not an essential component, but is used in one mode of
deployment. When deploying Spectralink SVP Solution with Meru Virtual Cell/
Virtual Port architecture solution, we cannot leverage the Spectralink specific
Quality of Service. However regular Meru QoS and Wi-Fi Specific QoS will still
apply for Spectralink
• TFTP Server – The TFTP Server can be any common TFTP Server. This server
contains the configuration and is used to download them to the handsets.
• SIP/H.323 Server – The SIP or the H.323 Server to establish and maintain voice
calls over the network. This communicates with the external PBX.
• External PBX – The external PBX can be either Analog or Digital PBX. This
usually interacts with both wired and wireless voice devices that might be
present in the network infrastructure
While deploying a wireless network when Polycom/Spectralink phones are used, we should
ensure that all Polycom/Spectralink specific parameters are precisely configured on the Meru
system. For more details on how to configure the Meru infrastructure for Polycom/Spectralink
voice solution, please refer to the Polycom/Spectralink Deployment Guide.
VOCERA
Vocera is one of the leading voice solution providers for enterprise class wireless products.
Vocera uses a unique voice recognition system to make and receive calls in the wireless
infrastructure. Vocera is a Meru partner WINSTM partner. There are specific components that
are used while deploying Vocera voice solutions in an enterprise WLAN.
• Vocera Server – This is software that can run on a Windows based system. They
control all the Vocera communication including establishing calls and
terminating them. They do follow some specific protocols and use specific ports
for their communication.
• Vocera Client Gateway – This is an optional component of the Vocera Solution.
This is software that is used when a Vocera Smartphone is deployed in the
network. This software can be installed in a Windows based system.
• Vocera SIP Telephony Gateway/Vocera Telephony Gateway – In order to make
calls outside of the network infrastructure, a Vocera SIP Telephony Gateway or a
Vocera Telephony Gateway is used. Vocera SIP Telephony Gateway is software
installed in a Windows based system and can communicate with the external
PBX. Vocera Telephony Gateway is a hardware that communicate with external
PBX.
• External PBX – The external PBX can be either Analog or Digital PBX. This
usually interacts with both wired and wireless voice devices that might be
present in the network infrastructure.
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 12
While deploying a wireless network, we should ensure that all Vocera specific parameters are
precisely configured on the Meru system. For more details on how to configure the Meru
infrastructure for Vocera voice solution, please refer to the Vocera Deployment Guide.
Voice solutions have become very important in the enterprise markets of today for effective
communication within and outside the enterprise. Wireless voice is gaining momentum and
plays a very important role in most wireless network solutions. By carefully planning and
deploying the Meru infrastructure, which is in one way tailored for wireless voice solution,
one can get to achieve toll quality, enterprise class Voice over IP deployment.
CONCLUSION
MERU BEST PRACTICES GUIDE | VOICE
BPG_Voice_V1.0 | Page 13