RE: Agent ready/not ready

CiscoTermina.sendData & non ASCII characters

2012-02-07T15:39:21Z

While our new guys figure out how to renew developer support I've had an old issue creep up again. Back in CUCM 5 days I had a case open on this... using CiscoTerminal.sendData(String data) resulted in non ASCII characters being mangled on devices. I'm currently porting an app made for CUCM 5 to 8.6 and I've run into the same issue. Here's what I'm sending - with cisco dev support we established that we need to prepend ISO-8859-1 encoding to the XML we're sending. data = "" + data; Message we're sending AbwesenheitsmeldungDer gewünschte Teilnehmer (7203) ist zur Zeit abwesend: Von: 01.01.2012 08:00 Bis: 07.02.2012 16:00. Grund: Abwesenheit wegen Fortbildung" This still works fine on IPC 8.6, but on a 7961 running load 9.2.1 the non ASCII characters get mangled. I believe I've gone through the JTAPI documentation with a fine comb, but I've not found anything with regards to any changes in sendData. I've also tried sendData(byte[] buffer): char[] charr = data.toCharArray(); byte[] byteArr = new byte[charr.length]; String error = "Unable to send XML to phone " + term.getName(); for (int i = 0; i < charr.length; i++) { byteArr[i] = (byte)charr[i]; } byte[] resArr = term.sendData(byteArr); String res = new String(resArr); where data is the entire message with the xml header prepended - but to no avail. We're now going through some other phone types to see if it's type dependant (should't be the case anymore but you never know.. back in the old days, every phone acted differently).

RE: Cisco JTAPI and Citrix Terminal Server

2011-10-06T17:06:45Z

Actually, I see no technical reason why this shouldn't work for JTAPI. JTAPI is completely independent of the user mechanisms... you can run JTAPI under a user account, or the system accoun t.. anything you like, and you could for instance have multiple services doing jtapi all running under different user accounts. I've accidentally launched one of my applications already running as a server (and thus different credentials than the logged in user) a bunch of times and it worked just fine (well... it did everything twice so fine is a bit saying too much.. but both application instances did work). Of course, if you're writing something for end users, there are other considerations, but they are outside the scope of the question and they apply regardless of whether you're using JTAPI or developing something else entirely.

RE: Calling Number Modification

2011-10-05T08:44:45Z

David - this is something I think should've been added a long time ago, and I don't quite understand why no PBX I know offers this feature. Adding a caller name to a call (other than on the gateway and delaying the call doing so), bounce calls while not letting know the calle that the call has been bounced around, as well as making calls using a freely selectable caller id would be extremely useful features.

RE: Unknown CCN Exception 0x8ccc00e7

2011-03-11T12:06:24Z

You might want to enable client side JTAPI traces or even go as far as enabling CTI Traces on the CCM itself. There's a bunch of errors that you can only truly figure out if I look at the big picture versus just the CCM exception :(

RE: Push Configuration to all Phone

2010-11-10T00:44:31Z

Or use AXL..

Support for Personal Communicator / CSF

2010-06-11T17:00:02Z

We do have one customer (rather large one.. we're looking at a worldwide rollout of serveral thousand devices) that will be rolling out CUP soon, and where we already have a significant investment in JTAPI based app. Amongst other things, we have our own outbound dialer. With CUP, the customer is looking at both hardphone control as well as softphone mode. And the latter is where the problems start - the outbound dialer will have to pick the proper device. When in hardphone mode, the hardphone should be used, and when in softphone mode, the softphone should be used to dial out. My colleagues that install the CCM/CUP part have made some tests with our current software to demonstrate how the rollout will look, and have found that the softphone part doesn't work at all - issue number one is detecting which mode is active, though they tell me that information can be recovered from the client machine (so I think that part won't be much of an issue because a part of the dialing logic sits on each client and the client could be extended to provide that information to the dialing server). However, it seems to be impossible to control / monitor the Personal Communicator (for CUP7) and CSF (for CUP8) devices. I've had my colleagues try the webdialer as well as the JTAPI test tool and they haven't managed to place a call with either - which seems to underline that those devices are a nogo. Are we doing anything wrong here or is this as it should be?

RE: Using JTAPI in .NET app

2010-04-06T15:56:08Z

If it needs to be a .NET language, look at ATAPI.NET - it's a .NET wrapper for TAPI, and it does work with Cisco's TSP. I haven't used it to make anything actively with it (like make calls, answer calls, etc.) but the whole device state bit definitely works (I see devices and lines coming online and going offline).

RE: CiscoTerm.isRestricted() returning incorrect values

2010-02-17T21:38:52Z

I went ahead and checked out the terminals where the problem arises in a 7.1.3 cluster. Turns out those are all 7931 phones - I know I cannot monitor them in rollover mode.. though imho, JTAPI telling me the device is not restricted, then throw a "terminal is restricted" exception when I try to monitor it is not correct. Either the exception should mention that you're now able to monitor that terminal because that type/configuration mode is not supported, or then isDeviceRestricted should return true right away so we don't even try to monitor it.

RE: CiscoTerm.isRestricted() returning incorrect values

2010-02-09T14:31:25Z

David Yes I'm waiting for the provider to come into service. Additionally, we're not talking about the first phones that are being returned.. it happens at random and well into the list of phones. Here's my Provider initialization code: public boolean init() { boolean retval = false; try { tracer.Trace("\r\n\r\nStarting Jtapi Connector 1.1 - 17.8.2008 (c) NextiraOne GmbH", 1); tracer.Trace("Initializing JTAPI", 1); CiscoJtapiVersion version = new CiscoJtapiVersion(); tracer.Trace("JTAPI Client version: " + version.toString(), 1); JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null); if (peer instanceof CiscoJtapiPeer) { CiscoJtapiPeer myPeer = (CiscoJtapiPeer)peer; setJtapiPreferences(myPeer); String providerString = ""; for (String callManager : config.callManagers) { providerString += callManager + ","; } providerString = providerString.substring(0, providerString.length() - 1); // strip last comma tracer.Trace("Listening to the following call managers: " + providerString, 4); providerString += ";login=" + config.jtapiLogin + ";passwd=" + config.jtapiPassword + ";appinfo=CiscoJTAPI"; provider = (CiscoProvider)((CiscoJtapiPeer)peer).getProvider(providerString); provider.addObserver(this); conditionInService.waitTrue(); prov = this; tracer.Trace("Successfully opened provider", 1); provider.registerFeature(CiscoProvFeatureID.TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY); for (Terminal term : provider.getTerminals()) { addTerminal((CiscoTerminal)term); } tracer.Trace("Successfully added observers for " + provider.getAddresses().length + " devices", 4); retval = true; } else { tracer.Trace("Unable to create a Cisco JTAPI Peer. Aborting..", 1); } } catch (javax.telephony.JtapiPeerUnavailableException p) { tracer.Trace("JTAPI Peer unavailable. Application cannot initialize." + p.getMessage(), 1); } catch (javax.telephony.ResourceUnavailableException r) { tracer.Trace("JTAPI provider reports resource unavailable. Application cannot initialize. " + r.getMessage(), 1); } catch (javax.telephony.MethodNotSupportedException m) { tracer.Trace("JTAPI provider method not supported when trying to add provider observer. Application cannot initialize. " + m.getMessage(), 1); } catch (Exception e) // catch all remaining exceptions { tracer.Trace("Generic exception during JTAPI initialization: " + e.getMessage()); tracer.DumpStackTrace(e.getStackTrace()); } return retval; }

CiscoTerm.isRestricted() returning incorrect values

2010-02-08T23:01:43Z

Is this another race condition issue? When my JTAPI apps start up, I set up Address and Call Observers on each terminal that is not restricted. for (Terminal term : provider.getTerminals()) { addTerminal((CiscoTerminal)term); } protected void addTerminal(CiscoTerminal term) { CiscoTerm ct = null; if (!term.isRestricted()) { if (term instanceof CiscoMediaTerminal) // this is a cti port ct = new CiscoCTIPort(provider, term, this.tracer, false); else if (term instanceof CiscoRouteTerminal) // this is a routepoint ct = new CTIRoutePoint(provider, term, this.tracer, false); else ct = new CiscoTerm(provider, term, this.tracer); ct.registerCallbacks(); this.terminals.put(term.getName(), ct); } else tracer.Trace("Terminal " + term.getName() + " is currently on the restriction list and cannot be monitored", 4); } .. in CiscoTerm.java (term = the CiscoTerminal) public boolean registerCallbacks() { boolean retval = false; lines = term.getAddresses(); try { term.addCallObserver(this); term.addObserver(this); CiscoAddress caddr = null; if (this.lines == null) { tracer.Trace("Device " + this.terminalName + " has no lines, monitoring it will be a rather futile attempt.", 4); } else { for (Address addr : this.lines) { caddr = (CiscoAddress)addr; if (caddr.isRestricted((Terminal)this.term)) tracer.Trace("Unable to monitor line " + caddr.getName(), 3); else addr.addObserver(this); } } retval = true; setDeviceEventFilter(false, TerminalEventFilterType.rtp); //setDeviceEventFilter(true, TerminalEventFilterType.buttonPressed); } catch (javax.telephony.ResourceUnavailableException r) { tracer.Trace("Problem when registering callbacks for terminal " + term.getName() + ": " + r.getMessage(), 1); } catch (javax.telephony.MethodNotSupportedException m) { tracer.Trace("Problem when registering callbacks for terminal " + term.getName() + ": " + m.getMessage(), 1); } catch (javax.telephony.PlatformException p) { JtapiProvider.GetProvider().processPlatformException(p, "registerCallback(" + terminalName + ")"); } catch (Exception e) { tracer.Trace("Generic exception during initialization of terminal " + this.terminalName, 1); } return retval; } Now, I have never had any issues in my lab, but on site, with both CCM 6.1 and 7.1 deployments, I have a handful of phones that dump an exception when I try to add the listeners. Now I'm wondering if I'm doing something wrong here or is there an issue in JTAPI that makes this fail from time to time? Note that when I check the offending terminals, they are not restricted, and neither are their addresses (so that makes me thing it's not race condition related... but I've seen it happening too with restricted terminals).

RE: CiscoProvTerminalRegisteredEv not being fired when JTAPI app first star

2010-02-08T22:54:51Z

Abishek Of course I'm registering my provider for CiscoProvFeatureID.TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY. You said the events only come for terminals that register/unregister after the provider comes into service. Then how do you explain why I was getting the CiscoProvTerminalRegisteredEv event for every terminal that was online at the time I started my JTAPI app back when I developed the app last October (I went on an extended leave until end of January thereafter..) and why suddenly this morning I was once again getting them (and then this afternoon I no longer got them)? That doesn't make much sense, does it? The reason why I like the events is because I need to get the EM login information from JTAP.. and due to a race condition, I only get the proper value once I get a CiscoProvTerminalRegisteredEv (for details see here: http://developer.cisco.com/web/jtapi/forums/-/message_boards/message/1672197). I'm currently working with devsupp on why I don't get the proper EM login information when my app starts up.. regardless of how long I delay querying the value - I only get the proper value for phones for which I have received a CiscoProvTerminalRegisteredE.

CiscoProvTerminalRegisteredEv not being fired when JTAPI app first starts

2010-02-08T18:18:43Z

Hi I'm having this whole thing intermittently - I wrote an app that uses the CiscoProvTerminalRegisteredEv event to load certain terminal data (e.g. the current EM user - getEMUserLogin will only return the correct data if you wait for the event and if you call it when you get the CiscoTermInServiceEv you're too early). When I first wrote my software, I was getting one CiscoProvTerminalRegisteredEv for each phone currently registered with my CCM when I started up my app on CCM 7.1.3.10000. Then I deployed the app at a customer.. they have 7.1.3.20000 - and I wasn't getting any of those events. Went back to my lab, same story there.. suddenly no events (if the phone is being reset, then I get the even when the phone registers again). Then today morning, all of a sudden I'm getting the events again during application initialization. Then I reboot to the inactive partition (where I installed 7.1.3.30000 last week), and after the reboot - no more CiscoProvTerminalRegisteredEv. I swapped out the jtapi.jar for the one that comes with 7.1.3.30000 but to no avail. What do I need to do to reliably get the CiscoProvTerminalRegisteredEv fired for each phone that is registered with CCM (and under JTAPI control of course) when my JTAPI app first starts up?

RE: Can I get MAC address and/or IP address of a caller at a CTI route poin

2009-11-04T04:33:33Z

There are two ways where you can modify the caller id.. one is with a redirect when you haven't answered the call yet (though iirc you can only re-instate the original caller id), and the other is using the route functionality. Look for "modifying calling number" in the JTAPI developer guide http://developer.cisco.com/c/document_library/get_file?folderId=192392&name=DLFE-23006.pdf

RE: Getting the original dialed digits or DDI/DNIS on a call

2009-11-04T04:20:58Z

Not sitting in front of the documentation but download the JTAPI javadoc and look at all the options ciscocall has with regards to called addresses.. make a call and look at the output of all the operations.. if one holds the info - there you go, if not, you're out of luck as there aren't any other options. You can collect digits for internal calls (monitor the phone and set the event filter to include buttons being pressed) but for external calls this is obviously useless. I know from redirects that original* differents from current* (or getCallingAddress differs from getCurrentCallingAddress) but I've never had to look for the oroginal dialled digits prior to any number rewrite. Also consider that depending on the gateway, number manipulations are already done on the gateway and you have no chance of getting the digits there (well.. maybe a TCL script but we're far outside JTAPI now).

RE: CiscoTerminal.getEMLoginUsername returning wrong values //CCM 7.1.3

2009-10-13T20:41:35Z

I was afraid it was a race condition (in the meantime I have opened a case). I found a few other optimization points where I previously used workarounds.. I'll be working on that and I'll check out the CiscoProvTerminalRegisteredEv. Thanks for the tip. By the way, could you suggest to the documentation team that this issue be mentioned in the getEMLoginUsername method description? It seems quite crucial to know when you can run into race condition and I figure I'm not the only one doing a config lookup that way.

CiscoTerminal.getEMLoginUsername returning wrong values //CCM 7.1.3

2009-10-07T18:03:15Z

Here's the scenario: Upon initialization, I add an AddressObserver and CallObserver to a terminal. Once the phone goes into service, I get the CiscoTermInServiceEv event, then I call CiscoTerminal.getEMLoginUsername on the terminal. Upon application initialization, the value returned may be correct, or it may be null, even for phones that have a user logged in (the dev guide says I get an empty string if nobody is logged in.. not null - is this an error in implementation or is the guide incorrect?). Then if a user logs in, I get the CiscoTermInServiceEv again, call getEMLoginUsername and it returns an empty string (which it should if nobody were logged in). If the user logs out again, once the phone comes back up and I get the CiscoTermInServiceEv, the call to getEMLoginUsername returns the name of the user that has just logged out.. If I query the EM API or SQL database via AXL, the values returned are always correct.. but it seems if you call getEMLoginUsername immdiately after a phone has restarted due to an extension mobility login/logout then the value returned by the method is incorrect. For my apps, getEMLoginUsername would be useful to have immediately after a phone comes back up (as the logged in user does not change between that point and the phone coming back online after another restart) - but since it returns the wrong values (except when I initialize my app), it is largely useless. Now I wonder.. is this desired behavior (and so I can go back to my old way of looking up the logged in user) or is it supposed to return the correct values? Note that this does not happen all the time.. there seem to be instances where the return value is correct, then you log in and out a couple of times and suddenly it's back to the wrong behavior. Of course, no report is good without traces so I'm attaching them. The phones I'm using for testing: SEP001E7AC3C13D (7975) with extensions 7500 and 3356. SEP001E138C7466 (7945) with extension 7503 EM profiles: sste (for userid sste) with extensions 3359 and 7510 dmei (for userid dmei) with extension 7511 07.10 14:28:27 - Provider went into service 07.10 14:28:28 - Terminal SEP001E7AC3C13D went into service 07.10 14:28:28 - Terminal SEP001E138C7466 went into service 07.10 14:28:28 - User null is currently logged in on device SEP001E138C7466 07.10 14:28:28 - User null is currently logged in on device SEP001E7AC3C13D 07.10 14:28:30 - 3356 went in service on terminal SEP001E7AC3C13D 07.10 14:28:30 - 7500 went in service on terminal SEP001E7AC3C13D 07.10 14:28:30 - 7511 went in service on terminal SEP001E138C7466 (note that at this point, user dmei is logged into the device whose MAC ends in 7644).. the line "User null ..." comes from me calling CiscoTerminal.getEMLoginUsername upon receiving a CiscoTermInServiceEv event (which turns into line "Terminal ... went into service"). Now user dmei logs out from device 7466: 07.10 14:28:40 - Terminal SEP001E138C7466 went out of service. Reason unregistered 07.10 14:28:40 - 7511 went out of service on terminal SEP001E138C7466 07.10 14:28:43 - Terminal SEP001E138C7466 went into service 07.10 14:28:43 - Line 7511 was removed from the system. 07.10 14:28:43 - User null is currently logged in on device SEP001E138C7466 07.10 14:28:43 - A new line 7503 was added to the system. getEMLoginUsername still reports null (according to page 828 of the dev guide it should report an empty string). Now user sste logs in to C13D: 07.10 14:28:56 - Terminal SEP001E7AC3C13D went out of service. Reason unregistered 07.10 14:28:56 - 3356 went out of service on terminal SEP001E7AC3C13D 07.10 14:28:56 - 7500 went out of service on terminal SEP001E7AC3C13D 07.10 14:28:59 - Terminal SEP001E7AC3C13D went into service 07.10 14:28:59 - User null is currently logged in on device SEP001E7AC3C13D 07.10 14:28:59 - Line 3356 was removed from the system. 07.10 14:28:59 - 3359 went out of service on terminal SEP001E7AC3C13D 07.10 14:28:59 - Line 7500 was removed from the system. 07.10 14:28:59 - 3359 went in service on terminal SEP001E7AC3C13D 07.10 14:28:59 - Address 3359 was added to Terminal SEP001E7AC3C13D 07.10 14:28:59 - A new line 7510 was added to the system. As you can see, we still get null, even though the user sste is now logged into the phone when it comes back online. Now user dmei logs into device 7466 07.10 14:29:12 - Terminal SEP001E138C7466 went out of service. Reason unregistered 07.10 14:29:14 - Terminal SEP001E138C7466 went into service 07.10 14:29:14 - User dmei is currently logged in on device SEP001E138C7466 07.10 14:29:14 - Line 7503 was removed from the system. 07.10 14:29:14 - A new line 7511 was added to the system. And this time, the user reported is indeed correct. Now dmei logs back out from 7466: 07.10 14:29:23 - Terminal SEP001E138C7466 went out of service. Reason unregistered 07.10 14:29:26 - Terminal SEP001E138C7466 went into service 07.10 14:29:26 - User dmei is currently logged in on device SEP001E138C7466 07.10 14:29:26 - Line 7511 was removed from the system. 07.10 14:29:26 - A new line 7503 was added to the system. And now you see that the method still reports the user dmei as being logged in. And finally, dmei logs back into 7466: 07.10 14:29:40 - Terminal SEP001E138C7466 went out of service. Reason unregistered 07.10 14:29:42 - Terminal SEP001E138C7466 went into service 07.10 14:29:42 - User dmei is currently logged in on device SEP001E138C7466 07.10 14:29:42 - Line 7503 was removed from the system. 07.10 14:29:42 - A new line 7511 was added to the system. This time, the logged in user is once again reported correctly.... so we have a pretty good picture here that the behavior is inconsistent.

RE: Getting the state of a phone button

2009-09-29T23:09:02Z

We lost an interesting opportunity because this wasn't possible earlier this year :( The local Cisco team had an idea on how to improve certain things in a call center setup that was put in place (and we're one of the few partners not only installing but also writing third party apps) but we needed to have the status of the headset button (well.. not really the status of the button but whether the headset mode is active or not).

Threaded implementation best practice

2009-07-21T22:28:02Z

According to the documentation, the JTAPI implementation is threaded so you can do nasty things in an event callback. I recently deployed a call monitoring solution (quite a complex beast.. it can keep records of all calls and performs number lookups in various data sources) for quite a large installation (so far I've been dealing with 100-300 phones.. now we're looking at over 1000) Those lookups can be quite involved.. and right now they're done in the callbacks for the appropriate CallEvs (basically I loop through the callsevs and have a method to handle each). Now... today I saw how the poor thing starts up.. not only does it eat up a lot of resources, but after going through the first 50 or so phones, it gets slower and slower and slower (part of the initialization is also loading the phone config from axl since I need information like what lines there are, the locale, extension mobility and some other stuff). I had to do some modifs on the installation (attach another data source) and in order to be able to test more quickly I created a new app user to monitor just one phone and tested with that. Then, at the end I switched back the old app user but at some point I had to go and I didn't get callevs for my testphone yet - I haven't heard anything so far about the whole thing not working if you give it enough time (it's been running for over a month now attached to just a single data source) - but this has me worried so I'm wondering... are there any best practices when dealing with a large installation? E.g. should I take the time to switch over any processing that accesses external data sources to their own threads (actually.. I'd go for a threadpool with an apropriate size since it seems more appropriate than creating threads all over the place for short running tasks).. are there any guideslines as to what you can safely process in the callbacks and what you should do in another thread? Also, and I've noted that before... could it be that those threaded callbacks have their own error catching mechanism? sometimes when I have a try { do something that may fail } catch (Exception e) { log the exception } the code seems to abort right in the middle of the try block without hitting the catch block.. when I run the same code in a non jtapi app, I'd get into the catch block with say a nullpointer exception or something nasty like it - but when inside the callback.. I get nothing at all.. no errors are dumped anywhere (the only thing I didn't do is turn on jtapi logging all the way)... is there something catching those errors on the sly without teling me anything about it?

RE: How is it possible to send caller number from IP PHONE to PC webbrowser

2009-07-10T12:39:00Z

Sure it is... e.g. configure the end user to identify the machine name. The run a JTAPI server app monitoring the phone, and upon a ringing incoming call you look up the machine name in the CUCM database (using executeSQL), and send the number to the PC in question (the PC in question would run a listener application which allows the server app to push numbers... and it would then open a webbrowser with a certain url and containing the number it was sent). Or you could run just one app on the client machines.. they just needed to know which PC to monitor and have the credentials to log into TAPI/JTAPI.. to set this up securely, you could use the end user's login/password and give each user access to monitor just his own device.

RE: Agent ready/not ready

2009-07-10T12:35:45Z

Given what the previous posters said (I really hope one day we'll have a complete JTAPI 1.4 spec implementation from Cisco), there are alternatives you can look at. I'm not sure, but perhaps you can do something in a CRS script.. if so you could write a http trigger and use it to change the agent state. If not, here's what we're already using productively: You can call the agent xml application from your own application with the proper parameters... sniff the connection between a phone and the CUCCX and note how status changes look like.. then replicate those http GET operations in your own application (and parse the result to catch any errors that might occur). We wrote our own agent application based on that principle (plus a http trigger to get the agent state which is shown as an CiscoIPPhoneStatus object on screen so agents always know their state even when they don't have the agent app on screen). I also quickly looked at what the JSP pages (agent application on the phone) actually do, but I suspect that stuff only works on the server itself, and I feel very of using something unsupported and in a setup (you'd have to put your own application on Tomcat or put another Tomcat instance on the server - TAC will balk at both).. so we went the wrapper route.