RE: Monitor a call without a monitored terminal or address connected

RE: Handle is unknown to the system and callpark events

2013-06-19T19:13:38Z

My theory is that the Call Park DNs have either been changed so that they are 'global' (in which case they cannot be monitored by JTAPI), or the DNs are instanced-on/associated-with a UCM node that is different from the one which the application is connected to. This refers to a limitation in monitoring park DNs, in that the DNs must be instanced on the same node that the JTAPI app connects to (CTI Manager.) If this is the case, then you should be able to work around this by having the application connect to the UCM node where the park DNs are configured. As noted in the developer guide, support for monitoring global park DNs is in development - however the feature is now scheduled to appear in 10.0 vs. the 9.0 mentioned in your quote below (which was unfortunately over-optimistic.) I'm not sure about the issue you describe with CTI ports. I suspect we would need to look into detailed JTAPI and UCM logs to determine what is going on. If you have a CDN Developer Support contract, I would advise opening a case.

RE: Handle is unknown to the system and callpark events

2013-06-18T15:52:59Z

Thanks for your answer. I think I have two problems: 1) with Call Park Event: I enabled CiscoProvFeatureID.MONITOR_CALLPARK_DN filter on the provider so I usually received the CiscoProvCallParkEv events when calls were parked. Since our customer has added a third node to he CUCM cluster, I can't receive these events anymore. I try to enable clusterwide callpark numbers/range flag, but nothing has changed. In the link you post, I read [i][font=Arial, Helvetica, sans-serif][b]CTI monitoring of parked call Directory Numbers (DNs) is unavailable. This function will be restored in Unified CM Release 9.0.[/b] [/font][/i]What does it mean ? 2) with CTI ports, I'm monitoring dinamically CTI Ports, but since our customer has added a third node to he CUCM cluster, I receive Handle is unknown to the system exception, handling CiscoMediaOpenLogicalChannelEv event. WHat CUCM config I have to investigate ?

RE: addMediaStream

2013-06-17T20:44:18Z

[quote=David Staudt]The DN mentioned will be the address of a service that is playing the pre-recorded greeting on demand. In practice this is typically a CTI port under control of the application (with the caveat that it needs to be observed via a separate thread) It's also possible the DN could be another IVR-type application, but note that their is no media sent from the agent phone towards the greeting service (this can cause a problem for some dedicated IVR systems, like Cisco IVR.) The greeting service needs to quickly answer the call and play the agent's personal greeting, then end its call. The phone will mix-in the audio from this simultaneous greeting call. Some of the feature description text gets a bit confusing regarding what process can/should observe what address, but I think the main point is that the DN that provides the agent greeting may not necessarily need to be fully observed/controlled by the app, since info/events obtained from observing the agent should be sufficient to implement the greeting stream.[/quote]Thanks David. Answered the question for me.

RE: Supported windows OS for Cisco JTAPI application

2013-06-17T18:04:00Z

Cisco JTAPI will support both Windows 8 and Windows 2012 in release 10.0(1) FCS Q4CY2013. Best- George Gary Manager, Product Management

RE: addMediaStream

2013-06-17T17:59:00Z

The DN mentioned will be the address of a service that is playing the pre-recorded greeting on demand. In practice this is typically a CTI port under control of the application (with the caveat that it needs to be observed via a separate thread) It's also possible the DN could be another IVR-type application, but note that their is no media sent from the agent phone towards the greeting service (this can cause a problem for some dedicated IVR systems, like Cisco IVR.) The greeting service needs to quickly answer the call and play the agent's personal greeting, then end its call. The phone will mix-in the audio from this simultaneous greeting call. Some of the feature description text gets a bit confusing regarding what process can/should observe what address, but I think the main point is that the DN that provides the agent greeting may not necessarily need to be fully observed/controlled by the app, since info/events obtained from observing the agent should be sufficient to implement the greeting stream.

RE: Supported windows OS for Cisco JTAPI application

2013-06-17T17:39:50Z

Testing and official support (mainly to validate installer/UI functionality) will be part of UCM 10(1). Not sure about a release date, but I believe expected towards the end of 2013 or early 2014.

RE: Supported windows OS for Cisco JTAPI application

2013-06-17T10:41:28Z

Hello any information regarding support for Windows Server 2012?

addMediaStream

2013-06-15T22:15:10Z

