Q: How can I install the JTAPI client on a non-Windows platform
A: Install on any windows machine and move the classes.
The JTAPIClient.exe, accessible from the CallManager admin web page Application tab, is an InstallShield package. This can be extracted to any Windows PC and the class files can be moved to any non Windows environment.
Alright, doesn't make sense to me offhand because I don't see where the binary is going to come from... but I'll humor them and follow the directions. So I did.
I've setup a Linux/Unix box that I'd like to use to develop and host my applications for interfacing to Cisco's Callmanager. It works on the Windows platform, but for many various of technical reasons, I want to run this on a Linux/Unix box instead. Cisco says you can in their "readme" file.
I've transferred all classes over, set up the proper classpaths, downloaded and installed the same exact version of JTAPI that I had on the working Windows box to the Linux/Unix box in it's format. Set my execution paths for both java and javac so I've got the JRE and JDK all ready to go. Transfer source over to the Linux/Unix box. Run it through the compiler "javac" with the correct classpaths and it compiles successfully just fine, no errors or warnings whatsoever. Now, on the Win platform, I ran the program with "jview". However, there is no such thing I can find availiable for my Linux/Unix platform, which brings me back to my thought in the first place. How am I going to run this without the Cisco JTAPI interface binary for the Linux/Unix platform? I run the program through "java" and of course, it runs. However, I insantly get a message saying...
"Can't get Provider: : javax.telephony.JtapiPeerUnavailableException: JtapiPeer: DefaultJtapiPeer could not be instantiated."
... which basically means to me that the Cisco JTAPI client binary is not there to do the translation between the Sun JTAPI interface and the Cisco Callmanager.
1) Does anyone know if this Cisco JTAPI client binary for Linux/Unix exists?
2) If it does not, please don't say you support the platform in your "readme" file.
I'm not sure what binary you are talking about, I don't see that it is needed. I have not yet implemented this on a Linux environment, but I don't see anything stopping a port to Linux.
Java provides JTAPI support, and Cisco provides extensions to the standard JTAPI classes to provide extended support. These are the classes that you copy across to your JTAPI environment. You don't need to use Cisco's classes at all if you don't need the extended support, I believe.
However, the sample applications that come with the JTAPI client are written in Visual J++ I believe (which is no longer available from MS, to my knowledge), which is a windows-only environment with windows-only java extensions. Therefore, you probably won't be able to run those samples in a non-windows environment.
In regards to the error you noted, it looks like you might be having a jtapi-based error, and not a platform problem. If you are still having difficulty with this (your post is a couple weeks old) we could look into this. I would be interested in the outcome.
Actually, I have it working on linux at this point.
(Ironically, it works more reliably than on Microsoft products)
With both the JRE and JDK loaded, you can run the JTAPI java calls. My problem before was twofold...
1) Incorrect reference directly to JTAPI without a needed Cisco extension.
2) Putting my .jar in the path, but not explicitly naming it.
I have written a shell binary for the linux platform to handle both execution and compilation of Cisco based JTAPI. It handles multiple versions of Callmanager natively. If anyone is further interested, you may contact me directly.
where 22.214.171.124 is the ip address of the callmanager. What I dont understand is that the application makecall which use the exact same connection string succeeds to get a provider. So I suppose that I am missing something in the configuration of the CTI port in the call manager.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...