Voice-Over IP Monitoring 4.6.0 Best Practices Deployment Guide · November 26, 2003 1 of 34 Voice-Over IP Monitoring 4.6.0 Best Practices Deployment Guide 1.0 Introduction This document

Voice-Over IP Monitoring 4.6.0Best Practices Deployment Guide

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706 USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

Customer Order Number: Text Part Number: NN-NNNN-NN

http://www.cisco.com

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCIP, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0203R)

Voice-Over IP Monitoring 4.6.0 Best Practices Deployment GuideCopyright © 2003, Cisco Systems, Inc.All rights reserved.

November 26, 2003

Table of Contents

1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.0 VoIP Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Desktop Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Server Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Monitoring Remote Agents and Supervisors. . . . . . . . . . . . 4

2.4 VoIP Monitoring Administration . . . . . . . . . . . . . . . . . . . . . . 5

2.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6 Monitoring Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.0 Best Practices Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Single Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Collapsed Core–One Logical Contact Center . . . . . . . . . 10

3.3 Multi-Tiered Complex Network . . . . . . . . . . . . . . . . . . . . . . 13

4.0 Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.0 VoIP Monitoring Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.1 Server Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2 Desktop Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.0 VoIP Monitor Service Deployment Strategies . . . . . . . . . . . . . 20

6.1 Voice VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2 IP Phone Switch Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.3 Voice Gateway and CallManager Ports . . . . . . . . . . . . . . . 20

7.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

App A SPAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

App B Switch Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.1 SPAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.2 RSPAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

B.3 Network Traffic Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 25

i

ii

B.4 Ingress and Egress Monitoring . . . . . . . . . . . . . . . . . . . . . 26

B.5 VSPAN Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

B.6 Number of SPAN Sessions . . . . . . . . . . . . . . . . . . . . . . . . 27

App C Using Multiple NICs with the VoIP Monitor Service . . . . . . . . . 29

C.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

C.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

C.3 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

C.4 Installing a Second NIC on a VoIP Monitor Service Computer 30

C.5 Installing Cisco Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

App D Example of a Simple Network Deployment . . . . . . . . . . . . . . . . 32

App E Example of a Collapsed Core Network Deployment . . . . . . . . 33

November 26, 2003

November 26, 2003

Voice-Over IP Monitoring 4.6.0 Best Practices Deployment Guide

1.0 Introduction

This document is intended to provide enough information about the abilities and requirements of voice-over IP (VoIP) monitoring v4.6.0 so that it can be effectively deployed.

This document contains the following information:

• An overview of VoIP monitoring and how this functionality is provided by Cisco Agent Desktop (CAD) software

• Descriptions of recommended deployments based on several typical net-work configurations, from simple to complex, which include references to features, issues, and limitations

• Detailed explanations of desktop and server monitoring features, issues, and limitations

• Descriptions of the deployment issues that need to be worked through to realize a successful deployment

• Reference information

• Examples of deployments using real switches to help you decide how desk-top and server monitoring should be deployed in your environment

1 of 34

VoIP Monitoring

2.0 VoIP Monitoring

In a VoIP environment, voice and data are transmitted over the network using well-known network protocols.

If you know which protocols are used to package a phone call’s data, it is pos-sible to capture (copy) those data packets as they traverse the network (often referred to as packet sniffing) and then unpackage and reassemble them into a voice stream that can be listened to in real time or stored to be listened to at a later time. This process is referred to as VoIP monitoring.

VoiP monitoring is invisible to the persons on the phone. Agents on calls are not aware that they are being monitored or recorded.

VoIP monitoring software looks only for Realtime Transport Protocol (RTP) packets. RTP is the protocol used to package and transmit voice over the net-work. RTP packets are encapsulated by the User Datagram Protocol (UDP), which in turn is encapsulated by the Ethernet protocol, which is encapsulated by the Internet Protocol (IP).

The VoIP monitoring software knows the Media Access Control (MAC) addresses of the IP phones it is monitoring/recording. It uses these MAC addresses to find the voice packets going to or coming from the appropriate device to determine whether or not to redirect the RTP packet to the receiver.

CAD software has two ways of monitoring IP phone calls:

• Desktop monitoring

• Server monitoring

You may use either method or both simultaneously. The method used is based upon your functional requirements and the network configuration.

The method used to monitor agents is configured in Cisco Desktop Administra-tor and stored in LDAP. When a supervisor requests a monitoring session for an agent, or a supervisor or agent request a recording session for a call, the software on their PCs reads the configuration information in LDAP to decide where to send the request. If the agent with the call is configured to use desk-top monitoring, the request is sent to the Desktop Monitor service on the agent’s PC. If the agent with the call is configured to use a VoIP Monitor ser-vice, the request is sent to that service.

In either case, the appropriate voice packets are sent back to the requestor (Cisco Supervisor Desktop for silent monitoring or the Recording and Statistics service for recording) which then decodes the voice packets to wav format.

2 of 34 November 26, 2003

VoIP Monitoring

For silent monitoring, the wav file is streamed to the supervisor’s PC sound card to be played over speakers or through headphones. For recording, the wav file is stored on disk.

2.1 Desktop Monitoring

In most environments, desktop monitoring is the easiest way to provide VoIP monitoring. With desktop monitoring, software on each agent’s desktop han-dles the recording and monitoring requests for that agent.

