A A A A ACTIV! IP - CHANNEL MANA CTIV! IP - CHANNEL MANA CTIV! IP - CHANNEL MANA CTIV! IP - CHANNEL MANA CTIV! IP - CHANNEL MANAGER GER GER GER GER CONFIGUR CONFIGUR CONFIGUR CONFIGUR CONFIGURA A A A ATION GUIDE TION GUIDE TION GUIDE TION GUIDE TION GUIDE

chickpeasulotrichousNetworking and Communications

Oct 27, 2013 (3 years and 9 months ago)

248 views

1
Activ! IP - Channel Manager (rev D)
VPI • 160 Camino Ruiz, Camarillo, CA 93012-6700
(Voice) 800-200-5430 • 805-389-5200 • (Fax) 805-389-5202
www.vpi-corp.com
AA
AA
A
CTIV! IP - CHANNEL MANACTIV! IP - CHANNEL MANA
CTIV! IP - CHANNEL MANACTIV! IP - CHANNEL MANA
CTIV! IP - CHANNEL MANA
GERGER
GERGER
GER
CONFIGURCONFIGUR
CONFIGURCONFIGUR
CONFIGUR
AA
AA
A
TION GUIDETION GUIDE
TION GUIDETION GUIDE
TION GUIDE
2
Activ! IP - Channel Manager (rev D)
TOC
Contents
Introduction ------------------------------------------------------------------------------------------------------------------------------------ 4
Activ! IP Recording Solution Highlights...............................................................................................................4
Terminology ------------------------------------------------------------------------------------------------------------------------------------ 5
AudioCodes and SMARTWORKS® API’s..........................................................................................................5
CMAPI ------------------------------------------------------------------------------------------------------------------------------------- 5
Gateway ---------------------------------------------------------------------------------------------------------------------------------- 5
Jitter ---------------------------------------------------------------------------------------------------------------------------------------- 5
Packet ------------------------------------------------------------------------------------------------------------------------------------- 5
Packet Sniffer ---------------------------------------------------------------------------------------------------------------------------- 5
Port Mirroring ---------------------------------------------------------------------------------------------------------------------------- 6
RTP ---------------------------------------------------------------------------------------------------------------------------------------- 6
SIP (Session Initiation Protocol) ----------------------------------------------------------------------------------------------------- 6
SPAN Port -------------------------------------------------------------------------------------------------------------------------------- 6
Brief Description of SPAN------------------------------------------------------------------------------------------------------------- 7
Switch and Port Monitoring ----------------------------------------------------------------------------------------------------------- 7
Tap Environment ------------------------------------------------------------------------------------------------------------------------- 7
TCP ---------------------------------------------------------------------------------------------------------------------------------------- 7
TDM (Time Division Multiplexing) ---------------------------------------------------------------------------------------------------- 8
UDP---------------------------------------------------------------------------------------------------------------------------------------- 8
Upstream/Downstream Traffic -------------------------------------------------------------------------------------------------------- 8
Virtual LAN ------------------------------------------------------------------------------------------------------------------------------- 8
VoIP---------------------------------------------------------------------------------------------------------------------------------------- 9
VoIP Phone------------------------------------------------------------------------------------------------------------------------------- 9
Hardware Overview --------------------------------------------------------------------------------------------------------------------------10
SmartWORKS® IPX (Event Monitor) ----------------------------------------------------------------------------------------------10
Example of Incoming Traffic ---------------------------------------------------------------------------------------------------- 11
Decoding Logic-------------------------------------------------------------------------------------------------------------------- 11
D-Channel Events ----------------------------------------------------------------------------------------------------------------12
PBX Command Events ----------------------------------------------------------------------------------------------------------12
Phone Action Events-------------------------------------------------------------------------------------------------------------12
Software Configuration (VPConfig) VoIP Channel Manager.....................................................................................13
Operational Overview ------------------------------------------------------------------------------------------------------------------ 13
SPAN Overview-------------------------------------------------------------------------------------------------------------------------13
SPAN Tap Point Options -------------------------------------------------------------------------------------------------------------14
IPX Setup: VPConfig > Channel Manager > IPX (Tab) > Settings (Tab)............................................................15
IPX Setup---------------------------------------------------------------------------------------------------------------------------15
Ignore Extensions/IP-------------------------------------------------------------------------------------------------------------17
Record Extensions/IPs ----------------------------------------------------------------------------------------------------------17
Called and Calling Party Transformations..................................................................................................17
Party Transformation - Cisco Wildcards....................................................................................................19
Apply/Cancel Buttons -----------------------------------------------------------------------------------------------------------20
IPX Setup: VPConfig > Channel Manager > IPX (Tab) > Boards (Tab)..............................................................21
IPX Boards -------------------------------------------------------------------------------------------------------------------------21
Signaling Protocols --------------------------------------------------------------------------------------------------------------21
Board Protocol (i.e., Cisco®) -------------------------------------------------------------------------------------------------- 25
Apply/Cancel Buttons -----------------------------------------------------------------------------------------------------------25
3
Activ! IP - Channel Manager (rev D)
© Copyright 2007 VPI, Inc.
The information contained herein is subject to change without notice.
As the registered end user, you are free to make and use as many
copies of this manual as you like, so long as it is used for internal
purposes only and is not transmitted in any manner whatsoever to any
individual, organization or corporate entity not specifically named in
your End User License Agreement.
VPI shall not be liable for technical or editorial errors or omissions
contained herein.
VPConfig > Channel Manager > Database (Tab)..............................................................................................26
Database Mappings --------------------------------------------------------------------------------------------------------------26
Database Field --------------------------------------------------------------------------------------------------------------------27
Apply/Cancel Buttons -----------------------------------------------------------------------------------------------------------27
VPConfig > Channel Manager > Software RTP (Tab)........................................................................................28
RTP Setup -------------------------------------------------------------------------------------------------------------------------28
Destination IP Address ----------------------------------------------------------------------------------------------------------28
Time Intervals ----------------------------------------------------------------------------------------------------------------------29
Ports---------------------------------------------------------------------------------------------------------------------------------29
RTP Codec -------------------------------------------------------------------------------------------------------------------------29
Apply/Cancel Buttons -----------------------------------------------------------------------------------------------------------29
Skinny Protocol Database Fields--------------------------------------------------------------------------------------------------------30
Cisco® Skinny Redirect Reasons -------------------------------------------------------------------------------------------------------31
Cisco® Specific Features Supported ---------------------------------------------------------------------------------------------------32
Activ! IP Known Technical Limitations --------------------------------------------------------------------------------------------------37
Index -------------------------------------------------------------------------------------------------------------------------------------------39
Revision History -----------------------------------------------------------------------------------------------------------------------------41
TOC
4
Activ! IP - Channel Manager (rev D)
Introduction
Activ! IP’s recording solutions are compatible and integrate with industry leading VoIP Telephony platforms which
include Cisco
®
Systems, Avaya
®
IP/Office IP, Nortel
®
Meridian 1 and the BCM
®
IP PBX, Ericson
®
, Siemens
®
, Alcatel
®
,
Asterisk
®
and SIP . Through collaboration with major Voice Over IP telephony solution developers, VPI ensures that its
clients are able to effectively leverage VoIP recording solutions to capture, evaluate, analyze and improve multimedia
interactions over converging networks, supporting transition from legacy PBX systems to the new ROI boosting Voice
Over IP telephony-based solutions.
Activ! IP Recording Solution Highlights
• Ready migration path to Voice Over IP telephony to gain total cost of ownership savings due to less expensive
calling rates
• Combine VoIP and circuit-switched telephony networks, preserving your organization’s investment in traditional
ACDs/PBXs
• Integration with VPI’s Activ! Suite of products for customer experience management, including Activ! View
Desktop Screen Capture and Activ! IQ Call Center Quality Monitoring technologies
• Activ! IP supports G.711and G.729a codecs.
• The combined solution delivers special features to include:
• Keep/delete calls as they are recorded
• Combine on-demand start and stop VoIP recording with Activ IP’s full-time IP Recorder
• Custom applications
• Completely D-Channel event driven solution that requires no third party software and/or connection to the PBX
in order to work. The communication between the PBX and the phone provide the start and stop events for each
phone. Activ IP uses and captures all possible data provided in this data stream. Some PBX’s provide more
data than others.
• Hybrid System-Activ! IP will support both analog VOX recording and D-channel driven VoIP recording in one
system.
• Easily upgrade existing systems with VoIP recording channels.
Introduction
5
Activ! IP - Channel Manager (rev D)
Terminology
This section explains the pertinent terms relating to Activ! IP’s capturing and recording capabilities in the VoIP environment
(in alphabetical order).
AudioCodes and SMARTWORKS
®
API’s
AudioCodes and SmartWorks API’s (Application Program Interfaces) provide the set of routines, protocols, and
tools for building software applications to communicate with Activ! IP and AudioCodes recording solution products.
CMAPI
Avaya CMAPI (Communication Manager Application Program Interface).
Gateway
A gateway is either hardware or software that acts as a bridge between two networks so that data can be
transferred between a number of computers. For example, when you send an e-mail or when you log into a Web
site, there is a gateway that allows the connection to take place. Often, your connection to a Web site will involve
many smaller connections to other servers along the way. In these cases, a number of gateways are used.
Jitter
In voice over IP (VoIP), jitter is the variation in the time between packets arriving, caused by network congestion,
timing drift, or route changes. A jitter buffer can be used to handle jitter.
Packet
A packet is a formatted block of information carried by a computer network. Computer communications links that
do not support packets, such as traditional point-to-point telecommunications links, simply transmit data as a
series of bytes, characters, or bits alone. When data is formatted into a packet, the network can transmit longer
messages more efficiently and reliably.
Packet Sniffer
A Packet sniffer (also known as network or protocol analyzer or Ethernet sniffer) is computer software (usually) or
computer hardware that can intercept and log traffic passing over a digital network or part of a network. As data
streams travel back and forth over the network, the sniffer captures each packet and eventually decodes and
analyzes its content according to the appropriate RFC (Request for Comments) or other specifications. Depending
on the network structure (hub or switch) one can sniff all or just parts of the traffic narrowing by switches to gain
access to traffic from other systems on the network (i.e., ARP spoofing). For network monitoring purposes it may
also be desirable to monitor all data packets in a LAN by using a network switch with a so-called monitoring port,
whose purpose is to mirror all packets passing through all ports of the switch.
Terminology
6
Activ! IP - Channel Manager (rev D)
Port Mirroring
Port mirroring is used on a network switch to send a copy of all network packets seen on one switch port to a
network monitoring connection on another switch port. This is commonly used for network appliances that
require monitoring of network traffic, such as an intrusion-detection system. Port mirroring on a Cisco Systems
switch is generally referred to as Switched Port Analyzer (SPAN).
RTP
RTP (Real Time Protocol) is a packet based communication protocol that adds timing and sequence information
to each packet to allow the reassembly of packets to reproduce real time audio and video information. RTP is a
transport used in IP audio and video environments.
SIP (Session Initiation Protocol)
A protocol designed to initiate, maintain and terminate a session involving multimedia streams such as voice,
data and video. All SIP messages are either a request or a response to a request.
SPAN Port
Another method to monitor networks is to use port mirroring is called "SPAN" (Switched Port Analyzer) by Cisco,
and given other names by some other vendors on routers and switches (i.e., PSPAN, VSPAN, LSPAN) for more
information refer to the “SPAN Overview” section on page 15. This is a low-cost alternative to network taps, and
solves many of the same problems.
Terminology
7
Activ! IP - Channel Manager (rev D)
Brief Description of SPAN:
What is SPAN and why is it needed? The SPAN feature was introduced on switches because of a fundamental
difference that switches have with hubs. When a hub receives a packet on one port, the hub sends out a
copy of that packet on all ports except on the one where the hub received the packet. After a switch boots,
it starts to build up a Layer 2 forwarding table on the basis of the source MAC address of the different
packets that the switch receives. After this forwarding table is built, the switch forwards traffic that is
destined for a MAC address directly to the corresponding port.
In the above diagram, the sniffer is attached to a port that is configured to receive a copy of every packet
that host A sends. This port is called a SPAN port.
Switch and Port Monitoring
Switch is a network exchange facility operating at the data link layer (layer 2) and sometimes the network layer
(layer 3) of the OSI Reference Model.
Unlike hubs, switches prevent promiscuous sniffing. When a data packet is transmitted in non-promiscuous
mode, all the LAN devices "listen to" the data to determine if the network address included in the data packet is
theirs. If it isn't, the data packet is passed onto the next LAN device until the device with the correct network
address is reached. That device then receives and reads the data.
However, most modern switches (management switches) support "port mirroring", which is a feature that allows
you to configure the switch to redirect the traffic that occurs on some or all ports to a designated monitoring port
on the switch. With this feature, you can monitor the entire LAN segment in switched network environment.
Tap Environment
For IP call recording applications, active interfaces can be connected directly to an available mirror port or can be
connected passively anywhere within the IP-PBX configuration.
TCP
Abbreviation of Transmission Control Protocol, and pronounced as separate letters. TCP is one of the main
protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to
establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that
packets will be delivered in the same order in which they were sent.
Terminology
8
Activ! IP - Channel Manager (rev D)
TDM (Time Division Multiplexing)
The means by which many different signals can be carried on the same transmission path by interleaving these
portions of signals over time. This means that circuit switched networks can be used more efficiently. This
technology is used on traditional networks such as the PSTN and GSM mobile networks. The main difference to
packet switching is that the time slots are pre-allocated to the channels rather than being allocated on a per-time
slot basis.
UDP
Abbreviation for User Datagram Protocol, a connectionless protocol that, like TCP, runs on top of IP networks.
Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive
datagrams over an IP network. It's used primarily for broadcasting messages over a network.
Upstream/Downstream Traffic
Upstream network traffic flows away from the local computer toward the remote destination. Conversely, downstream
traffic flows to the user's computer. Traffic on most networks flows in both upstream and downstream directions
simultaneously, and often when data flows in one direction, network protocols often send control instructions
(generally invisible to the user) in the opposite direction.
One way to generate upstream traffic is to upload files to a server or send an email message. Conversely,
downloading files and receiving email generate downstream traffic. Typical Internet users create much more
downstream than upstream traffic.
Examples: The Web browser sends HTTP requests upstream to the Web server, and the server replies with
downstream data usually in the form of HTML pages.
• Ingress (RX) - Packets/Frames entering the device or network being described. In data/center or
server centric discussions sometimes referred to as client side or client traffic. That is traffic
transmitted by the client and received by the data center.
• Egress (TX) - Packets/Frames leaving the local device or network. In data/center or server centric
discussion it is traffic transmitted by the device or network and received by the client.
Virtual LAN
A virtual LAN, commonly known as a vLAN or as a VLAN, is a method of creating independent logical networks
within a physical network. Several VLANs can co exist within such a network. This helps in reducing the broadcast
domain. A VLAN consists of a network of computers that behave as if connected to the same wire - even though
they may actually be physically connected to different segments of a LAN. Network administrators configure
VLANs through software rather than hardware, which makes them extremely flexible. One of the biggest advantages
of VLANs emerges when physically moving a computer to another location: it can stay on the same VLAN
without the need for any hardware reconfiguration.
Terminology
9
Activ! IP - Channel Manager (rev D)
For Activ! IP the voice traffic is isolated onto a separate VLAN on each of the ports that are connected to a phone.
The switch port that is configured for connecting a phone would have separate VLANs that are configured for
carrying the following:
• Data traffic to and from the PC that is connected to the switch through the access port of the IP phone
(i.e., VLAN 1)
• Voice traffic to and from the IP phone (i.e.,VLAN 2)
Isolating the phones on a separate, auxiliary VLAN increases the quality of the voice traffic and allows a large
number of phones to be added to an existing network where there are not enough IP addresses.
Advantages of VLAN:
• Reduces the broadcast domain, which in turn reduces network traffic and increases network
security (both of which are hampered in case of single large broadcast domain)
• Reduces management effort to create subnetworks
• Reduces hardware requirement, as networks can be logically instead of physically separated
• Increases control over multiple traffic types
• Increases network security
VoIP
Voice Over IP is the technology that provides the capability to break voice streams down into small pieces, group
them together in an IP Packet, and then send them over an IP network to the far end caller.
VoIP Phone
A VoIP phone is a telephone device that looks like a traditional telephone. However, instead of connecting to the
POTS (plain old telephone system) network, it instead has an Ethernet port that is used to connect to a TCP/IP
computer network.
Terminology
10
Activ! IP - Channel Manager (rev D)
Hardware Overview
SmartWORKS
®
IPX (Event Monitor)
SmartWORKS
®
IPX monitors and collects voice packets in the IP-PBX environment and reports D-Channel data
to Activ! IP via the SmartWORKS
®
API. Supporting multiple protocols, it has on-board connections for monitoring
up to 64 channels (120 in the future) of upstream and downstream Real Time Protocol (RTP) and one on-board
connection for output to the Recording Processing Board (i.e., Standard Network Card).
The IPX does not have any DSP resources. This board is not designed for signal detection or recording purposes.
The IPX has been designed with packet forwarding capabilities which enable the user to forward media packets
to another system on the network for signal processing and recording.
• Provides the Tap Point
• Monitors PBX Events
• Multiple IPX per server
• Limited to Half Ethernet bandwidth
VoIP Tap Methods:
• Mirror/span port (Most likely method for station-side tap).
• Tap box (Most likely method for trunk-side tap).
Signaling Protocol—currently supported (more details in the VPCONFIG-VoIP Mgr. Config Section):
• Cisco Skinny (SCCP Protocol-default)
• Avaya H323 (IP PBX S8300 or IP Office PBX)
• H323 Protocol (Standard)
• Nortel UNIStim (Meridian or BCM PBX)
• Ericsson H323 (MD110 PBX)
• SIP (Standard)
• Siemens (HiPath 4000 PBX)
• Alcatel (OMNI PCX)
Note: Future protocol support accommodated with a software upgrade.
Cisco
®
Skinny Client Control Protocol (default)
SCCP is a proprietary terminal control protocol originally developed by Selsius Corporation. It is now
owned and defined by Cisco
®
Systems, Inc. as a messaging set between a skinny client and the Cisco
®
CallManager. Examples of skinny clients include the Cisco
®
7900 series of IP phone such as the Cisco
®
7960, Cisco
®
7940 and the 802.11b wireless Cisco
®
7920. Skinny is a lightweight protocol which allows for
efficient communication with Cisco
®
Call Manager. Call Manager acts as a signalling proxy for call events
initiated over other common protocols such as H.323, SIP, ISDN and/or MGCP.
A skinny client uses TCP/IP to and from one or more Call Managers in a cluster. RTP/UDP/IP is used to
and from a similar skinny client or H.323 terminal for the bearer traffic (real-time audio stream). SCCP is a
stimulus-based protocol and is designed as a communications protocol for hardware endpoints and other
embedded systems, with significant CPU and memory constraints.
Hardware Overview
11
Activ! IP - Channel Manager (rev D)
Example of Incoming Traffic
To understand how the IPX works, follow this example of incoming traffic:
1.Two Ethernet ports monitor the network- one for upstream (Tx) traffic, and the second for downstream (Rx)
traffic. The two sides of the conversation are not summed on the IPX.
2.The IPX sorts packets based on protocol type. As call set-up is negotiated signaling packets are passed to
the appropriate protocol decoding stack.
3.Signaling packets, based on the endpoint’s IP address, are tagged with a Station ID by the IPX’s Station
Manager.
4.D-Channel messages are decoded and events are passed to the user application via the Event Mailer. Each
event is reported with the Station ID.
5.Call State information is abstracted and reported to the user application as Call Control events. Station ID is
reported with each event.
6.When an RTP connection is established between endpoints the event is reported to the user application.
The Session Manager assigns a unique Session ID to this connection which is passed to the user applica
tion along with the Station ID.
7.All media packets (RTP) are redirected to the RTP Forwarding Process.
8.RTP packets are forwarded to two ports on the recording device.
9.When the call is disconnected:
The RTP logical channel is closed - the event is reported. The Session manager gives up this Session ID
for re-use by the system.
During call tear down all D-Channel information is decoded and all signaling information is reported to the
user application in the form of D-Channel events. Call Control information is also reported to Activ! IP.
Decoding Logic
The IPX presents four types of line events to Activ! IP:
• D-Channel - signaling and terminal control messages are decoded and passed to Activ! IP
• Call Control Events - an underlying call state machine abstracts information and provides call state event
reporting
• Media Events - all media (RTP) connections are monitored and reported to Activ! IP
• Station Events - alerts the application when VoIP endpoints are added or removed from the monitored
network
Hardware Overview
12
Activ! IP - Channel Manager (rev D)
D-Channel Events
The IPX provides D-Channel decoding similar to the D-Channel decoding on the AudioCodes
®
NGX boards. To
obtain D-Channel information, the tap must be positioned between the local VoIP phones and the IP-PBX (VoIP
Call Agent). Activ! IP enables the protocol decoding stack on the board, and then enables D-Channel event
reporting for this protocol.
The D-Channel decoder provides a message-to-event translation for the terminal control messages. AudioCodes
®
groups all D-Channel events into two types:
• PBX Command events - messages initiated by the PBX to control the phone
• Phone Action Events - messages initiated by the phone to inform the PBX of an action taken
PBX Command Events
The following types of command events are reported to Activ! IP:
• Signaling - these events indicate the PBX is commanding the phone to produce a tone (ringing, or incoming
page)
• Audio Events - indicate the PBX is controlling external audio devices such as headsets or microphones
• LEDs - these events correspond to light changes on the phone. Light events are important indications when
monitoring call states and feature activity
• Display - these events indicate that the LCD on the phone has been updated. These are usually related to
the clock display, or messages displayed on the LCD
• Call State - these events are generated with a change in call state (NOTE: These are not related to Call Control
events)
Phone Action Events
These events are generated by the phone after an action has been taken (i.e., button pressed). The phone is
informing the PBX that something has occurred. Events generated by the phone have been classified by the
following types:
• Hook State - off hook and on hook changes occur when the handset is removed or replaced
• Button Depression events - indicate that a button on the phone was used. For example: digits, speaker
buttons etc. Button events can include both a pressed or released event, depending on the PBX.
Hardware Overview
13
Activ! IP - Channel Manager (rev D)
Software Configuration (VPConfig) VoIP Channel Manager
Operational Overview
VPI’s VoIP D-Channel recording solution consists of a combination of at least two PCI cards. The first card is the
“SmartWorks
®
IPX” card. The IPX card is a packet sniffing card that connects directly to the SPAN port of the IP
Switch for the phone/devices and supports most of the currently used VoIP PBX’s and signaling protocols. It has a
total of three Ethernet ports on it. The top two, (ports 0 and 1) are the inputs and the bottom port, (port 2) is the
output which streams only the RTP packets containing the call(s) audio to the recording card(s).The IPX card also
supplies all of the Call Control and D-Channel events for each call that it detects traffic on. These events are used to
determine when to start and stop recording while also supplying all pertinent call data for each call which is then
saved by Activ! IP to become searchable data. Each IPX card can accept inputs from two individual SPAN ports
simultaneously and several IPX cards can be used in one system in conjunction with one recording card.
Activ! IP uses a standard network card to perform the actual recording of the RTP packets received from the IPX card(s)
output. All VoIP traffic contains an audio path per party involved in a call (one per party). The recording card must record
each party of the call un-summed then combine these two un-summed recordings into one WAV file hence creating one
recording per call. Activ! IP currently supports G.711, G.729 and G.723 codecs on a per call basis. Each call is checked
before recording starts to determine the codec, port(s) and signaling protocol type of each call automatically.
SPAN Overview
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 to 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 Activ! IP 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 destination
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 configuration 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 regular network
traffic. For more information on SPAN and RSPAN, refer to your switch documentation.
Software Configuration
14
Activ! IP - Channel Manager (rev D)
SPAN Tap Point Options
Port Spanning 1- Monitor traffic of all recorded phones on both transmit and receive (TX-RX). The Gateway(s)
and Call Manager Server(s) do not need to be spanned if the phones are being spanned both in transmit and
receive mode. This will allow for recording of both internal extension to extension calls and external inbound and
outbound calls. Optionally, create two span ports to minimize span port traffic, as the IPX Card can accept input
from two span ports providing that duplicate traffic does not exist on them. Duplicate traffic would then provide
duplicate events to the IPX Card which is not supported.
Port Spanning 2- Monitor the traffic of just the Call Manager Server(s) and Gateway(s) on both transmit and
receive (TX-RX). Optionally, create two span ports to minimize span traffic; one for the Gateway(s) and one for the
Call Manager Server(s). This will allow for recording of only external outbound and inbound calls. Internal extension
to extension calls will contain no audio but will get call control events. Use the Ignore Internal Calls option in this
configuration as internal extension to extension calls will never contain audio.
VLAN Spanning- Monitor traffic of the whole voice VLAN. Normally the span can just be set for Transmit (TX)
only and this is sufficient.
There are many other SPAN options depending on the exact network configuration, switches used, sites involved
etc. The configurations outlined above are just the most common.
NOTES: Monitoring the Call Manager Server and the phones is what provides the Call Control Events
that are required to make this solution work. Since the phones are talking directly to the Call Manager
Server audio is heard via monitoring just the phones themselves. Monitoring just the Call Manager
“cable” by itself would then hear both the phones and the Call Manager and would provide events
however, the RTP Packets would never receive the audio. Once the call is established, the audio (RTP
Packets) are transferred between the two devices involved in the call, either on another phone or on
an internal extension-extension call(s), or the phone and the gateway router on inbound-outbound
external call(s). Activ! IP must get traffic to provide both Call Control Events from the phones, and audio
from the phones and/or gateway routers.
Software Configuration
15
Activ! IP - Channel Manager (rev D)
IPX Setup: VPConfig > Channel Manager > IPX (Tab) > Settings (Tab):
IPX Setup:
Dynamic Mode Checkbox- Activ! IP is configurable to run in two different operating modes. This allows the
configuration to be very flexible and to accommodate most any PBX configuration. A checkbox controls both
modes, options are configured as follows:
Static Mode- Uncheck the “Use Dynamic Channels” checkbox to use Static Mode. In Static Mode the
extension or the IP address of the phone(s) must be setup manually on the Channels Tab of VPConfig.
NOTE: You cannot combine Dynamic mode with Static mode. Please reference the VPConfig
Guide on how to configure Channels. This configuration is very flexible as the channels are config-
ured with either the IP address and/or the Directory Number/Extension of the phone.
Software Configuration
16
Activ! IP - Channel Manager (rev D)
When a call begins, the IP address and extension are both used to determine which Activ! IP channel
should be used to record the call. If both are configured the IP is used first, then the extension if the IP is
invalid or blank. It’s recommended to use IP whenever possible in Static Mode, especially for multi-line
configured phones. If a phone has two lines/extensions assigned to it, and the channels/extension column
is used to configure the Activ! IP channel, it would require an extension per channel for each multi-line
phone, whereas using the IP address of the phone would only require one channel. Shared directory
number/lines/extensions should not use extension for a channel in Static Mode, it’s not supported. This
configuration needs a “unique” identifier per phone, either IP or extension, as long as it’s unique.
Dynamic Mode- Check the “Use Dynamic Channels” checkbox to use Dynamic Mode.
In this mode the first unused available recording channel will be used for recording the call. This in turn
allows more efficient use of the recording channels as a smaller number of recording channels are needed
to record the same number of phones as Static mode. It’s limited only by the maximum number of
simultaneous recordings which in turn is limited by the number of available channels in Activ! IP. For
example, a 64 channel recorder can be used to record 256 phones/devices but can only record 64 calls
simultaneously. When the channel capacity is exceeded by the number of simultaneous calls, recordings
are then ignored in the order received. Each call will normally use a different recording channel under
normal traffic rather than the same channel that Static Mode provides. Activ! IP by default will record every
phone that generates traffic routed to the recorder in Dynamic Mode. With this configuration channels
cannot be locked down to a specific phone in any way. This mode requires no configuration for the Channels
Extension, IP settings, or anything else for that matter to work—it’s basically plug and play in this mode.
The Ignore List within VPConfig can be used in order to not record specific phones in this mode.
Log IPX Events (Trace)- This feature sends all trace events to the Event Center Log file. This includes
routing information, D-Channel Events and Call Control Events. This checkbox should only be checked for
debugging.
Save Dialed Digits- Check this option to capture digits pressed while dialing. When this option is checked
the Digits Pressed will be saved into the ANI/NumberDialed column. The Calling Party and Numbers dialed
will be separated by a forward slash “/” when this is checked. This can be very useful in determining if
an outbound Called Party Transformation is in effect for this call. The digits pressed will show what was
actually dialed while the Called Party will show the number it was transferred to.
Ignore Internal Calls- Check this option to ignore internal extension to extension calls. This will allow for
only recording external inbound and outbound calls. Basically this provides trunkside recording functionality
but is still stationside recording. It’s primarily used when monitoring only the Call Manager Server(s) and
Gateway(s) since there would be no audio present on extension-extension calls but it can also be used
when monitoring just the phones themselves to ignore unwanted internal calls.
# VOX Channels- Enter the number of VOX channels to be mixed with VoIP channels. All Smartworks
®
analog cards can be used but must be configured as the first Board(s)/Channels in the system. Analog
channels can only be used in VOX mode, Loop Detect is not supported. Analog channels must be set to
“Always Record (Vox Emulation)” within the VPConfig/Channels settings.
Software Configuration
17
Activ! IP - Channel Manager (rev D)
Ignore Extensions/IP:
This feature is used with Dynamic Mode in order to ignore specific Extensions or IP Addresses or a mixture
thereof that should not be recorded. Just highlight the extension(s) then select the Minus Sign button. Use the
Add Sign Button to re-add the extension(s).
Record Extensions/IPs:
This feature is used in Dynamic Mode to record only the devices contained in this list. All other devices calls will
be ignored.
Called and Calling Party Transformations
Cisco
®
Call Manager can be configured to use Called or Calling Party Transformations. Both of these features
affect the data passed in the Skinny Protocol as Called or Calling Party. Activ! IP can be configured to handle
Party Transformations for either the Called or Calling Party. When this feature is used on the Call Manager the
actual Called or Calling Party data at times is then moved to either the Called or Calling Party VM or Party Name
fields within the Skinny protocol. This GUI is used to handle this feature and get the actual Called or Calling Party
data rather than the transformed data. Transformed numbers should be entered here when Acitv! IP needs to look
into other fields for the correct data. When Activ! IP encounters any number as either Called or Calling Party
within this list it will then automatically look into the other Skinny fields in order to locate the correct non-
transformed data to use for either extension or ANI/Numberdialed. Both features and how to configure Activ! IP
for handling these features are discussed below:
Calling Party- The Calling Party is what Activ! IP uses for extension on outbound calls, and ANI on
inbound calls. Normally this value would be the Directory Number/Extension of the phone that is making
the call unless it’s being transformed by the Call Manager and/or IPCC/ICM Servers. Calling Party
Transformations will change the Calling Party to whatever the Transformation is set for therefore changing
what Activ! IP is presented via the Skinny protocol as the Directory Number/Extension. This option allows
Activ! IP to handle Calling Party Transformations and still capture the phone’s real Directory Number/
Extension to be saved in the Extension database column and pass on to other applications that may be
using Extension via the VPI API’s. Calling Party Transformations are very commonly used and it’s highly
recommended to check for the correct data on call records to determine if the real Directory Number/
Extension is being captured and Activ! IP and the Cisco Call Manager and are properly configured to get
this data. Changes within the Cisco systems involved may be needed to provide correct or desired data for
the Calling Party. If a Calling Party Transformation is used it may be necessary to put the phones Directory
Number/Extension into the “Display (Internal Caller ID)” section of the Line Settings of each specific
Directory Number assigned to a phone within the Call Manager Administration to provide the real Directory
Number/Extension. This section can accept a mixture of both numbers and letters for a value on the Call
Software Configuration
18
Activ! IP - Channel Manager (rev D)
Manager without affecting Activ! IP as the letters are stripped from the value and just the numbers are
used. For example “Stephanie-4002” could be used for the “Display (Internal Caller ID)”. Activ! IP will strip
the letters from the value and end up with “4002” as the Directory Number/Extension. It’s recommended to
not use any other numbers except the desired Directory Number to be saved as the extension when the
Calling Party is transformed.
Called Party- If a Called Party Transformation is being used on the Call Manager this setting will change
the data seen via Skinny for the Called Party. The Called Party data is saved by Activ! IP into the ANI/
NumberDialed column. If the Save Digits option is enabled you will see the reported Called Party along with
the number actually dialed separated by a forward slash “/”. (Ex: “8053895200/8055551212” where
8055551212 is the transformed number). The GUI in VPConfig can be used to watch for transformed
numbers and allows Activ! IP to look into either the CalledPartyVM or CalledPartyName columns for the
value to use as Called Party. This setting is normally not used or needed by Activ! IP since enabling Saved
Digits would show both values, the numbers dialed and the transformed number which shows as Called
Party. If Save Digits is not or cannot be used then this setting can be used to attempt to get a value other
than Called Party if the correct value is seen in either the CalledPartyVM or CalledPartyName columns.
Called Party- The Called Party is what Activ! IP uses for extension on inbound calls, and Numberdialed
on outbound calls. Normally this value would be the Directory Number/Extension of the phone that is
receiving the call unless it’s being transformed by the Call Manager Server and/or IPCC/ICM Servers.
Calling Party Transformations will change the Called Party to whatever the Transformation is being set for
therefore changing what Activ! IP is presented via the Skinny protocol as the Directory Number/Extension.
This option allows Activ! IP to handle Called Party Transformations and still capture the phone’s real
Directory Number/Extension to be saved in the Extension database column and pass on to other applications
that may be using Extension via the VPI API’s. *Called Party Transformation is rare to see on inbound calls
when monitoring stationside but can be very commonly used on outbound calls in stationside monitoring.
Changes within the Cisco systems involved may be needed to provide correct or desired data for the Called
Party. If a Called Party Transformation is used it may be necessary to put the phones Directory Number/
Extension into the “Display (Internal Caller ID)” section of the Line Settings of each specific Directory
Number assigned to a phone within the Call Manager Administration to provide the real Directory Number/
Extension. If a Called Party Transformation is being used on the Call Manager this setting will change the
data seen via Skinny for the Called Party. The Called Party data is saved by Activ! IP into the ANI/
NumberDialed column on outbound calls. If the Save Digits option is enabled you will see the reported
Called Party along with the number actually dialed separated by a forward slash “/” on outbound calls.
Software Configuration
19
Activ! IP - Channel Manager (rev D)
Party Transformation - Cisco Wildcards
Activ! IP’s Party Transformation GUI supports the use of most commonly used Cisco wildcards.
The Woldcards cover a broad range of “transformed” numbers without having to type them all
individually. For example a commonly used Cisco
®
Call Manager transformation setting would be
“805389xxxx” , this would set the Calling Party to be “8053891234” if the Directory Number of the
phone initiating the call was 1234. The xxxx is replaced by the Directory Number of the phone that
dialed the call. In this case, the Calling Party Transformation in Activ! IP for example could be set
for the following values:
1.805389xxxx would cover any number that started with 805389 and then had 4 more following
digits. For example 8053895200 would be a match while 80538952001 would not be.
2.805389@ would cover any number that started with 805389 with any number of following
digits. For example 8053895200 would be a match while 80538952001 would also be a match.
Supported Cisco® Wildcards: @, X, [ ^ - ], 0 1 2 3 4 5 6 7 8 9 A B C D, *, #
@ The at symbol (@) wildcard matches all numbers. Each pattern can have only one @
wildcard.
Ex: The pattern 389@ matches all numbers in the range 3890000000 through
3899999999.
X The X wildcard matches any single digit in the range of 0 through 9.
Ex: The pattern 9XXX matches all numbers in the range 9000 through 9999.
[ ] The square bracket ([ ]) characters enclose a range of values.
Ex: The pattern 813510[012345] matches all numbers in the range 8135100 through
8135105.
- The hyphen (-) character, used with the square brackets, denotes a range of values.
Ex: The pattern 813510[0-5] routes or blocks all numbers in the range 8135100
through 8135105.
^ The circumflex (^) character used with the square brackets negates a range of values.
Ensure that it is the first character following the opening bracket ([). Each pattern can
have only one ^ character.
Ex: The pattern 813510[^0-5] matches all numbers in the range 8135106 through
8135109.
Unsupported Cisco® Wildcards: !, ?, +
Software Configuration
20
Activ! IP - Channel Manager (rev D)
Calling Party Transform Ext (First and Last X Digits):
Enabled this feature to minimize either First or Last digits when using Calling Transformation for Extensions.
Valid values for these fields are the numbers 1-32.
This field contains a list of discard patterns that control the discard digit instructions. For example, in a
system where users must dial 9 to make a call to the Public Switched Telephone Network (PSTN), the PreDot
discard pattern causes the 9 to be stripped from the dialed digit string.
Called Party Transform Ext (First and Last X Digits):
Enabled this feature to minimize either First or Last digits when using Called Transformation for Extensions.
Valid values for these fields are the numbers 1-32.
Calling Party Transform Masks:
This field specifies the calling party transform mask for all calls routed through this route group. Valid values
for this field are the numbers 0 through 9, and the wildcard character X. This field can also be left blank. If it is
blank and the preceding field is set to Off, no calling party number is available for Calling Line Identification
(CLID).
The calling party transform mask can contain up to 50 digits.
Add the CLID in the box provided and select the Plus (+) Sign Button. Remove a CLID using the Minus (-) Sign
Button.
Called Party Transform Masks:
This field specifies the called party transform mask for all calls routed through this route group. Valid values for
this field are the numbers 0 through 9, and the wildcard character X. This field can also be left blank. If this
field is blank, no transformation takes place—the dialed digits are sent exactly as dialed.
The calling party transform mask can contain up to 50 digits.
Add the CLID in the box provided and select the Plus (+) Sign Button. Remove a CLID using the Minus (-) Sign
Button.
Apply/Cancel Buttons:
Select these buttons prior to exiting the Settings Tab.
Software Configuration
21
Activ! IP - Channel Manager (rev D)
IPX Setup: VPConfig > Channel Manager > IPX (Tab) > Boards (Tab):
IPX Boards:
Here is where you add additional IPX boards depending on how many channels you need to record. Use the Add
and Delete Board buttons accordingly (i.e., 64 channels per IPX Card).
• Analog Cards will not appear here, this section is just for IPX boards.
• The board numbering does not reflect the Smartworks
®
Board number.
Signaling Protocols:
Choose the appropriate terminal control protocol for your recording environment. If required, multiple signaling
protocols can be selected at the same time. For example a Cisco
®
PBX can use Skinny phones, SIP phones and
H.323 devices. In this configuration Skinny, SIP and H.323 Signaling Protocols can be selected to record all three
types on the same system.
Software Configuration
22
Activ! IP - Channel Manager (rev D)
For example a Cisco
®
PBX can use both Skinny and SIP phones.
Cisco
®
Skinny- Select this protocol for use with Cisco
®
Call Manager or any other PBX or devices that
may use the SCCP protocol to communicate. This protocol provides extensive information about each call,
Activ! IP saves all of the information provided into custom fields which represent the actual field names
used within the Skinny protocol.
Port Settings:
Protocol Type - MT_TCP or MT_UDP, the type of protocol used by the network to listen for signaling data.
Default: TCP
Port - Port Number reserved on the Call Manager to listen for signaling requests associated with Cisco
®
telephones. Default: 2000 (Location: Cisco
®
Call Manager Configuration screen Setting: Ethernet Phone
Port)
Supported phone models tested:
Cisco
®
7960
Cisco
®
7940
Cisco
®
7912
Cisco
®
7910
Cisco
®
7920 Wireless Phone
Cisco
®
IP Communicator (PC Software Phone)
NOTE: All Skinny phones and devices should be supported.
Unsupported phone models tested:
Cisco
®
IP Softphone-No Call Control events are provided by this software phone. Recommend using the
Cisco
®
IP Communicator instead which does provide Skinny protocol Call Control events.
Software Release Version tested:
Cisco
®
Call Manager Versions 3.3, 4.1, 4.2, 5.0
Cisco
®
IPCC Express- Standard, Enhanced, Premium
Cisco
®
IPCC Enterprise 7.0
Cisco
®
ICM 7.0 build 14833
Cisco
®
CRS 3.5.3
Cisco
®
Agent Desktop 7.0(0) enhanced version build 7.0.0.39
If other versions are used, different behaviors may be observed that could require additional
programming changes.
Avaya® H.323- Select this protocol for use with Avaya
®
IP PBX S8300 or the Avaya
®
IP Office PBX.
Configure the Port Type and Port Number used by the Avaya
®
PBX.
Port Settings:
H225CS - H225 Call Signaling IP Protocol Type (TCP/UDP) and the port designated by the PBX for listening
to signaling information associated with IP phones. By default, the TCP protocol is used on port 1720.
H225RAS - H225 Registration Admission and Status IP Protocol Type and Port (if RAS is not enabled on
the network than these fields must be ‘NULL’). NOTE: RAS must be enabled and configured correctly
in order to obtain caller and called phone numbers via the IPX.
Software Configuration
23
Activ! IP - Channel Manager (rev D)
Phone models tested:
Avaya S8300
4620
4612
4606
4602
IP Office
5602
4620SW
5620SW
4610SW
4602
Software Release Version tested:
Avaya
®
IP PBX S8300 G3xV11, Comm. Manager 1.3
Avaya
®
IP Office PBX - 3.0
If other versions are used, different behaviors may be observed.
H.323- Select this protocol for recording standard H.323 protocols. This is commonly used for the Cisco
®
Call Manager to communicate to a Gateway router and would be used if the Tap Point was the cable going
to the Gateway.
Nortel
®
UNIStim- Select this protocol to record the Nortel
®
Meridian 1 PBX or the Nortel
®
Business
Communications Manager (BCM).
Port Settings:
LTPS Port Number - the number of the port used by the Nortel
®
IP PBX for listening to signaling requests
from the VoIP endpoints. By default, the Nortel
®
Meridian 1 uses port 5100 while the Nortel
®
BCM uses port
7000.
LTPS Type - MT_TCP or MT_UDP, the type of protocol used by the network. By default, the Nortel
®
PBX
relies on the UDP protocol.
IP Phone Port - Port Number reserved on the IP phone to listen to signaling requests from the PBX. By
default, Nortel
®
phones reserve port 5000.
IP Phone Type - MT_TCP or MT_UDP, the type of protocol used by the network. By default, the Nortel
®
PBX relies on the UDP protocol.
Phone models tested:
Meridian 1
Series Model
IP2004 NTDU92 T
IP2002 NTDU91 T
IP2007 NTDU96 T
IP 1120E NTYS03 T
IP2001 NTDU90 T
Software Configuration
24
Activ! IP - Channel Manager (rev D)
BCM
Series Model
IP004 NTDU82 T
Software Release Version tested:
Nortel
®
Meridian 1 with Option 11c release version 4.
Nortel
®
Business Communications Manager (BCM) Release 3.6 Build 2.2c.
If other versions are used, different behaviors may be observed.
Ericson
®
H.323- Select this protocol to record the Ericsson
®
MD110 PBX.
Port Settings:
H225CS - H225 Call Signaling IP Protocol Type (TCP/UDP) and the port designated by the PBX for listening
to signaling information associated with IP phones. By default, the TCP protocol used is on port 1720.
H225RAS - H225 Registration Admission and Status IP Protocol Type and Port. These fields are required
when decoding an Ericsson
®
PBX. By default the UDP protocol is used on port number 1719.
Phone models tested:
DIALOG
®
4422 T
DIALOG
®
4425 T
Software Release Version tested:
Ericsson
®
MD110 version
BC 12 build CXP1010130/2/BC12SP6/R3B
If other versions are used, different behaviors may be observed.
SIP- Select this protocol to record standard SIP phones or devices.
Phone models tested:
X-Lite softphone
®
- v2.0 rel. 1103m
Avaya One -X
®
, and all phone models that support this firmware
*
Asterisk Grandstream
®
: Budget tone 100, GXP 2000
Asterisk Snom
®
320
Asterisk Zulty
®
Zip2
Asterisk Linksys
®
SP841
*
The IPX is capable of decoding the SIP protocol on networks using this PBX and phone models,
however, the media (RTP) data is either encrypted or scrambled.
Siemens
®
- Select this protocol to record the Siemens HiPath 4000 PBX.
Port Settings:
Two Transports (IPPROTO and Port fields) are needed to enable Siemens with the IPX platform. The
control signaling is proprietary and we have seen it running on port 4060 over TCP. The media is established
using h323 on an h225\h245 channel which we have seen running on port 1720 of TCP.
Software Configuration
25
Activ! IP - Channel Manager (rev D)
Phone models tested:
Optipoint 410 advance,
Optipoint 410 economy plus,
Optipoint 420 advance,
Optipoint 410 entry
Software Release Version tested:
HiPath 4000 Ver 3.0 SMR5 SMP4
If other versions are used, different behaviors may be observed.
Alcatel
®
- Select this protocol to record the Alcatel
®
OMNI PCX Enterprise Systems.
Port Settings:
One Transport is needed to enable Alcatel with the IPX platform. All of the signaling is proprietary and we
have seen it running on port 32640 over UDP.
Phone models tested:
4038 IP Touch Set US (8 Series)
4068 IP Touch Set US (8 Series)
4035 IP Advanced e-reflexes
4020 IP Premium e-reflexes
4010 IP Easy e-reflexes
Software Release Version tested:
OMNI PCX Enterprise 6.0
If other versions are used, different behaviors may be observed.
Board Protocol (i.e., Cisco
®
):
Depending on the Signaling Protocol, select either TCP (i.e., Cisco Skinny) or UDP (User Datagram Protocol, not
normally used but it is supported).
Apply/Cancel Buttons:
Select these buttons prior to exiting the Boards Tab.
Software Configuration
26
Activ! IP - Channel Manager (rev D)
VPConfig > Channel Manager > Database (Tab):
Activ! IP uses several new database columns for VoIP that are not contained within the default database. This
section provides details on these new database columns.
Database Mappings:
The GUI shows the database columns that can be used when the VoIP Channel Manager is enabled and also
allows for the creation of new database columns. If need necessary, the mapping of these columns can be
changed. The left most entries show the columns that Activ! IP will use to save the data, the right most entries
show the database column that will be used to hold the data. If no database column exist there will be no
mapping shown. In this case use the Database Field + button to create a new column for the data.
Software Configuration
27
Activ! IP - Channel Manager (rev D)
Database Field:
This allows for the creation of and modification of the new database columns mappings. Select an entry from the
Database Mappings menu, then click the + button to the right to create the new column. Optionally, the mapping
for any entry in the Database Mappings can be changed here. Normally there is no need to modify the Database
Mappings unless some custom configuration is required.
Apply/Cancel Buttons:
Select these buttons prior to exiting the DatabaseTab.
Software Configuration
28
Activ! IP - Channel Manager (rev D)
Software Configuration
VPConfig > Channel Manager > Software RTP (Tab):
Activ! IP uses a standard network as the RTP recording device. VPConfig will show this Configuration Tab
within the Channel Manager called Software RTP. This tab contains all of the configuration options for the
Software RTP capture within Activ! IP.
NOTE: Enable License Activ! IP for D-channel DLL and set registry setting (DSP Hardware=6)
RTP Setup:
Destination IP Address- This configures the IP Address that Activ! IP will both listen on and stream the RTP
data to and from the IPX card. It must be set for the same subnet as the IPX cards output (port 2) or no audio
will be recorded.
29
Activ! IP - Channel Manager (rev D)
Time Intervals:
Idle Timeout: (integer) default 5 – Time value in
seconds after each a channel is declared idle and stops
recording
InterPacket Sleep: (integer) default 100 – Time value in
milliseconds between polling RTP receive ports. Designed
to improve performance in the future.
Ports:
Left Port: (integer) default 4000 – Left channel UDP port to receive RTP left channel traffic.
Right Port: (integer) default 6000 – Left channel UDP port to receive RTP right channel traffic.
RTP Codec:
Select the type of coding/decoding to be performed on the data stream, here are some examples:
• G.711
• G.729a
Apply/Cancel Buttons:
Select these buttons prior to exiting the Software RTP Tab.
Software Configuration
30
Activ! IP - Channel Manager (rev D)
Skinny Protocol Database Fields
Skinny Protocol Database Fields
This section outlines the Skinny Protocol’s internal communication fields and their definitions. This data provides
detailed information about the call all of which is captured and saved to Activ! IP’s database.
CallingPartyName- When a name can be associated with this number (CallerID when possible, or configured
via PBX).
CallingParty- The number of the caller.
CalledPartyName- When a name can be associated with this number (CallerID when possible, or configured via
PBX).
CalledParty-The number that was originally dialed. LineInstance-which phone line the call is active on. This is
phone model dependant.
CallId- A unique number assigned by the IPX to this call. This number is unique per each Station and is not
unique to the complete system. Same as call ref number provided with the call control events reported by the IPX.
CallType- The direction and type of the call. Values below:
INBOUND=1
OUTBOUND=2
FORWARD=3
OrigCalledPartyNumber- The number that was originally dialed. For example, this field is relevant when the
original number is configured for call forwarding.
OrigCalledParty- This is relevant when call has been redirected or forwarded.
LastRedirectingPartyName- When the call has been re-directed, this is the name associated with the re-
directing phone number (when available).
LastRedirectingParty- When the call has been re-directed, this is the phone number which re-directed the call.
OrigCalledPartyRedirectingReason- The reason the original called number was redirected on the previous call
segment. This would indicate this call has another part associated with it.
LastRedirectReason- The reason the last call was re-directed.
CallingPartyVoiceMailbox- When directed to Voicemail, the mailbox number used by the calling party.
CalledPartyVoiceMailbox- When directed to Voicemail, the mailbox number used by the called party.
OriginalCalledPartyVoiceMailbox- When the call has been forwarded, the original VoiceMailbox used by the
called party.
LastRedirectVoiceMailbox- When the call has been re-directed, the original VoiceMailbox used by the called
party
31
Activ! IP - Channel Manager (rev D)
Cisco
®

Skinny Redirect Reasons
The Redirect Reasons provided within the Skinny Protocol provides more detailed and useful information about each
transferred, diverted, or forwarded call. There are two fields provided in Skinny that use these Redirect Reasons, they
are called OrigCalledRedirReason and LastRedirReason. If a value is present within the OrigCalledRedirReason field
this would indicate that there is a previous call somehow associated with this call and the value shown would
indicate why and how it was redirected. See chart below showing all Skinny Redirect Reasons and their
descriptions.
The OrigCalledParty, OrigCalledPartyName and OrigCalledPartyVM fields would provide the CalledPartyData
data for this preceding “part” of the call. A value in LastRedirReason would indicate why and how this call itself
was redirected and the LastRedirParty, LastRedirPartyName and LastRedirParty VM fields would contain the
data showing where this call was redirected from. Using this data all “parts” of a call can be located. If no data is
provided for either RedirReason there is no other call(s) associated with this call. Unfortunately not enough data
is provided for Activ! IP to perform the FindAllParts feature to locate any other previous parts of a given call. There
is more than enough data to do this manually and locate all recorded parts.
Value Description
Q.931 Standard Redirect Reason Codes
0 Unknown
1 Call Forward Busy
2 Call Forward No Answer
3 Announced Transferred Call
4 Call Transfer
5 Call Pickup
7 Call Park
8 Call Park Pickup
9 CPE Out of Order
10 Call Forward
11 Call Park Reversion
15 Call Forward All
Non Standard Redirect Reason Codes
256 Call Deflection
512 Blind Transfer
768 Call Immediate Divert
1024 Call Forward Alternate Party
1280 Call Forward On Failure
1536 Conference
1792 Barge
Cisco
®
Skinny Redirect Reasons
32
Activ! IP - Channel Manager (rev D)
Cisco
®
Specific Features Supported
Barge- Allows you to add yourself to non-private calls on a shared phone line. Barge features include cBarge and
Barge. Typically, your System Administrator will provide only one of these barge features to you:
• cBarge adds you to a call and converts it into a conference, allowing you and other parties to
access conference features.
• Barge adds you to a call but does not convert the call into a conference. Your system administrator
must configure Barge features for you. Associated softkeys: cBarge, Barge
NOTES: Activ! IP has been tested to work with Cisco’s Barge and cBarge features. Barge results in a
second recording for the extension performing the barge.
Call Forward- Allows you to redirect your incoming calls to another number.
Associated softkey: CFwdALL
Associated key sequence: **1
NOTES: Activ! IP has been tested to work with forwarded calls. Call records will show the extension of
the phone that answered the call as the Number Dialed. The original called party is kept in the Called
Party column.
Call Park- Allows you to park (temporarily store) a call and then retrieve the call by using another phone in the
Cisco Call Manager system. Call Park can be useful if you want to transfer a call from your phone to a phone in
a lab or conference room, for example: Associated softkey: Park
NOTES: Activ! IP has been tested to work with Call Park. When a call is parked, the Call Manager
treats this just like a hold at first. Recording is stopped if the call is parked.
Call Pickup- Allows you to redirect a call that is ringing on another phone to your own phone, so you can answer
the call. Call Pickup features include Pickup, GPickup, and OPickup:
• Pickup allows you to answer a call that is ringing on another phone within your “group” (a collection
of extensions that your System Administrator defines).
• GPickup allows you to answer a call ringing on a phone in another group.
• OPickup allows you to answer a call ringing on a phone in another group that is associated with
your group. Call Pickup can be useful if you share call-handling tasks with coworkers.
Associated softkeys: PickUp, GPickUp, OPickUp
NOTES: Activ! IP has been tested to work with Call Pickup. When a call is picked up from Park there
will be a call record showing an outgoing call from the extension to the pilot number associated with
the Parked Call.
Caller ID- Displays caller-identification, such as a phone number, name, or other descriptive text, on your phone
screen.
Cisco
®
Specific Features Supported
33
Activ! IP - Channel Manager (rev D)
NOTES: Activ! IP has been tested to work with Callerid. Callerid is captured and saved if provided to the
phone.
Call Waiting- Indicates (and allows you to answer) an incoming call that you receive while on another call. Call
waiting also displays incoming call information on your phone screen.
Associated softkey: Answer
NOTES: Activ! IP has been tested to work with Call Waiting. When answering another call the existing
call is placed on hold by the Call Manager which causes recording to stop. When the next call is
answered a new recording will then begin for the Call Waiting call.
Conference Features- Allows you to talk simultaneously with multiple parties.
Conference features include Conference, Join, cBarge, and Meet-Me:
• Conference (or ad-hoc conference) allows you to initiate a conference by calling each participant.
• Join allows you to connect current callers who are on a single line by creating a conference call.
• cBarge allows you to establish a conference by adding yourself to a call on a shared phone line.
• Meet-Me allows you to call a predetermined number at a scheduled time to host or join a conference.
Associated softkeys: Confrn, Conference, Join, cBarge, MeetMe
NOTES: Activ! IP has been tested to work with all types of conferences mentioned here. Any pilot
numbers and/or conference I.D.’s are captured as part of the call(s) record(s). Normally a b00 will be
preceded by the internal conference bridge associated with a conference and normally will be
displayed as Called Party. This information can be used to manually determine all parties recorded
within a conference call.
Direct Transfer and Announced Transfers- Allows you to connect two calls to each other (without remaining
on the line yourself).
Associated softkey: DirTrfr
NOTES: Activ! IP has been tested to work with Direct Transfers. All calls involved in a direct transfer
will be recorded. The actual transferred call may not be marked as a transfer due to the fact that on
some versions of Cisco Call Manager there is no reliable way to determine when and if the transfer
actually took place. Announced Transfers have a LastRedirectReason that provides a value to determine
if a call was transferred but Direct does not. Activ! IP marks calls as transferred if the LastRedirectReason
column contains a value that is seen as a transferred call. See Cisco Skinny Redirect Reasons for more
information on translating Redirect Reasons.
Extension Mobility Service- Allows you temporarily to apply your phone number and user profile settings to a
shared Cisco IP Phone by logging into the Extension Mobility service on that phone. Extension Mobility can be
useful if you work from a variety of locations within your company or if you share a workspace with coworkers.
Associated button: Services
Cisco
®
Specific Features Supported
34
Activ! IP - Channel Manager (rev D)
NOTES: Activ! IP has been tested to work with Extension Mobility. Since Activ! IP captures the call
information on a per call basis, the directory number/extension change that “will follow” the userid
logged into a given phone, will be captured correctly for all calls made after the login. Unfortunately
the userid itself cannot be captured by monitoring the Skinny Protocol data and does not get captured
by Activ! IP. The login itself uses HTTP protocol on port 80 in order to login to the Call Manager. No
other data provided is utilized to determine the userid that logged into a phone. Use the userid’s
associated-assigned Directory Number to “follow” an agent in a free seating environment.
Hold- Allows you to move a connected call from an active state to a held state.
Note that your phone allows only one call to be active at a time; other calls will be put on Hold.
Associated button: Hold
Associated softkey: Hold
NOTES: Activ! IP has been tested to work with Held Calls. Calls put on Hold will automatically stop
recording. This is not configurable. A MediaStopped event is given with the Call Held event.
MediaStopped cannot be ignored, therefore calls put on hold will always stop recording.
Immediate Divert- Allows you to transfer a ringing, connected, or held call directly to your voice-messaging
system.
Associated softkey: iDivert
NOTES: Activ! IP has been tested to work with Immediate Divert. The device/phone taking the call will
be saved as the Ani/Numberdialed. The OriginalCallPartynumber and Name columns will hold the
actual directory Number/Extension that was dialed before it was Diverted. Diverted calls may get marked
as transferred if the LastRedirectReason=4.
Join- Allows you to join two or more calls that are on one line to create a conference call. You remain on the call.
Associated softkey: Join
NOTES: Activ! IP has been tested to work with Join. If a recorded phone Joins a call, another recording
will be started for the Joined phone.
Meet-Me Conference- Allows you to host a Meet-Me conference in which other participants call a predetermined
number at a scheduled time. To host a Meet-Me conference, press MeetMe and dial the Meet-Me conference
number (provided by your system administrator). Meet-Me participants do not use the softkey but simply dial the
number at the scheduled time. Participants get a busy signal if they call the conference number before the host
has dialed in.
Associated softkey: MeetMe
NOTES: Activ! IP has been tested to work with Meet-Me-Conferences.
Multiple Calls per Line Appearance- Allows each line on your phone to support multiple calls. The default
configuration specifies four calls per phone line, but your system administrator can adjust this setting. Only one
call can be active at any time; other calls will be on hold.
NOTES: Activ! IP has been tested to work with Multiple Calls Per Line Appearance. When moving from
call to call each “active” call will become a new recording with it’s own call data. Switching from call
to call is really treated like a call put on hold. Recording stops, and a new call begins.
Cisco
®
Specific Features Supported
35
Activ! IP - Channel Manager (rev D)
Multiple Lines per Phone- Allows you to handle calls on multiple phone lines. Your system administrator
assigns one or more phone lines (directory numbers) to your phone.
NOTES: Activ! IP has been tested to work with Multiple Lines Per Phone. When moving from line to
line each “active” call on each line will become a new recording with it’s own call data. Switching
from line to line is really treated like a call put on hold. The recording stops, and a new call begins.
Phone Line Text Label- Allows you to create a text label that shows up on your phone screen for each of your
extensions or phone lines. This feature can be useful if you have multiple lines on your phone. The line label
setting can be accessed from the User Options web pages.
NOTES: Activ! IP has been tested to work with Phone Line Text Labels. This feature normally adds
data put here to the Called/Calling Party Name field within the Skinny Protocol and is captured by
Activ! IP.
Programmable Buttons- Depending on configuration, programmable buttons provide access to:
• Phone lines (line buttons)
• Speed-dial numbers (speed-dial buttons)
• Web-based phone services (for example, a Personal Address Book button or Fast Dials button)
• Phone features (for example, a Privacy button)
Your system administrator determines how many lines (and therefore line buttons) you have on your phone; he or
she can configure other types of programmable buttons for your phone as well.
Using your User Options web pages, you can assign speed-dial numbers or phone services to available
programmable buttons. Your system administrator might need to first configure a Service URL button for your
phone.
NOTES: Activ! IP has been tested to work with Programmable Buttons. None of these features appear
to have any affect on the Skinny Protocol data therefore have no affect on the operation of Activ! IP.
Redial- Allows you to call the most recently dialed phone number by pressing a button.
Associated softkey: Redial
NOTES: Activ! IP has been tested to work with Redial. This feature has no affect on getting the
numberdialed/called party information. The only difference are digits not being pressed and a softkey
button pressed, neither of which have any affect at all to the operation or data capture by Activ! IP.
Remove Conference Participants- Allows the conference initiator to drop participants from the conference call
by using Remove or Remove Last Conference Participant:
• Remove drops the selected participant
• Remove Last Conference Participant drops the most recently added participant
Associated softkeys: Remove, RmLstC
NOTES: Activ! IP has been tested to work with Remove Conference Participants. If a recorded phone is
removed from a conference, recording is stopped just for the phone that that was removed.
Cisco
®
Specific Features Supported
36
Activ! IP - Channel Manager (rev D)
Resume- Allows you to resume a call that you had put on hold.
Associated button: Hold
Associated softkey: Resume
NOTES: Activ! IP has been tested to work with the Resume Call feature. If a recorded phone resumes
a call a new recording will start.
Shared Line- Allows you to have multiple phones that share the same phone number or allows you to share a
phone number with a coworker. Shared lines can use special features such as Barge and Privacy.
NOTES: Activ! IP has been tested to work with Shared Lines. Activ! IP does not track calls or use
extensions internally to record calls. Calls are tracked by sessionid so phones with the same Directory
Number/Extension do not affect the operation of Activ! IP. However, using Static Mode and having an
Extension only per channel will be affected. To use Static Mode with Shared Lines it’s recommended to
use the IP address per channel rather than the Directory Number/Extension.
Speaker Mode (listen-only)- Allows you to listen to a phone call hands-free (without using the handset).
Associated softkey: Monitor Speakerphone Mode
Associated button: Speaker
NOTES: Activ! IP has been tested to work with Speakerphone Modes. Activ! IP records the audio
directly from the transmission between the two phones/devices and is not concerned which device
on the phone is used. Handset, Speakerphones, Headsets and any other supported communication
device is supported on the Cisco phones.
Speed Dialing- Allows you to enter an index code, press a button, or select a phone screen item to place a call
(rather than dialing the number manually). You can use your User Options web pages to assign a speed-dial
number to a programmable phone button or to an Abbreviated Dialing index code (1-99).
Associated buttons: speed-dial button, assigned keypad button
NOTES: Activ! IP has been tested to work with Speed Dialing. Speed Dialing has no affect on the Called/
Calling Party information and therefore has no affect on the operation of Activ! IP.
Transfer- Allows you to redirect a connected call from your phone to a another number. Transfer features include
Transfer and Direct Transfer:
• Transfer allows you to redirect a single call to a new number, with or without consulting the transfer
recipient.
• Direct Transfer allows you to transfer two calls to each other (without remaining on the line
yourself).
Associated softkeys: Transfer, Trnsfer, Transf, DirTrfr
NOTES: Activ! IP has been tested to work with both types of Transferred Calls. If a recorded phone picks
up a Transferred Call a new recording is started. When a call is transferred from a recorded phone the
recording is stopped.
Cisco
®
Specific Features Supported
37
Activ! IP - Channel Manager (rev D)
Activ! IP Known Technical Limitations
This section outlines any known technical limitations within Activ! IP or it’s supported PBX Systems.
CRITICAL DISCLAIMER!
Cisco
®

Call Manager Systems- VPI cannot guarantee that data obtained on a per call basis will be 100%
accurate due to the overall flexibility of the Cisco
®
Call Manager Systems unless it’s properly installed
and configured. There are many known custom configuration options within the Call Manager that can
affect the locations and/or the data itself in the Skinny Protocol. All known custom configurations that do
affect the data provided via the Skinny Protocol used by the Cisco
®

Call Manager are discussed below:
Directory Number/Extension Limitation- Activ! IP can only handle directory numbers/extensions up to 9
characters long due to a database limitation of the extensionnum column and the internal handling of the extensions
as an integer within Activ! IP. If a directory number/extension longer than 9 characters is encountered it is
assumed that this is a transformed number and Activ! IP then looks to the Called or Calling Party VM or Party
Name fields in order to get the data to use as an extension. If the extension is “transformed” the column
“ExtensionTransformed” will be set to 1 on the calls record. If no usable data exists in either of these fields Activ!
IP will then strip characters from the beginning of the reported data until it is 9 characters long and use this as the
extension on the call record. Basically this prohibits Activ! IP from supporting more than 9 digits for any PBX as
the extension or directory number. The Cisco
®

Call Manager can also allow for non-numeric characters to be part
of the Directory Number/Extension, for example the # and * are both valid characters on the Cisco
®
Call Manager.
These characters cannot be saved as the extension number because they are non-numeric (not integer characters).
They are automatically removed in order to be saved in the extension column of the database. The Called or
Calling Party columns will contain the “un-parsed” original data provided by the Call Manager for each call record.
Activ! IP’s operation of recording the audio is not affected by what the extensions are reported as. Even phones
that have shared line/extensions/instances are supported. Calls made on shared lines/extensions do appear to
the recorder as the same extension. This can cause some strange results for example if using Static Mode and
shared lines extension is used for a channel. It’s never recommended to use a shared directory number/extension
as a unique identifier.
Internal Calls- Internal calls between two recorded phones will only result in one recording for the phone that
initiated the call. The call will show outbound from the extension that made the call to the phone that took the call.
This is due to the fact that there is only one audio “path” for internal calls.
If a non-recorded phone calls a recorded phone the recording will show an inbound call with the extension that
took the call from the extension that made the call.
Cisco
®
and CallRefid’s- Each call on the Cisco Call Manager has two separate CallRefid’s associated with
each call, one for each side or party within the call. They are named Destination Call Leg Identifier and Originating
Call Leg Identifier and are the same I.D.’s that are saved to the CDR database when CDR is enabled on the Call
Manager. *(This IS NOT the Global Callid used within the Call Manager for each call. Cisco’s Global Callid is not
provided within the Skinny data stream between the phones and PBX) External calls (incoming or outgoing calls
from outside involving the Gateway/Trunkline Router) only provide one of these CallRefid’s via the Skinny protocol.
The CallRefid for the Gateway “side” of the call is just not provided in the data stream anywhere. Both of these
CallRefid’s are saved by Activ! IP, one to CTI_CALLID and the other to CTI_NEWCALLID.
Activ! IP has a feature called FindAllParts that was designed to locate all of the parts of a transferred call via
using any provided CallRefid’s from the PBX. This feature only partially works on the Cisco
®
Call Manager due to
the fact the CallRefid is not provided on “external” calls. FindAllParts will only find the part(s) that are directly
associated with the actual transfer, the first incoming “external” part of the call will not be found using this feature.
Activ! IP Known Technical Limitations
38
Activ! IP - Channel Manager (rev D)
It can still be useful in finding the initiating call of an announced transfer.
Cisco
®
Transformed Numbers- The Cisco
®
Call Manager has a feature called Party Transformation that can
affect what is provided via the Skinny data stream for Called and Calling Party. This can be configured on a per
device basis or globally via a Route Pattern on the Cisco
®
Call Manager. This feature is commonly used in order
to mask or change the callerid information provided on either outbound or inbound calls both internal and external.
This causes Activ! IP to see these transformed numbers for the directory number/extension or the ANI. When
this feature is used the real un-transformed data is moved either to the Called or Calling Party VM or Party Name
columns within the data stream. NOTE: See the Called/Calling Party Transformation section for additional
info.
SPAN Port Limitations- Most Cisco
®
switches cannot handle spanning the whole VLAN or all of the ports on the
switch correctly when the utilization exceeds 50% on the switch. Packets can be lost when exceeding the
recommended traffic out of a Span Port. This should always be verified for the model switch and the intended
SPAN Port configuration. It’s always recommended to create the SPAN Port(s) in order to provide the least of
amount of traffic to the SPAN port as necessary. Minimizing traffic to the SPAN port and to the Activ! IP system
will always make for a more efficient reliable configuration.
IPX Card Limitations- With version 3.8 of Smartworks
®
the IPX card supports 64 simultaneous calls per card.
It’s capable of monitoring 256 phones/devices. These capabilities will be increased in future Smartworks
®
releases.
Activ! IP Known Technical Limitations
39
Activ! IP - Channel Manager (rev D)
Index
A
Alcatel® 25
Avaya H.323 22
B
Barge- 32
C
Call Forward 32
Call Park 32
Call Pickup 32
Call Waiting- 33
Called Party 18
CalledParty 30
CalledPartyName 30
CalledPartyVoiceMailbox 30
Caller ID- 32
CallId 30
CallingParty 30
CallingPartyName 30
CallingPartyVoiceMailbox 30
CallType 30
Cisco® IP Softphone 22
Cisco® and CallRefid’s 37
Cisco® Catalyst switches 13
Cisco® Skinny 22
Conference Features 33
CRITICAL DISCLAIMER! 37
D
Destination Port 13
Direct Transfer and Announced Transfers 33
Directory Number/Extension Limitation 37
Dynamic Mode 16
Dynamic Mode Checkbox- 15
E
Ericson® H.323 24
Extension Mobility Service 33
F
FindAllParts 31
H
H.323 23
I
Idle Timeout 29
Ignore Internal Calls 16
Immediate Divert 34
Internal Calls 37
InterPacket Sleep 29
IPX Card Limitations 38
J
Join 34
L
LastRedirectingParty 30
LastRedirectingPartyName 30
LastRedirectReason 30
LastRedirectVoiceMailbox 30
LastRedirParty 31
LastRedirPartyName 31
LastRedirReason 31
Left Port 29
Log IPX Events (Trace) 16
Loop Detect 16
LSPANs 13
M
Meet-Me Conference 34
Multiple Calls per Line Appearance 34
N
Nortel® UNIStim 23
O
OrigCalledParty 30,31
OrigCalledPartyName 31
OrigCalledPartyNumber 30
OrigCalledPartyRedirectingReason 30
OrigCalledPartyVM 31
OrigCalledRedirReason 31
OriginalCalledPartyVoiceMailbox 30
P
Phone Line Text Label 35
Port Spanning 1 14
Index
40
Activ! IP - Channel Manager (rev D)
Port Spanning 2 14
Programmable Buttons 35
PSPAN 13
PSPANs 13
R
Redial 35
RedirReason 31
Remove Conference Participants 35
Resume 36
Right Port 29
RSPANs 13
S
Save Dialed Digits 16
Shared Line 36
Siemens® 24
SIP 24
Source Ports 13
SPAN Port Limitations 38
Speaker Mode (listen-only) 36
Speed Dialing 36
Static Mode 15
Supported Cisco wildcards 19
T
Transfer 36
U
Unsupported Cisco Wildcards 19
V
VLAN Spanning 14
VLANs 13
VOX Channels 16
VSPAN 13
Index
41
Activ! IP - Channel Manager (rev D)
Revision History
Rev. History
Page 17 added more detail to the IPX board settings. Page 21 added more detail to Called and
Calling Party Transformations.
Rev A:
Pages 13 through 36 completely rewritten. Removed all references to IPM-260 Card (now
using Standard Network Cards). Detailed information included for all Signaling Protocols,
including current phone models tested/supported.
Rev Level:
Date:
Description:
11/20/06
Rev B:
Rev C
:
03/07/07
03/14/07
Initial Release.
Rev D
:
03/30/07
Added new information on new features for the IPX Board—including but not limited to
Calling/Caller Party Transform Masking. Software RTP Tab added RTP Codecs. Revised IP
Known Technical Limitations.