Install NICE Voice recording Server on VM in UCS

[knadsady]

We are trying to determine if it is possible to install our Servers running a NICE VoIP recording Application in our Virtual environment on Cisco UCS. We have filtering TAPS installed in our network that provide as an output a copy of the RTP media streams (similar to SPAN output) to a server with a promiscuous NIC that records the VoIP streams, like a sniffer.

Can we connect the output of the tap to a port on the Fabric Interconnect, configure the port as an uplink with a dedicated vlan, and direct the traffic to a VM with a vNIC in promiscuous mode and associated with the dedicated vlan? If this would work, what configuration details are needed? Do we need to disable MAC learning on the dedicated vlan, if that is possible?

Monitoring of source interfaces, servers, etc within the UCS environment and directing the destination out to an external device is documented clearly in the configuration guide, but we are essentially trying to do the opposite.

Ken Nadsady

[mhansen]

I dont have a direct answer to your question but I wanted to share my approach from last year which resulted in our voice recording server, virtualized on UCS.

Initially, we were using "agent based recording" which was using the "span to PC port" option of the IP phones with a sniffer agent installed on all the agent PC's which uploaded the recorded calls/video at the end of the day. Needless to say, with all the crapware that was installed and other misc PC issues, those machines were not the best candidates for real-time communication recording and we had several issues with reliability. Centralized SPAN was not really physically possible for us at the time without additional hardware.

Then, the calabrio solution we were using was updated to support "phone based recording" which used the "built-in bridge" fuction of the IP phone which creates a duplicate RTP stream and sends it to the recording server. Create a SIP trunk on the callmanager, point it to the recording server, create the partition, CSS, and route pattern. This approach greatly simplified our call recording environment because it eliminated the physical constraints of needing the sniffer software, or taps in your case.

Not sure if you were aware of that type of call recording but it has proven to be very reliable for us as the cisco handsets are pretty solid. I dont seem to run into firmware bugs as often as i used to ;). I have to think you could do the same thing with the NICE solution if you dont have other constraints.

Mike

[mhansen]

I just had a quick look on the NICE web site and I think they call the funtionality I mentioned SIP Trunk Call Recording

http://www.nice.com/interaction-recording/sip-recording

[chaausti]

In Switching End Host Mode, the UCS will drop all unknown unicast frames, so it will not work unless your VM uses the destination MAC address(s) from the traffic, and continuously refresh the ARP table entry(ies). Also, you would need to send the 'SPAN type' traffic tagged on a specific VLAN and configure Disjoint L2 Networks.

In switch mode, the UCS behaves like a normal switch (it does PVST+) and if you could send the traffic tagged for a specific VLAN and participate in spanning tree allowing only a single VLAN, the traffic would be flooded in that VLAN to your collection VM, and only to your collection VM if it was the only device on the VLAN.

Both of these cases would likely require an additional pair of switch ports connected to the UCS to take untagged traffic and encapsulate it in a trunk on the 'SPAN traffic VLAN'.

If you could find a way to send the desired traffic over some kind of tunnel, that would be a much simpler implementation as relying on constant arp table entry updates, or ununknown unicast flooding will probably be problematic.

[chaausti]

SPAN to a blade is not added yet.

You can follow this bug to see when it is added:

CSCtr80980

[chaausti]

From the VMware portion of this, you are correct promiscuous mode will turn the vSwitch (can be per port-group) into a hub.