To use desktop monitoring, the agent must have either of the following setups:

• a PC running CAD and a Cisco IP phone (models 7910, 7940, or 7960), or

• a PC running CAD with Media Termination (the soft phone feature)

If the agent is using an IP phone, that IP phone is connected to the switch through one network connection on the back of the phone and to the agent’s PC through the other network connection on the back of the phone. The sec-ond network connection allows network traffic to be passed from the IP phone to the agent's PC, which enables the Desktop Monitor service to see voice traf-fic going to and from the agent’s IP phone. This traffic can then be copied and sent to the monitoring/recording requester.

A desktop-monitored agent’s PC must have a NIC card that fully supports NDIS Promiscuous mode. This mode allows the desktop monitoring software to see the voice packets on the network. A small number of NIC cards are not fully NDIS-compliant, and will prevent desktop monitoring from working.

IP phone agents (agents who do not use PCs) cannot use desktop monitoring. If VoIP monitoring is required for these agents, they must be configured to use server monitoring.

2.2 Server Monitoring

A CAD installation always includes one or more VoIP Monitor services, even if all agents are configured to use desktop monitoring. The installation requires a VoIP Monitor service in order to provide connectivity to the Cisco CallManager database for the desktop monitoring software.

The VoIP Monitor service also sniffs the network for voice packets, but it relies on the Switched Port Analyzer (SPAN) feature of the Cisco Catalyst line of switches to enable it to see the voice traffic for devices assigned to it.

SPAN allows one or more ports or VLANs to be designated as source ports and a single port to be designated as the destination port.

November 26, 2003 3 of 34

VoIP Monitoring

Source ports are any or all of the following:

• Ports used to connect IP phones to the switch

• Port used to connect the CallManager to the switch

• Port used by the voice gateway

• VLAN consisting of all the ports to be monitored by SPAN

The destination port is the port used to connect the VoIP Monitor service to the switch.

Once SPAN is properly configured, all network traffic traversing the source ports is copied and sent to the destination port. In this way, the VoIP Monitor service can see all the voice traffic to the IP phones and is able to capture voice streams from a particular agent's device for silent monitoring or recording.

Some Catalyst switches have the Remote SPAN (RSPAN) advanced feature, which enables the VoIP Monitor service connected to one switch to see the voice traffic of a port on another Catalyst switch.

2.2.1 VoIP Monitor Domains

A VoIP Monitor service is limited in the number of calls it can monitor simulta-neously. This is due to the speed of the server on which the service runs and on the speed of the network that delivers packets to it.

For a contact center that has more agents than can be monitored by a single VoIP Monitor service, additional VoIP Monitor services can be installed. Each of these services is referred to as a monitor domain, and represents a pool of monitoring resources that can be assigned to monitor particular IP phones. Each VoIP Monitor service requires its own SPAN configuration on the switch to which it is connected.

2.3 Monitoring Remote Agents and Supervisors

Remote agents and supervisors are connected to the contact center’s local network via a wide area network (WAN) or virtual private network (VPN).

2.3.1 Monitoring Via VoIP Monitor Service

The VoIP Monitor service can support remote agents and supervisors only if they are connected via a WAN with the necessary ports opened up in the WAN’s firewall.

There can be no routers between the remote agent’s or supervisor’s IP or soft phone and the VoIP Monitor service assigned to that device. Routers (including VPN concentrators used for VPN connectivity) change the MAC address of


VoIP Monitoring

packets routed through them. If a voice stream packet’s MAC address is changed, the VoIP monitoring service is unable to recognize the voice packets for a particular device.

Connection through a WAN can be as slow as 56 Kbps or as fast as 1.544 Mbps (T1 line). Even a T1 connection is much slower than the normal 100 Mbps connection of a PC connected to the network via a NIC card.

2.3.2 Monitoring Via Desktop Monitoring

Desktop monitoring fully supports remote agents using either WAN or VPN connectivity. This is possible because the desktop monitoring service runs on the agent’s PC. Once the traffic is captured by the desktop monitoring soft-ware, it no longer cares about the MAC address. The captured packets are sent to the object requesting the monitoring (the Recording and Statistics ser-vice or a supervisor) with no regard to routing devices.

CAVEAT Voice streams require a certain amount of network bandwidth. If several supervisors attempt to silently monitor or record a remote agent, the quality of the received speech may be low due to the lack of bandwidth between the agent and the supervisor.

Each monitoring request results in two voice streams (one for speech going to the agent and one for speech coming from the agent). This is in addition to the bandwidth of the actual phone call itself.

If voice packets cannot be sent out due to network congestion, the packets are dropped and will not be received by the supervisor request-ing the monitoring.

2.4 VoIP Monitoring Administration

By default, CAD is configured to use desktop monitoring after installation. How-ever, if there are IP phone agents in the contact center, they must be config-ured to be monitored using a VoIP Monitor service.

All properly installed and started VoIP Monitor services can be seen in Desktop Administrator. From there they can be assigned to monitor specific devices.

It is possible to enable desktop monitoring and also assign a VoIP Monitor ser-vice to a device. With this configuration, the VoIP Monitor service becomes a failover service that is used in the event that the desktop monitor is unable to monitor the agent’s device.


VoIP Monitoring

2.5 Scalability

