Saturday, November 22, 2014

Binding SIP on a per dial-peer basis:

Hi Guys!

Very Cool and I had no idea you could do this, I am sure your all familiar with binding to SIP:

voice service voip
  bind all lo0

What I just found out and wish I had known sooner, is you can actually change this binding on a per dial-peer basis:

dial-peer voice 100 voip
 session target
session protocol sipv2
 voice-class sip bind control source-interface Loopback0
 voice-class sip bind media source-interface Loopback0


Pretty cool hey?

Thursday, November 6, 2014

How to troubleshoot call recording with AQM

Quick note: This blog post shouldn't be considered "finished" at this point, right now it's just a collection of useful tibids I found when configuring advanced quality manager or AQM on cisco. I found there was not a lot of good documentation so this is my attempt to capture some good information.
AQM can be very tricky, it's the second way of doing call recording. I have already spoken in a previous blog post on some of the native call recording options you have, but AQM can provide a bit more advanced methods.

There are several recording methods, the two most common:

Server-based recording:
Uses a SPAN port that you point towards the server, and uses desktop recording as backup.

Network-based recording
This uses the built-in-bridge on the Phone to allow the audio to be mixed and then sent out to a SIP trunk of your choosing. Screen recording is actually done in a VERY clever way by sending a msg to the phone which in turn sends a msg to the PC which tells the screen recording client on the PC to start recording. I found this whole process it went through quite interesting.

Here are some hints to troubleshoot, first of all your AQM user you specify when configuring your CTI JTAPI user under System Configuration -> Telephony Groups needs to be a user who has access to all the phones (since it will use JTAPI to tell the bridge to dial in a certain number) but you must also have a few extra CTI permissions enabled, the screenshot below illustrates this:
Second of all, to help you troubleshoot the log directory contains lots of useful files, I tend to look for the ones that have been modified recently but the most helpful one is the CTI Service, you can use this to tell that the calls are actually being recorded:

2014-11-06 19:11:45,349 DEBUG  [PipelineThread-1|SipStackLogger#logMessage:55] SIP: IN|ACK sip:recording@172.1X.X.X5060;transport=tcp SIP/2.0|2396e9d4|172.16X.X.X57810->172.16X.X.X:5060|Call-ID: c55bac80-45c10cc6-13-70510ac@|From: "Temp" X>X>X;x-farend;x-refci=23795895;x-nearendclusterid=StandAloneCluster;x-nearenddevice=SEPAAAAFEA34743;x-nearendaddr=2606;x-farendrefci=23795896;x-farendclusterid=StandAloneCluster;x-farenddevice=CiscoUM2-VI1;x-farendaddr=2100>;tag=22~a1a6a549-e138-4c78-bd07-3a3cd137f07d-23795903|To: ;tag=c8af6c20|null|Content-Type: application/sdp|

You can see here that the recorded call is a call to voicemail.

Here is where the system tries to send a msg to the client application running on the users PC to tell it to start recording:

2014-11-06 19:11:44,956 DEBUG  [(P1-1X.X.X.X) EventThread|BasicSocketProtocolClient#sendMessage:59] MSG: Sent to X:49276]>: Head[48,292,1]AgentId=247;MAC=SEPAAAEA34743;RecordingIP=172.16.X.X;Type=NETWORK_RECORDING;State=RECORDING_SCREEN_FAILURE;Cause=recording_no_connected_client;<

In this case I didn't have the client installed on that PC. But for this message to go from the phone to the PC means you need to enable the phone to pass that traffic on:

More Help Troubleshooting AQM
You can get some more helpful info troubleshooting AQM but enabling event-viewer notifications like this one:
This will put useful messages in your event viewer so you know when you have misconfigured something:

More helpful troubleshooting steps:
You can always see what the heck is going on and if your screen is actually being recorded by checknig out the encoding directories, these store the actual screenrecordings, on my machine they are configured for:

C:\Program Files (x86)\Common Files\QM\recordings

You can also find them on your server (both the enconding and recording directory) in the postinstall.exe tool (which, incidentally, is another great way to troubleshoot and configure AQM)

When it comes to screen recording, you might notice messages about screen success in your JTAPI log file, but you can also find it in your client logfiles:
C:\Program Files (x86)\Cisco\WFO_QM\log\DesktopRecordServer0001


note however your lovely screencapture won't actually be uploaded until the network is not busy OR you set the workflow to say immediate upload (see screenshot below)

Live monitoring is.. pretty damn sick, you can watch an agents screen live and see what they are up to, check out a screenshot below:

The desktop view (the little picture of an eye) is quite impressive:

It's important to check your workflows to make sure you are actually going to record the event and then match it with an appropriate workflow rule (such as record all calls from user XYZ.) It is far too easy to not notice the calls because you don't have the right workflow rules.

Useful URLS:

These two are decent overviews: