Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
3446
Views
1
Helpful
2
Comments

JTAPI Silent Monitoring

cdnadmin
Level 11
Level 11

on ‎01-25-2014 10:32 AM

This document was generated from CDN thread

Created by: PETER MISUREK on 22-02-2013 12:22:58 PM
Hi-
I was wondering if anyone has any very simple examples of how to use JTAPI to trigger built-in bridge silent monitoring?  I understand that I will want to call startMonitor on a CiscoCall object, but I'm not having any luck with the code I am testing.  Any help would be appreciated.
Thanks,
Peter

Subject: RE: JTAPI Silent Monitoring
Replied by: Stewart Ponsford on 26-02-2013 10:35:13 AM
You create a new CiscoCall object from the provider and call startMonitor, passing in the address and terminal objects for the initiator plus some flags.  
 
You need to check the settings on the Phone record in CUCM for a couple of things on both the supervisor (Must be in the monitoring calling search space) and the user to be monitored (built-in bridge).   Also not all phone models support it. Not supported on 7910,7912,7931,7940 & 7960.

Subject: RE: JTAPI Silent Monitoring
Replied by: Stewart Ponsford on 26-02-2013 11:15:40 AM
I forgot to mention you also pass the terminal connection for the call you are monitoring. So a target call needs to be in progress - and I think the connection must be in the established state.
 
 

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 26-02-2013 11:07:37 AM
Does the monitoring destination phone ring then, or does it need to be offhook before the startMonitor call?  I'm getting a device Out Of Service with the code I am playing around with.

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 27-02-2013 10:51:02 AM
Here is the code I am trying to get working:
srcAddr = provider.getAddress("1111"); // Agent DN to be monitored
srcAddr.addCallObserver(new CallObserver() { public void callChangedEvent(CallEv[]eventList) { } });
CiscoCall aCall = ((CiscoCall) provider.getCalls()[0];
try {
 aCall.startMonitor(provider.getTerminal("SEPBADBADBADB",   // Supervisor Phone MAC
   provider.getAddress("1234"),       // Supervisor DN
   aCall.getCurrentCallingTerminal().getTerminalConnections()[0],       // Agent call to be monitored
   CiscoCall.SILENT_MONITOR,
   CiscoCall.PLAYTONE_BOTHLOCALANDREMOTE);
} catch (Exception e) {
 e.printStackTrace();
}
 
I am seeing the following exception:
 
com.cisco.jtapi.InvalidStateExceptionImpl: Did not meet pre-conditions -- call must be IDLE.
Supervisor Agent DN is IDLE, no calls in progress and Agent DN has an ACTIVE call.
Is my calling sequence on startMonitor() backwards?

Subject: RE: JTAPI Silent Monitoring
Replied by: Stewart Ponsford on 27-02-2013 10:56:59 AM
I haven't tested this for a while but the call object that I call start monitor is not an already active call.
 
Eg:
 
CiscoCall monitorCall = provider.createCall();
monitorCall.startMonitor( superviserTerm, supervisorAddress,
activeCall_termCon,CiscoCall.SILENT_MONITOR,CiscoCall.PLAYTONE_LOCALONLY);
 
Where activeCall_termCon is the terminal connection for the agent on the active call.

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 27-02-2013 11:18:56 AM
Closer, but I'm seeing the following now:
 
2163: Feb 27 11:11:39.809 CST %JTAPI-JTAPI-7-UNKP1-rmcmuser)[(P1-rmcmuser) GCID=(1,2262750)->IDLE]Request: startMonitor ([SEPC40ACB4C8FFD/[89201199:Cluster DN Presence Allowed:1/(P1-rmcmuser) GCID=(2,3317132)->ACTIVE]->ESTABLISHED]->TALKING)
2164: Feb 27 11:11:39.809 CST %JTAPI-JTAPI-7-UNKP1-rmcmuser)[(P1-rmcmuser) GCID=(1,2262750)->IDLE]Request: startMonitor (SEPE80462EA148A, 4235 , 41752281, 89201199, SEPC40ACB4C8FFD, 1 2
2165: Feb 27 11:11:39.810 CST %JTAPI-JTAPI-7-UNK:[4235]InvalidStateExceptionImpl caught: Address is out of service

Subject: RE: JTAPI Silent Monitoring
Replied by: Stewart Ponsford on 28-02-2013 02:29:32 AM
Hi,
 
Sorry not sure why it isnt working now. Reminder on the checks:
1. Correct phone models
2. Agent is established on a call
3. Supervisor phone idle
4.create new call from provider object
 
Not in a position at the moment to test my code but it has worked. If I get time I will fire it up.

Subject: RE: JTAPI Silent Monitoring
Replied by: David Staudt on 28-02-2013 11:18:27 AM
When adding an Observer (provider/terminal/address) generally the app will need to wait for the corresponding 'InService' event, which indicates that the object is operational and ready to accept commands.  If the app adds an address observer and immediately attempts a command (like start monitor), then this creates a race condition where the command could be attempted before the address is operational.

Not sure that's what you are seeing, but it's a step that is sometimes overlooked.

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 02-04-2013 01:25:12 PM
Ok, I have this working now, but the quality is really poor on the supervising terminal.  Is this normal?  The sound quality when calling between the two terminals is 100% fine, just the observed audio stream seems to have issues with quality.

Subject: RE: JTAPI Silent Monitoring
Replied by: David Staudt on 02-04-2013 04:04:21 PM
We are currently investigating an issue where certain phone/firmware combinations may be incorrectly marking the 'sequence' field in RTP packets being forked to recording services, i.e. the sequence numbers are all odd or all even - skipping sequence numbers.  This results in poor audio quality at the recorder.

If you can obtain a network packet capture of the RTP stream towards your monitoring device, you should be able to see if this is the case for you.  Feel free to attach pcap here.

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 03-04-2013 03:15:46 PM
Yes, it appears this is the case.  I've attached a screen cap of the packet data from wireshark.  This is between a 7962G (monitor src) and 7965G (monitor dest). Phone loads as follows: SCCP42.9-2-1S SCCP45.9-2-1S

Subject: RE: JTAPI Silent Monitoring
Replied by: David Staudt on 03-04-2013 04:14:06 PM
Very interesting...it looks like there is a newer firmware version available: cmterm-7942_7962-sccp.9-3-1SR2-1.cop.sgn
 
Can you reproduce using this latest load?


Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 04-04-2013 11:08:17 AM
Yes, it seems as bad if not worse.  It almost seems like there is not enough processing power on the supervised phone to be able to send the forked audio stream or something.

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 08-04-2013 12:13:14 PM
Should I open a TAC case regarding these issues?  It does not appear to be related to anything I am or am not doing in the code.

Subject: RE: JTAPI Silent Monitoring
Replied by: David Staudt on 08-04-2013 04:11:33 PM
If you have a CDN Developer Support contract, go ahead and open a case (regular TAC will not be able to assist as this is an API-related issue.)

We are already investigating an identical issue, so may have more information (for example a defect ID) shortly.

Subject: RE: JTAPI Silent Monitoring
Replied by: PETER MISUREK on 14-06-2013 08:59:32 AM
Do you know if any progress has been made on this?  We do not have a CDN Developer support contract.

Subject: RE: JTAPI Silent Monitoring
Replied by: David Staudt on 14-06-2013 12:13:41 PM
In the previous mentioned investigation we found the problem on the application side - I believe listening ports on the app were incorrect, and ICMP unreachable errors were present.  My suggestion would be to obtain a network packet capture from the phone itself (enable switch port and span to PC port options), check for ICMP errors, and check the SIP signaling to verify the forked destination IP/port are as expected.
If you can't spot an issue I may be able to examine the pcap if attached here, but to go into much more depth I will need to recommend the CDN/DS support program.

Subject: Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questions:
Replied by: PETER MISUREK on 14-06-2013 02:38:19 PM
This is between two phones, so I'm not sure how the application would have anything to do with it.


----- Reply message -----
From: "Cisco Developer Community Forums" <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Subject: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questions: RE: JTAPI Silent Monitoring
Date: Fri, Jun 14, 2013 12:15 PM



David Staudt has created a new message in the forum "Cisco JTAPI Questions": -------------------------------------------------------------- In the previous mentioned investigation we found the problem on the application side - I believe listening ports on the app were incorrect, and ICMP unreachable errors were present.  My suggestion would be to obtain a network packet capture from the phone itself (enable switch port and span to PC port options), check for ICMP errors, and check the SIP signaling to verify the forked destination IP/port are as expected.
If you can't spot an issue I may be able to examine the pcap if attached here, but to go into much more depth I will need to recommend the CDN/DS support program.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/jtapi/community/-/message_boards/view_message/16212359 or simply reply to this email.

IMPORTANT: The information contained in this transmission is intended only for the personal and confidential use of the designated recipient(s) named above. This transmission is privileged and confidential and may be subject to certain Nondisclosure Agreements. If you are not the intended recipient(s) or an agent responsible for delivering this email and any attachments to the intended recipient(s), you are hereby notified that you have received this document in error. Any review, dissemination, distribution or copying of this message is strictly prohibited.

Subject: RE: Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questi
Replied by: David Staudt on 14-06-2013 05:06:39 PM
Sorry, I overlooked that this is a silent-monitoring (vs. recording) scenario.  Not aware of any reason why a 7942 would have a horsepower issue with BiB monitoring...

If you are an environment like below:

- Both devices in same network segment
- Both devices on latest firmware version (from Cisco.com)
- Both devices are single-homed (one network connection)
- Simple routing/switching environment - no NAT, firewalls, ACLs, SBC, etc.

then it will be difficult to contemplate any other possibility than a phone firmware problem.  Successfully monitoring with another model would be informative.  
If everything above checks out, please obtain a packet capture from both devices and we'll investigate as a phone defect. 

Subject: Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questions:
Replied by: PETER MISUREK on 14-06-2013 05:32:19 PM
Yes, it is as basic as you describe.  I will get a new pcap next week.


----- Reply message -----
From: "Cisco Developer Community Forums" <cdicuser@developer.cisco.com>
To: "cdicuser@developer.cisco.com" <cdicuser@developer.cisco.com>
Subject: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questions: RE: Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questi
Date: Fri, Jun 14, 2013 5:09 PM



David Staudt has created a new message in the forum "Cisco JTAPI Questions": -------------------------------------------------------------- Sorry, I overlooked that this is a silent-monitoring (vs. recording) scenario.  Not aware of any reason why a 7942 would have a horsepower issue with BiB monitoring...

If you are an environment like below:

- Both devices in same network segment
- Both devices on latest firmware version (from Cisco.com)
- Both devices are single-homed (one network connection)
- Simple routing/switching environment - no NAT, firewalls, ACLs, SBC, etc.

then it will be difficult to contemplate any other possibility than a phone firmware problem.  Successfully monitoring with another model would be informative.
If everything above checks out, please obtain a packet capture from both devices and we'll investigate as a phone defect.
--
To respond to this post, please click the following link: http://developer.cisco.com/web/jtapi/community/-/message_boards/view_message/16219773 or simply reply to this email.

IMPORTANT: The information contained in this transmission is intended only for the personal and confidential use of the designated recipient(s) named above. This transmission is privileged and confidential and may be subject to certain Nondisclosure Agreements. If you are not the intended recipient(s) or an agent responsible for delivering this email and any attachments to the intended recipient(s), you are hereby notified that you have received this document in error. Any review, dissemination, distribution or copying of this message is strictly prohibited.

Subject: RE: Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questi
Replied by: PETER MISUREK on 20-06-2013 11:33:35 AM
David, I've attached a pcap file of the silent monitoring data (obtained from a phone SPAN to PC).  These two devices are both on the same subnet and same switch.:

Labels:
Preview file
64 KB
Preview file
6 KB
Comments
oscar.barrofet
Level 1
Level 1
‎02-13-2015 02:56 AM

02/04/2013 Peter said: "OK, I have this working now", but how you did it?

I am exactly in the same point as he was in 27/02/2013 my call is in ACTIVE state, but the pre-conditions for startMonitor states that:

- "the call must be in IDLE"...

And my call has passed already beyond IDLE state.

-> There is a way to reset the call back to IDLE? is what you did? Or how did you solve the problem?

The documentation says:

"IDLE - This is the initial state for all Calls. In this state, the Call has zero Connections, that is Call.getConnections() must return null."

I am using 7940 phones ( I checked and though controversial they say those accept silent monitoring the same way the use conferencing, via DSP) , i set the Agent terminal Built-in-bridge to ON.

liam123
Level 1
Level 1
‎04-07-2019 09:17 PM 
if (ev instanceof CallCtlTermConnTalkingEv) {
    Terminal supervisorTerminal_1819 = null;
    Terminal agentTerminal = null;
    Address supervisorAddress_1819 = null;
    Address agentAddress = null;
    CiscoCall ciscoCall = null;

    try {
        supervisorTerminal_1819 = provider.getTerminal(SUPERVISOR_TERMINAL_SEP00BF7718B4CE);
        agentTerminal = provider.getTerminal(AGENT_TERMINAL);
        supervisorAddress_1819 = 
        provider.getAddress(SUPERVISOR_LINE_1819);
        agentAddress = provider.getAddress(AGENT_LINE);
        ciscoCall = (CiscoCall) provider.createCall();

    } catch (InvalidArgumentException | 
        ResourceUnavailableException | InvalidStateException
        | PrivilegeViolationException | 
        MethodNotSupportedException e) {
        log.error("Exception thrown: ", e);
    }

    if (agentAddress.getConnections() == null || 
        agentTerminal.getTerminalConnections() == null) {
         return;
    }

    if (agentAddress.getConnections()[0] != null
        && agentAddress.getConnections() 
        [0].getTerminalConnections()[0] != null) {

        // Validate first if supervisor's phone is not in monitoring state or on-hook before sending monitoring request
        if (supervisorTerminal_1819.getTerminalConnections() == null && ciscoCall != null) {
            log.info("Monitoring request from {} has sent to {}", 
            supervisorAddress_1819,
            agentAddress.getName());
            ciscoCall.startMonitoring(supervisorTerminal_1819, 
            supervisorAddress_1819,
            agentAddress.getConnections()[0].getTerminalConnections()[0],
            CiscoCall.SILENT_MONITOR, 
            CiscoCall.PLAYTONE_NOLOCAL_OR_REMOTE);
        }
}
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links
Discussions
Customers Also Viewed These Support Documents