Desktop monitoring is infinitely scalable. Each instance of CAD that is installed contains its own VoIP monitoring software.

Monitor domains provide scalability for VoIP Monitor services. The only limit to the number of VoIP Monitor services that can exist in a contact center’s system is the number of SPAN configurations that the Catalyst switches can support. Once that limit is reached, no more VoIP Monitor services can be added.

2.6 Monitoring Modes

Due to different SPAN configuration options, it is necessary to differentiate between caller-to-agent monitoring and agent-to-agent monitoring:

• Caller-to-agent monitoring is the ability to monitor a call between a single agent and a caller from outside the contact center (a customer).

• Agent-to-agent monitoring is the ability to monitor a call between two agents within the contact center.

NOTE A conference call consisting of an outside caller and multiple agents is treated as a caller-to-agent call, since the mixing of voice streams is per-formed by the Cisco CallManager and merged into a single stream.

These modes, and how to configure the system to support them, are shown in the deployment examples for the VoIP Monitor service (see Section 3.0 on page 8).

Desktop MonitoringIf desktop monitoring is used, both modes are automatically supported, since the desktop monitoring software captures the voice streams going to and com-ing from the agent’s IP phone.

Server MonitoringIf server monitoring is used, the ability to support a monitoring mode is based on the configuration of SPAN, the capabilities of the switch, and the location of the switches that contain the IP phone ports.

If you want to monitor only caller-to-agent calls, configure SPAN to copy both ingress and egress packets for all the source ports. The source ports include only the agent’s IP phones.

If, however, you also want to monitor agent-to-agent calls, SPAN must be con-figured to copy only ingress packets or egress packets from the port used by the agents’ IP phones. You then must also monitor the port used by the voice gateway to connect the contact center with the PSTN. If this is not done, then only one side of the conversation with an outside caller can be monitored (only


VoIP Monitoring

the customer side, if copying ingress packets, or the agent side, if copying egress packets).

In addition, the port used by the Cisco CallManager must be a source port, so that conference calls can be monitored.


Best Practices Deployments

3.0 Best Practices Deployments

The following sections describe best practices deployment strategies for VoIP monitoring, based on common network configurations.

3.1 Single Switch

In this network configuration (see Figure 1 on page 9), the CallManager, voice gateway, VoIP Monitor service, and all IP phones are connected to a single switch. There are a small number of agents. Data and voice are on separate VLANs.

See Appendix D on page 32 for an example of a simple configuration of this network layout using a Catalyst 3524 switch.

Option 1: Agent-to-Agent MonitoringEnable desktop monitoring on each agent’s desktop. You can use this configu-ration if the agents to be monitored/recorded:

• Use CAD with an IP phone

• Use CAD with Media Termination

Option 2: Agent-to-Agent MonitoringSPAN is configured on the switch to monitor the voice VLANs. It is configured to copy only ingress packets.

CAVEAT If your switch does not support VLAN monitoring (see Section B.5 on page 26), use Option 3.

Option 3: Agent-to-Agent MonitoringSet up SPAN to monitor each IP phone’s switch port, copying only ingress packets.

Option 4: Caller-to-Agent Monitoring OnlySet up SPAN to monitor the voice gateway and CallManager ports, copying both ingress and egress packets.

If your switch does not support monitoring ports on other VLANs, then the voice gateway, CallManager, and all IP phones must be on the same VLAN.



FIGURE 1. Single Switch Deployment



3.2 Collapsed Core–One Logical Contact Center

In this configuration (see Figure 2), Switch A comprises both the core and dis-tribution layers. Switches B, C, and D are access layer switches. All the agent IP phones are attached to Switches B and C. Only a supervisor is attached to Switch D.

Data and voice traffic is separated by data and voice VLANs. All agent IP phones are members of the voice VLAN.

The VoIP Monitor service can be attached to Switch A, B, or C. Where it is placed, and how many services are used, depends on:

• the functionality the customer wishes;

• the number of agents to be monitored; and

• the features available on the switches.

Refer to Appendix E for a configuration example of this network layout using a Catalyst 6000 switch as the core/distribution switch, and a Catalyst 3524 switch for the access layer switch.

Option 1: Agent-to-Agent Monitoring (Desktop Monitoring)Enable desktop monitoring on each agent’s desktop. You can use this configu-ration if the agents to be monitored/recorded:



Option 2: Agent-to-Agent Monitoring (1 VoIP Monitor Service, VLAN RSPAN)You can use this configuration if:

• There are 400 or fewer agents

• Switches B and C support VLAN RSPAN (see Section B.2 on page 24)

To Implement this configuration:

• Install a VoIP Monitor service on a PC that is directly connected to a switch that supports RSPAN.

• Configure an RSPAN destination port on that switch to monitor the agent voice VLANs on switches B and C, copying only ingress packets. The RSPAN destination port is the port to which the VoIP Monitor service is con-nected.

CAVEAT If your switches do not support RSPAN monitoring, you will not be able to use this configuration.

10 of 34 November 26, 2003


Option 3: Agent-to-Agent Monitoring (2 VoIP Monitor Services, VLAN SPAN)You can use this configuration if Switches B and C support VLAN SPAN.

On Switches B and C:

• Install a VoIP Monitor service on a PC that is directly connected to the switch.

