meru best practices guide - techhosteddocs.ittoolbox.com/meru_bpg_voice.pdf · · 2013-11-13this...

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


BPG_Voice_V1.0 |

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


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 |

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.


BPG_Voice_V1.0 |

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 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 |

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.


BPG_Voice_V1.0 |

• 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.


BPG_Voice_V1.0 |

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



26 - Assured Forwarding



46 - Expedited Forwarding




BPG_Voice_V1.0 |

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.


BPG_Voice_V1.0 |

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.


BPG_Voice_V1.0 |

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.


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.


BPG_Voice_V1.0 |

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.



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.



present in the network infrastructure.


BPG_Voice_V1.0 |

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


BPG_Voice_V1.0 |

meru best practices guide - techhosteddocs.ittoolbox.com/meru_bpg_voice.pdf · · 2013-11-13this...

Documents