I wonder is there some cisco document for JTAPI events flow for some basic calls? (Cisco IP - Cisco IP, 3d-party IP - Cisco IP, Analog - Cisco IP)?
Searched through Cisco JTAPI developers guide, but found flows only for transfer/agent calling
It can be different based on a number of factors, including:
The version of CUCM you are running
The version of JTAPI you are using
The type (SCCP/SIP) and model of phone you are using to make/receive a call
The level of CTI access the application user is provisioned
I recommend you download the JTAPI test tool that corresponds to the CUCM version you are using and see what events you get. That's what I've had to do. ;)
Here are the published versions:
10.0(1) JTAPI Test Tool for Unified CM.zip
11 May 2014: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 10.0(1)
9.0(1) JTAPI Test Tool for Unified CM.zip
14 Feb 2013: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 9.0(1)
8.6(1) JTAPI Test Tool for Unified CM.zip
8 Jul 2011: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 8.6(1).
8.5(1) JTAPI Test Tool for Unified CM.zip
12 Jan 2011: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 8.5(1).
8.0(1) JTAPI Test Tool for Unified CM.zip
16 Feb 2010: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 8.0(1).
7.1(3) Cisco JTAPI Test Tool for Unifed CM.zip
25 Sep 2009: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 7.1(3).
7.1(2) Cisco JTAPI Test Tool for Unifed CM.zip
26 May 2009: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 7.1(2).
7.0(1) Cisco JTAPI Test Tool for Unifed CM.zip
26 May 2009: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 7.0(1).
6.0(1) Cisco JTAPI Test Tool for Unifed CM.zip
26 May 2009: Cisco JTAPI Test Tool for use with Cisco Unified Communications Manager 6.0(1).
Related
Hyperledger sawtooth is maintained by Apache or Inter corporation?
At the footer there is intel corporation, if we want to move the project to production which is built on Hyperledger sawtooth, do we need to pay to intel?
Hyperledger Sawtooth is open source software, and is free to download and use.
The project was initially created by Intel, as blockchain software using Intel SGX CPU instructions to implement PoET (Proof of Elapsed Time) consensus. Intel then donated it to the Hyperledger Foundation as open source software, under the Apache 2.0 open source license. Developers from Intel and many other companies and individuals are members of the Hyperledger community and contribute to the Sawtooth project.
The Hyperledger Foundation is a global collaborative organisation 'created to advance cross-industry blockchain technologies' which incubates and supports several open source blockchain projects. It was launched in 2016 as part of the Linux Foundation, similar to the CNCF and Cloud Foundry.
No, you do not need to pay Intel. Intel donated Hyperledger Sawtooth to The Linux Foundation, which manages it under the Hyperledger consortium.
Hyperledger Sawtooth is licensed with Apache 2, but your application's source code can use Sawtooth and be open (or even closed) source under another license. You just use the Sawtooth APIs/SDKs/CLIs.
Fuzz testing tools generate malformed packets of protocols. Do they use their own TCP/IP stack to generate these malformed packets? Does the operating system's TCP/IP stack play any role in Fuzz testing?
I am working on a MPLS Fuzz testing tool running on Windows 7 OS. The tool is testing a MPLS stack on a Linux machine. Does my test tool use the windows stack? I was told that windows does not support MPLS but the test tool works just fine.
Any tool that doesn't rely on kernel modifications will have to go through the OS's networking stack. This doesn't mean that they necessarily have to use the networking stack's TCP/IP support: many OSes support APIs like SOCK_RAW+IP_HDRINCL (Windows, BSD, OS X)/PF_PACKET (Linux) which lets you build your own packets (which do not have to be TCP, or even IP).
This means that userspace tools are free to bypass the TCP/IP handling in the OS and roll their own packets so long as the OS provides the necessary support (and most major ones do).
I'm investigating how our application can communicate with a phone system: identifying the caller and making a call.
I see that there is a standard Java API: JTAPI with 2 implementations (gjtapi and xtapi). Unfortunately, those projects seems to be dead.
Can I use this API?
Thanks!
I think it depends on the phone systems you have to use/connect with :
With Avaya, Unify (Siemens), Cisco you have good support. Asterisk looks outdated.
Other systems? Don't know.
Yes, JTapi is still alive but it depends of telefony platform maker. For example:
For Cisco you have tow options: For Call Manager Express which allows you control just one extension by connection and for Call Manager Enterprise wich allows you control many extensions by connection.
For Avaya you have another implementation of JTapi wich allows you control one extension by connection.
All of them use the standar of JTapi for implements their requirements according with the telephony plataforma.
Hi we are a embedded development company (www.emfocus.co.in) and new to driver signing details.currently we are developing a driver for a UPS is just a generic USB HID class device.The device firmware has been written in such a way that the UPS will be enumerated as a Human Interface device
But our intention is to treat our UPS as a HID UPS Battery - a battery class device, instead of a generic HID device. So that when we connect our UPS to the Windows, Windows will detect the UPS as a battery connected to the system and the Windows power manager will communicate to the UPS through HID interface. The HID interface here I mentioned in the driver is not just a generic interface. Its HID Power Device Interface. We defined HID Power Device report descriptor in our mini driver, so that the Windows will enumerate a Top Level Collection which is the HID UPS battery for our UPS. That HID UPS Battery top level collection has been implemented in our mini driver. Actually we can use the Windows InBox driver if we have written the device firmware in such a way that it will enumerate a battery top level collection. But our device firmware is written to enumerate as a generic HID device.
Once the HID UPS Battery has been detected by the Windows, the Windows itself starts sending Feature Report requests for getting Battery Capacity, RunTimeToEmpty, AC Present, Charging status... every thing is working fine.
While those requests are issued to our driver, our driver will communicate to the UPS over USB (with its proprietary protocol) and get the status parameters from the UPS and the driver finishes the IOCTL_HID_GET_FEATURE request with the required values in the feature report and Windows Power Manager displays the status on the Power meter.
So that the UPS battery status will be monitored on the Windows Power Meter itself, since Windows considers our UPS as a HID UPS Battery and not a generic HID device after installing our driver.
We want to have the Windows select our driver inf file at all times while looking for best matching driver files.
So to achieve this we want to know if its ok to sign our driver with our code signing certificate or to get the driver WHQL certified ?
If you are just looking to get your device "installable" on an end users system without warnings or signing errors you can create catalog files for the INF installation and sign them with your code signing certificate. The downside to this is that you have to distribute and install the certificate to your users' machines as a trusted publisher before trying to install the device through it's INF.
Alternatively running through the WHQL HCK tests will require that you acquire test logs (for each OS) and submit them to Microsoft for a fee to review and provide a WHQL signature on CAT files created through the HCK submission process. This route is the cleanest for the user because it requires no certificate distribution and also proves that your device passes the WHQL HCK tests.
So the answer depends on what you are trying to do and who your target audience is. I would opt for the WHQL route if you can afford it, as it provides the most benefit for the end users.
i would like to learn how I can make my agents communicate with a PLC(siemens S7 1200). Basically the agents are created in JADE and make a decision kind of a true and false decision which they are to send the PLC. If its true the PLC is activated or otherwise. I have heard of the concept of using simple object access protocol, but not familiar with it (if anyone knows how to use that they can help me with a sample program or means of linking my programs). To complete this by 08 April 2013
I think you're talking about OPC.
OPC is an 'open' standard guarded and maintained by the OPC Foundation.
Every manufacturer of PLCs has an OPC server that communicates over their own protocol to their PLCs. The OPC clients can be donwloaded, purchased or created.
In short [S7-1200] cable S7 over ethernet cable [PC OPC Server intern OPC Protocol intern OPC Client]
In your case, you need an OPC Server from Siemens for the S7-1200. And the OPC client will be your agent. JADE needs to have a OPC library in order to communicate over OPC. See the website of www.opcfoundation.org for the possibilities.
Now you can read and write directly into the PLC.
But, you're using an S7-1200. The new micro automation PLC from Siemens. This has a new memory lay-out and OPC need some tricks to make it work. (Has to do with direct addressing in the older S7 PLCs and the named values in the S7-1200). The following FAQ from Siemens will help you further
How do you connect a PC station to an S7-1200 with OPC?
http://support.automation.siemens.com/WW/view/en/39960679
Or you could try sending the values via TCP/IP. This requires a reprogramming of the PLC.
CPU CPU Communication
http://support.automation.siemens.com/WW/view/en/20982954
I know this is a bit late but libnodave is a package for communication with Siemens PLC's. It works in Java too which is a great plus. I don't think it is suitable for industrial applications though. I do remember Siemens having their own version of the library. Just google it.