• Configure SPAN to monitor the agent voice VLAN(s), copying only ingress packets. The SPAN destination port is the port to which the VoIP Monitor service is connected.

• Use Desktop Administrator to associate agent phones with the VoIP Monitor service. If you want to have a redundant system, enable desktop monitoring for each agent phone.

Option 4: Agent-to-Agent Monitoring (2 VoIP Monitor Services, Port SPAN)You can use this configuration if Switches B and C support Port SPAN.

On Switches B and C:


• Configure SPAN to monitor the agent IP phone ports, copying only ingress packets. The SPAN destination port is the port to which the VoIP Monitor service is connected.


Option 5: Caller-to-Agent Monitoring (1 VoIP Monitor Service, VLAN SPAN)You can use this configuration if Switches B and C support VLAN SPAN.

• Install a VoIP Monitor service on a PC that is directly connected to Switch A.

• Configure SPAN to monitor the agent voice VLANs, copying only ingress packets. The SPAN destination port is the port to which the VoIP Monitor is connected.

Option 6: Caller-to-Agent Monitoring (1 VoIP Monitor Service, Port SPAN)You can use this configuration if:

• Switch A supports Port SPAN.

• The voice gateways, CallManagers, and agent IP phones are in the same VLAN.

To implement this configuration:

• Install a VoIP Monitor service on a PC that is directly connected to Switch A.

November 26, 2003 11 of 34


• Configure SPAN to monitor the CAllManager and voice gateway ports, copying both ingress and egress packets. The SPAN destination port is the port to which the VoIP Monitor service is connected.

FIGURE 2. Collapsed Core (Single LCC)

12 of 34 November 26, 2003


3.3 Multi-Tiered Complex Network

In Figure 3, two redundant core switches are attached to two redundant distri-bution switches. These switches are, in turn, connected to two stacks of layer 2 switches at the access layer. The switches in the stacks are connected to each other through trunk ports.

This is a common configuration for Cisco networks. It is configured for redun-dancy, load balancing, or both.

With this configuration you have several choices on how to deploy the VoIP Monitor services, depending on the abilities of the various switches and whether the customer wishes to monitor only caller-to-agent calls or agent-to-agent calls as well.

Option 1: Agent-to-Agent Monitoring (Desktop Monitoring)Enable desktop monitoring on each agent’s desktop. You can use this configu-ration if the agents to be monitored/recorded:



Option 2: Agent-to-Agent Monitoring (1 VoIP Monitor Service, VLAN RSPAN)You can use this configuration if:


• Switches on stacks X and Y support RSPAN (see Section B.2 on page 24)

To implement this configuration:

• Install a VoIP Monitor service on a PC that is directly connected to a switch that supports RSPAN.

• Configure an RSPAN destination port on that switch to monitor the agent voice VLANs on all switches in stacks X and Y, copying only ingress pack-ets. The RSPAN destination port is the port to which the VoIP Monitor ser-vice is connected.

Option 3: Agent-to-Agent Monitoring (Multiple VoIP Monitor Services, VLAN SPAN)You can use this configuration if the switches on stacks X and Y support VLAN SPAN.

On each switch in stacks X and Y:


November 26, 2003 13 of 34


• Configure SPAN to monitor the agent voice VLANs, copying only ingress packets. The SPAN destination port is the port to which the VoIP Monitor service is connected.


Option 4: Agent-to-Agent Monitoring (n VoIP Monitor Services, Port SPAN)You can use this configuration if the switches on stacks X and Y support Port SPAN.

On each switch in stacks X and Y:


• Configure SPAN to monitor the agent IP phone ports, copying only ingress packets. The SPAN destination port is the port to which the VoIP Monitor service is connected.


Option 5: Caller-to-Agent Monitoring (1 VoIP Monitor Service, RSPAN)You can use this configuration if:


• Switches A and B support RSPAN

For the top switch in each stack:


• Configure SPAN to monitor the agent voice VLANs, copying only ingress packets. The SPAN destination port is the port to which the VoIP Monitor service is connected.


Option 7: Caller-to-Agent Monitoring (2 VoIP Monitor Services, Port SPAN)You can use this configuration is:

• Each stack has 400 or fewer agents

• The top switches in stacks X and Y support Port SPAN

14 of 34 November 26, 2003


For the top switch in each stack:


• Configure SPAN to monitor the agent IP phone ports and the trunk port to the next switch in the stack, copying both ingress and egress packets. The SPAN destination port is the port to which the VoIP Monitor service is con-nected.


FIGURE 3. Multi-Tiered Complex Network

November 26, 2003 15 of 34

Deployment Planning

4.0 Deployment Planning

You must make many decisions when planning for a VoIP Monitor service deployment. These decisions will dictate how many VoIP Monitor service instal-lations will be needed, where they will be deployed, and how the switches will be configured.

Table 1 summarizes the major decisions/features that must be taken into account when planning a deployment. These are expanded upon in Section 5.0.

TABLE 1. Decisions/Features for Consideration in Deployment Planning

Decision/Feature Importance

Number of Agents The VoIP Monitor service can support the phone traffic of 400 simultaneous calls. Loads greater than this cause performance degradation.

As a general equation, use

APT × N = X

where

APT = average peak talk time

N = number of agents

X ≤ 400

This is a simplified formula. Real-world planning is more complex and should use Erlang tables to calculate the number of VoIP Monitor services needed to support a given contact center.