Dear Gang; Are there any sample code for this feature (CiscoTerminalConnection.addMediaStream(...). The documents say that to use this feature:[list] [*]create a DN with auto-answer capability [*]use the DN in the method call [*]create a separate thread that will play audio to the DN [/list]Since JTAPI blocks on addMediaStream, the assumption is that an observer will be placed on the DN. My question is how the DN is associated with the original "agent" device. Should I add that DN as a line to the agent device? With this kind of setup, one would not want that DN to show up as a line that the agent might use since its only function is to act as a conduit for the media stream. After the configuration of the DN, how do we get the IP address and port to send RTP stream to. Since this is an agents phone, I imagine the address and port are not dynamically assigned like a route point/CTI port. Thanks.

RE: CiscoMediaOpenLogicalChannelEv

2013-06-15T00:45:39Z

You will see CiscoMediaOpenLogicalChannelEv when call is answered at RP or CTIPort. If call is not anwered at RP media setup is not initiated and this event will not be seen. Since you are not answering the call at first RP, you will not see this event. On the second RP do you have a route call back as well? Answer the call at RP to see this event.

CiscoMediaOpenLogicalChannelEv

2013-06-14T23:44:36Z

Dear Gang; Using default configuration for a CTI Route Point (that is, I only configured the name and extension), I registered the RP for Dynamic Media Registration and a few Media Capabilities (eg. new CiscoMediaCapability[]{CiscoMediaCapability.G711_64K_30_MILLISECONDS}). I also attached the following observers to the RouteTerminal and RouteAddress objects.[list] [*]CIscoTerminalObserver [*]CallObserver [*]CallControlCallObserver [*]CallControlTerminalObserver [/list] I get the Terminal-In-Service event as well as a host of call changed events when a call is sent to the RP. However, I never get the CiscoMediaOpenLogicalChannelEv Terminal Changed Event. This happens when I dial the route address directly (is that legal?) and when I route to the RP from another RP than employs the route callback interface, but without media registration. One thing: In the callback method of the first RP, I just route the call to the correct media terminating RP without doing anything to it. Shoud I "accept" it first? Thanks,

Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questions:

2013-06-14T22:32:19Z

Yes, it is as basic as you describe. I will get a new pcap next week. ----- Reply message ----- From: "Cisco Developer Community Forums" To: "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.

RE: Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questi

2013-06-14T22:06:39Z

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.

Re: New Message from David Staudt in JTAPI (JTAPI) - Cisco JTAPI Questions:

2013-06-14T19:38:19Z

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" To: "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.

RE: Handle is unknown to the system and callpark events

2013-06-14T19:17:29Z

Currently 'cluster-wide' call park DNs cannot be monitored by CTI applications (this is roadmapped for an upcoming release.) If these are not cluster-wide CP DNs, then note that apps can only monitor CP DNs which are instanced on the same node as the Callmanager/CTI-Manager service instances that the app connects to. http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/8_6_2/delta/delta862.html#wp2288800 Note that notwithstanding the note in the link above, CTI monitoring of cluster-wide CP DNs is not yet available, as of 9.1(1). Regarding the handle error, if related to call park DNs, it is likely due to the above situation. If not, can you provide some more details around the scenario/callflow and observed vs. expected JTAPI events/data.

RE: JTAPI Silent Monitoring

2013-06-14T17:13:41Z

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.

RE: JTAPI Silent Monitoring

2013-06-14T13:59:32Z

Do you know if any progress has been made on this? We do not have a CDN Developer support contract.

Interaction between Presence/BLF and CallEv events

2013-06-14T12:36:06Z

I'm experiencing an issue in which terminals configured with BLFPresence speed dial buttons are receiving CallEv events with metacode Ev.META_CALL_STARTING whenever the watched DN gets busy but not their corresponding CallEv with Ev.META_CALL_ENDING metacode events when call ends. As a consequence my realtime call counters get all garbled. As a matter of fact I'm not interested at all in tracking presence related call events. How would I go about filtering those out? Is there any other set of high level call events fired only for call actually connected to the listened terminal? [EDIT] Oh, let me add I'm listening to said events through a CallControlCallObserver added to a watching CiscoTerminal [/EDIT] Thanks in advance

Handle is unknown to the system and callpark events

2013-06-14T08:16:29Z

Hi to all, we have lots of problem, since our customer added a third node to the cluster of his call manager. CUCM version is 8.6, we monitor and control CTI Ports and IpPhones via CTI, now that we have 3 nodes in cluster arise many times the following exception: [b]com.cisco.jtapi.PlatformExceptionImpl: Handle is unknown to the system[/b] Moreover, the CiscoProvCallParkEv events do not come anymore from the provider, when calls are parked on a CallPark number registered on Node 2 (only in this case). CUCM is not configured by us, my customer tell me that configuration has made as Best practises, Any ideas ? In the jtapi log I found this line: CEST %JTAPI-JTAPIIMPL-7-UNKP1-ApplicationUser) GCID=(1,61699)->INVALIDCallManager.deliverEvents: deliver 5 events with METACODE 132 has somethinf to do with the previuos error ? Thanks. Stefania.

RE: Monitor a call without a monitored terminal or address connected

2013-05-31T21:14:49Z

Unfortunately for now direct/real-time/call-progress monitoring of gateway-UCM-gateway calls is not possible (without resorting to sniffing signaling,) though I believe solutions in that area are being worked on. Note, there is an AXL API for monitoring summary trunk/port call counts/usage on a polling basis (Perfmonport.) Also, you don't overlook that apps can calculate that kind of data historically via the Call Detail Records facility.

RE: Monitor a call without a monitored terminal or address connected

2013-05-31T20:51:42Z

Thanks David, My requirements are to basically be able to report on when the call actually ended on the UCM, not just when the agent's interaction with the caller ends. The call is still using two channels on our PRI trunk (one on the incomming call and one on the external call), and we need to know about it. I will look into using a CTI-port, but my initial thoughts tell me it's a bad idea.