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

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.

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?

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

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.

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.

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?

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.