VLANs Voice and data must be separated by using voice and data VLANs. This improves VoIP Monitor service capacity because it is not sniffing network traffic that is not related to calls. If the switch does not support VSPAN, or is con-strained to sniffing only a single VLAN, the placement of the VoIP Monitor service will be limited.

LCCs A single LCC can contain multiple VoIP monitor services (monitor domains). This implies multiple subnets and mul-tiple VLANs, which can all affect how the VoIP Monitor services are deployed.

Router Placement There can be no routers between the ports being moni-tored and the IP phones. Doing so causes the speech packet MAC addresses to be changed, becoming invisi-ble to the VoIP Monitor service.

Switch Capabilities Different Catalyst switches have differing SPAN and RSPAN capabilities. These capabilities (or lack thereof) dictate where the VoIP Monitor service can be deployed.

16 of 34 November 26, 2003

Deployment Planning

Monitoring Requirements Caller-to-agent call monitoring is generally less complex than agent-to-agent call monitoring. The requirements from the customer dictate where the VoIP Monitor service can be deployed.

Number of Supervisors The number of simultaneous monitoring sessions by supervisors must not exceed a ratio of one monitoring session per 10 agent calls. If the ratio needs to be higher, separate LCCs and VoIP Monitor services must be installed to handle the monitoring load.

TABLE 1. Decisions/Features for Consideration in Deployment Planning (Continued)

Decision/Feature Importance

November 26, 2003 17 of 34

VoIP Monitoring Assumptions

5.0 VoIP Monitoring Assumptions

5.1 Server Monitoring

5.1.1 VoIP Traffic Exposure

In order for monitoring and recording to function correctly, the VoIP Monitor service must be exposed to the IP traffic containing the RTP packets to be sniffed. This means the voice traffic must be presented to the VoIP Monitor ser-vice service’s network interface. This is done by setting up SPAN or RSPAN on the switches to which the agent phones are connected.

SPAN and RSPAN configurations specify one or more ports or VLANs on a switch as source ports and a single port as a destination port. The destination port is the port used by the machine running the VoIP Monitor service to con-nect to the switch.

The IP traffic coming over the source ports is copied and sent to the destination port. The VoIP Monitor service examines each packet to see if it should be cop-ied and sent to a supervisor for monitoring, or to the Recording & Statistics ser-vice for recording.

Ideally, the VoIP Monitor service only needs to sniff the packets that it is inter-ested in (voice packets). If voice VLANs are not used, or the switch only sup-ports port sniffing (see Section B.5 on page 26), then it is sniffing the IP phone port directly, and more extraneous network traffic is processed by the VoIP Monitor service. This decreases the capacity of the service.

5.1.2 Layer 2 Switching Domains

VoIP traffic is sniffed and copied using the designated IP phone MAC address. As a result, there can be no layer 3 routing performed on the VoIP packets because that changes the MAC address of the Ethernet frames.

There can be no routers between the agent IP phones that are being moni-tored/recorded and the ports being sniffed (exposed via SPAN and RSPAN).

5.1.3 Single Copy of VoIP Packets

When configuring SPAN and RSPAN on the switch(es), it is important to verify that only a single copy of a VoIP packet is sent to the VoIP Monitor service.

If SPAN is set up to monitor two agent ports, and those agents are on a call with each other, the voice packets exchanged between the two IP phones can be sent to the VoIP Monitor service twice—once when it leaves Agent A’s phone, and again when it is received by Agent B’s phone.

18 of 34 November 26, 2003

VoIP Monitoring Assumptions

For most Catalyst switches, the SPAN can be configured to copy only ingress or egress packets. If agent-to-agent calls are to be monitored, the SPAN/RSPAN must be configured to copy either ingress or egress packets, but not both.

For switches that do not support this feature (see Section B.4 on page 26), agent-to-agent call monitoring is not possible.

5.1.4 IP Phone Compatibility

The VoIP Monitor service works with the Cisco 7910, 7940, and 7960 IP phones and the CAD soft phone.

5.1.5 Voice Encoding Protocols

The VoIP Monitor service supports the voice encoding protocols G.711 and G.729 (with and without silence suppression). Other encoding schemes are not recognized by the monitoring software.

5.2 Desktop Monitoring

5.2.1 Remote Agent Bandwidth Considerations

Even if a remote agent is accessing the Concentric services with a fast T1 line, no more than two simultaneous monitoring/recording sessions can be sup-ported for the same agent due to bandwidth limitations.

5.2.2 IP Phone Compatibility

The Desktop Monitoring service works with the CIsco 7910, 7940, and 7960 IP phones and the CAD soft phone.

5.2.3 Voice Encoding Protocols

The Desktop Monitoring service supports the voice encoding protocols G.711 and G.729 (with and without silence suppression). Other encoding schemes are not recognized by the monitoring software.

November 26, 2003 19 of 34

VoIP Monitor Service Deployment Strategies

6.0 VoIP Monitor Service Deployment Strategies

This section describes, in general terms, the different sniffing configurations that can be used in successful VoIP Monitor service installations. The primary goal of these scenarios is to limit the amount of network traffic the VoIP Monitor service must sniff in order to serve the needs of the customer.

Sniffing excessive network traffic incurs loads on the VoIP Monitor service machine, the switch(es), and the network. Using the correct sniffing strategies that match the customer’s needs allows the system to work most efficiently. Using an invalid sniffing scenario negatively affects the VoIP Monitor service and the system as well.

VoIP sniffing can be done at several locations in the system:

• Voice VLANs

• IP Phone/CAD switch ports

• Voice gateway and CallManager ports

In this context, sniffing means to set up a SPAN or RSPAN to monitor one or more ports and/or VLANs. The sources used by the SPAN each have issues that affect VoIP monitoring, and need to be understood.

6.1 Voice VLANs

Sniffing voice VLANs is the preferred sniffing method for two primary reasons:

• Voice and data network traffic are separated

• SPAN configuration and maintenance are easier

It is strongly recommended that voice and data network traffic be separated by VLANs, and that the VoIP Monitor service sniffs only the voice VLAN. The less network traffic the VoIP Monitor service needs to process, the more capacity it has.

6.2 IP Phone Switch Ports

If VLANs or VSPAN are not supported on the switch, SPAN must use individual ports as source ports rather than a VLAN. This is less desirable than VLAN sniffing because the VoIP Monitor service is exposed to both voice and data traffic. This additional traffic reduces the capacity of the service.

6.3 Voice Gateway and CallManager Ports

If agent-to-agent call monitoring/recording is not required, it is possible to set up SPAN to monitor only the voice gateway port(s) and the CallManager port.

20 of 34 November 26, 2003

VoIP Monitor Service Deployment Strategies

This allows the VoIP Monitor service to see all the voice packets that are exchanged in a call between an outside caller and the agent.

Agent-to-agent calls cannot be monitored because the voice packets will not traverse the voice gateway port. An exception to this is if the agent is speaking to an outside caller and then conferences in another agent. In this case, the merging of the voice streams is handled by CallManager. Because the VoIP Monitor service is monitoring the CallManager port, this three (or more)-way call can be monitored successfully.

November 26, 2003 21 of 34

References

7.0 References

1. Catalyst 1200 Installation and Configuration Guide, Chapter 3, “Feature Configuration”

2. Catalyst 2900 Series XL and Catalyst 3500 Series XL Software Configura-tion Guide, Cisco IOS Releases 12.0(5)WC4 and 12.0(5)WC5, May 2002

3. Catalyst 2950 Desktop Switch Software Configuration Guide, Chapter 20, “Configuring SPAN”

4. Catalyst 3550 Multilayer Switch Software Configuration Guide, Chapter 22, “Configuring SPAN”

5. Software Configuration Guide—Catalyst 4000 Family, Catalyst 2948G, Catalyst 2980G, Chapter 25, “Configuring SPAN and RSPAN”

6. Catalyst 4224 Access Gateway Switch Software Configuration Guide, April 2002

7. Catalyst 5000 Family Software Configuration Guide, Chapter 27, “Config-uring SPAN”

8. Catalyst 6000 Family Software Configuration Guide, Release 7.2

9. Cisco IOS Switching Services Configuration Guide

10. Catalyst 1900 Series Software Configuration Guide, Chapter 3, “Configur-ing and Monitoring from the Switch Manager”

11. Catalyst 2820 Series Software Configuration Guide, Chapter 3, “Configur-ing and Monitoring from the Switch Manager”

12. Catalyst 2900 Series XL and Catalyst 3500 Series XL Command Refer-ence

13. Catalyst 3000 Installation and Configuration Guide, Chapter 9, “Monitoring Port Activity with Application Software”

14. Catalyst 3200 Installation and Configuration Guide, Chapter 9, “Monitoring Port Activity with Application Software”

15. Configuring Catalyst 3500 XL Switches for AVVID/IP Telephony, Applica-tion note

22 of 34 November 26, 2003

References

Appendix A SPAN Overview

The VoIP Monitor service relies on a SPAN (Switched Port ANalyzer) session configured on the Catalyst switch. A SPAN session is a feature of the Cisco Catalyst switches that allows one or more port’s IP traffic to be copied and sent to another single destination port on the switch.

The ports that are used for the input to a SPAN are referred to as source ports. The port where all the copied traffic is sent is called the destination port.

NOTE On some switches, the SPAN destination port is referred to as the monitor port. In this document this port will always be referred to as the destination port.

Think of SPAN as a funnel that collects network traffic from multiple ports and copies it to a single output port. The destination port of a SPAN is used by the VoIP Monitor service to sniff for voice traffic to and from agent phones.

Depending on the switch model, the source ports used by SPAN can be ports or VLANs. Only certain types of ports can be used as source ports.

Using switch ports as source ports is referred to as PSPAN (Port SPAN). Using VLANs as source ports are referred to as VSPAN (VLAN SPAN). Some switches support only PSPANs. Other switches support both PSPANs and VSPANs. Some switches support the use of both ports and VLANS in a single SPAN configuration.

Local SPANs (LSPANs) are SPANs where all the source ports and the destina-tion port are physically located on the same switch. Remote SPANs (RSPANs) can include source ports that are physically located on another attached switch.

The number of SPANs that can be configured can vary by switch. SPAN con-figuration and functionality is not the same on all Cisco Catalyst switches.

Some switches can have the SPAN destination port configured to only show packets that are incoming to the source port(s) (ingress traffic) or only packets that are outgoing to the source port(s) (egress traffic). The default for many switches is to show both ingress and egress packets hitting the source port(s).

On some Catalyst switches, the destination port of a SPAN will not accept reg-ular network traffic. In these cases, the machine running the VoIP Monitor ser-vice must have two NIC cards; one to send and receive normal network traffic, and another to receive voice traffic from the switch.

For more information on SPAN and RSPAN, refer to your switch documenta-tion.

November 26, 2003 23 of 34

References

Appendix B Switch Capabilities

The VoIP Monitor service is targeted specifically for the Cisco line of Catalyst switches. It may work with other switches that offer VoIP traffic, but it has not been tested on other switches at this time.

There are differences among the Cisco Catalyst switches that you need to be aware of when installing and configuring the VoIP Monitor service software. The switch issues that are known at this time are shown in the tables below.

B.1 SPAN Support

For certain switches, the ability to set up SPAN, or something similar in func-tionality, does not exist. In these cases, the VoIP Monitor service will not work because there is no method for giving the monitor software access to the voice traffic.

The following Catalyst switches do not support SPAN:

• 1700

• 2100

• 2800

• 2948G-L3

• 4840G

B.2 RSPAN Support

In some cases, it is desirable to use RSPAN in a VoIP Monitor service deploy-ment. Not all switches support RSPAN.

In some cases, a switch may not support RSPAN, but may be an intermediate switch within an RSPAN configuration.

The following Catalyst switches do not support RSPAN:

• 1200

• 1900

• 2820

• 2900

• 2900XL

• 2926GS

• 2926F

• 2926T

24 of 34 November 26, 2003

References

• 2948G

• 2950

• 2980G

• 3000

• 3100

• 3200

• 3500XL

• 3524-PWR XL

• 3508GL XL

• 3550

• 5000

• 5002

• 5500

• 5505

• 5509

B.3 Network Traffic Restrictions

Some Catalyst switches do not allow the destination port of a SPAN configura-tion to act as a normal network connection. The only traffic that flows through this port is the traffic copied from the SPAN source ports.

This means that the computer running the VoIP Monitor service must have two network connections to function properly. It needs one NIC to receive monitor and record requests and to interact with the other components of the CAD software, which reside on other machines within the network. The second NIC is dedicated to sniffing VoIP traffic for monitoring and recording.

The following Catalyst switches do not support normal network traffic on SPAN destination ports:

• 2950

• 3000

• 3100

• 3200

• 3550

November 26, 2003 25 of 34

References

The actions required to configure the system to use multiple NIC cards are shown in Appendix C.

B.4 Ingress and Egress Monitoring

In some configurations, the VoIP Monitor service can receive duplicate voice packets. This can potentially happen with many Cisco Catalyst switches. The problem occurs in agent-to-agent calls when SPAN/RSPAN is configured to sniff both ingress and egress packets from both parties on the call.

As a voice packet leaves Agent A’s port, SPAN copies it to the VoIP Monitor service port. When the voice packet arrives at Agent B’s port, it is copied again and sent to the VoIP service. The same happens when Agent B speaks. All packets are seen twice by the VoIP Monitor service. This causes poor speech quality.

To avoid this, only ingress packets to a port are sent to the VoIP Monitor ser-vice. This is a setting for SPAN. Some switches do not support this setting.

The following Catalyst switches do not support ingress-only packet sniffing:

• 1900

• 2820

• 2900

• 2900XL

• 3000

• 3100

• 3200

• 3500XL

B.5 VSPAN Support

In some switches, SPAN cannot use VLANs as sources. In that case, SPAN must designate individual ports to use for monitoring.

The following Catalyst switches do not support VSPAN:

• 1200

• 1900

• 2820

• 2900XL

• 2950

26 of 34 November 26, 2003

References

• 3000

• 3100

• 3200

• 3500XL

• 3524-PWR XL

B.6 Number of SPAN Sessions

There are limits to the number of SPAN/RSPAN sessions that can exist on a switch.

TABLE 2. SPAN Session Limits for Catalyst Switches

Switch Model Maximum SPAN Sessions Allowed

1200 1

1900 1

2820 1

2900 1

2900XL 1

2926GS 5

2926GL 5

2926T 5

2926F 5

2948G 5

2950 1

2980G 5

3000 1

3100 1

3200 1

3500XL 1

3524-PWR XL 1

3508GL XL 1

3550 2

4003 5

4006 5

November 26, 2003 27 of 34

References

2912G 5

5000 5

5002 5

5500 5

5505 5

5509 5

6006 30

6009 30

6506 30

6509 30

6513 30

TABLE 2. SPAN Session Limits for Catalyst Switches (Continued)

Switch Model Maximum SPAN Sessions Allowed

28 of 34 November 26, 2003

References

Appendix C Using Multiple NICs with the VoIP Monitor Service

C.1 Overview

The VoIP Monitor service sniffs RTP traffic from the network and sends it to registered clients. This requires support from the switch to which the service is connected.

The VoIP Monitor service must be connected to the destination port of a config-ured SPAN/RSPAN. Any traffic that crosses the SPAN/RSPAN source ports is copied to the SPAN/RSPAN destination port and consequently is seen by the VoIP Monitor service.

Not all Catalyst switches allow the VoIP Monitor service to use the SPAN port for both receiving and sending traffic. There are switches that do not allow nor-mal network traffic on a SPAN destination port. A solution to this problem is to use two NICs in the machine running the VoIP Monitor service:

• One NIC for sniffing the RTP streams, connected to the SPAN port

• One NIC for sending/receiving normal traffic, such as requests from clients and sniffed RTP streams, connected to a normal switch port not monitored by the above-mentioned SPAN port.

C.2 Limitations

Since Cisco CallManager does not support two NICs, using multiple NICs works only in configurations where CallManager is not co-resident with the VoIP Monitor service.

SplkPCap 3.0, the packet sniffing library, works only with NICs that are bound to TCP/IP. Make sure the sniffing card is bound to TCP/IP.

C.3 Issues

The VoIP Monitor service does not specify which NIC should be used when sending out packets. This is not a problem when using a single NIC for both sniffing and normal traffic. With two NICs, however, normal traffic should be restricted so that it does not go through the NIC used for sniffing. Otherwise, the sniffed RTP streams of a currently-monitored call might not reach the super-visor because the SPAN destination port does not allow outgoing traffic.

To resolve this, use the route command to customize the static routing table so that normal traffic does not go through the sniffing NIC. Contact your network administrator for details.

November 26, 2003 29 of 34

References

An alternative solution is to give the sniffing NIC an IP address that no other host on the network uses, and a subnet mask of “255.255.255.0”. Leave the default gateway field blank for this NIC’s TCP/IP binding.

C.4 Installing a Second NIC on a VoIP Monitor Service Computer

This procedure applies only to computers running Windows 2000.

1. Install the second NIC in the computer.

2. Start the computer.

3. Make sure that neither adapter is using DHCP to get its IP address.

4. Give the adapters valid IP addresses.

5. Determine which of the two adapters is to be used for sniffing.

6. Connect the sniffing adapter with the switch SPAN port.

7. Connect the second adapter with a normal switch port that is not monitored by the SPAN port.

8. Use the route command to customize the local routing table so that normal traffic does not go through the sniffing adapter.

9. Verify that the sniffing adapter is not registered with DNS and WINS by using the PING <local host name> command. This ensures that the local name always resolves to the normal traffic card IP address.

C.5 Installing Cisco Desktop

If a second NIC card is present before installing Cisco DesktopIf the computer on which you are installing the VoIP Monitor service has two NICs before you install the service, follow these steps:

1. During the VoIP Monitor service installation, enter the normal traffic adapter’s IP address when prompted for the machine IP address.

2. Enter the sniffing adapter’s IP address when prompted for the VoIP Monitor Service.

If a second NIC card is installed after installing Cisco DesktopIf the computer on which you installed the VoIP Monitor service is upgraded to include a second NIC, follow these steps:

1. Open the registry and access the following key:

HKey Local Machine\Software\Microsoft\WindowsNT\CurrentVersion\Net-workCards

2. Find the newly-inserted card entry.

3. Copy the value in the ServiceName key.

30 of 34 November 26, 2003

References

4. Paste this value to the following key:

HKey Local Machine\Software\Spanlink\FastCall VoIP Monitor Server\Setup\MonitorDevice

5. Add \Device\Splkpc_ at the beginning of the string you pasted in the key. Be sure to use the correct case when typing this string—it is case sensitive.

NOTE An alternative to following this procedure is to use the Sniffing Adapter Update utility (UpdateSnifferNIC.exe) that is included on the CAD installation CD. See “Test Programs” in the Cisco Desktop Prod-uct Suite 4.6.0 Service Information Manual for more information.

November 26, 2003 31 of 34

References

Appendix D Example of a Simple Network Deployment

FIGURE 4. Example of a Simple Network Deployment

To create a SPAN session on the switch:Assumptions:

• The switch ports are configured as shown in Figure 4

• The voice VLAN used by the IP phones is VLAN 1

1. On the switch, type the command config t to enter configuration mode.

2. Type the command interface 0/3 to enter configuration mode for Ethernet port 0/3.

3. Type the command port monitor vlan 1 to set up SPAN to monitor voice VLAN 1.The VoIP Monitor service now sees all the voice traffic from the IP phones connected to the switch. Both caller-to-agent and agent-to-agent calls can be monitored and recorded.

32 of 34 November 26, 2003

References

Appendix E Example of a Collapsed Core Network Deployment

FIGURE 5. Example of a Collapsed Core Network Deployment

To create a SPAN session on Switch B:Assumptions:

• The switch ports are configured as shown in Figure 4

• The voice VLAN used by the IP phones on both switches is VLAN 1

1. On Switch B, type the command config t to enter configuration mode.

2. Type the command interface 0/1 to enter configuration mode for Ethernet port 0/1.

3. Type the command port monitor vlan 1 to set up SPAN to monitor voice VLAN 1.

4. Repeat Steps 1–3 for Switch C.The VoIP Monitor service now sees all the voice traffic from the IP phones connected to the switch. Both caller-to-agent and agent-to-agent calls can be monitored and recorded.

November 26, 2003 33 of 34

References

34 of 34 November 26, 2003

Documents

Voice-Over IP Monitoring 4.6.0 Best Practices Deployment Guide · November 26, 2003 1 of 34 Voice-Over IP Monitoring 4.6.0 Best Practices Deployment Guide 1.0 Introduction This document