Solved: External Webserver to access CallManager

patricksaar · ‎02-21-2008

Hi,

i've heard that the Tomcat server installaed on on CUCM should not be touched to develop Webservices. So, i would take an external WebServer and buildt on that. Question:

What are the different access methods i hae?

There are the XML Objects available on IP Phones, then there is the AXL browser and there is the SDK. What shall be used for what?

May be some links to documents would be great,

Kind regards, Patrick

stephan.steiner · ‎03-03-2008

It would take an insane amount of time to go into details.. each API has some functionality that it's best at, and you just need to compare the developer guides I linked to to get down to the details (and I figure most people settle for one API.. even though the syntax is similar, if you are used to Java you generally don't like going back to malloc and free, whereas if you're a hardcore C user, you probably like bothering with memory allocation and pointers)

One thing that can be said about TAPI versus JTAPI. Obviously it's a language thing.. TAPI is C whereas JTAPI is Java. Then, TAPI is meant for first party call control (meaning you install the TAPI Service Provider on the PC of the user who owns a particular phone.. and installing multiple TSPs to handle multiple phones concurrently is usually either a PITA or simply impossible), whereas JTAPI is meant for third party call control.. so you have your central application server that manages a bunch of phones.

And yes, you will lose certain features by going the JTAPI route.. e.g. there's no media playback (that's in the JTAPI specs but Cisco decided not to implement it for whatever reason.. many here are quite disappointed about that). But you also gain certain things besides the ones I already mentioned.. e.g. the super provider which allows you to monitor any device without having to configure an application user.

View solution in original post

stephan.steiner · ‎02-22-2008

This (http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/devguide/6_0_1/cucm_devguide.html) lists all XML interfaces you have on Callmanager and what they do (all are XML/SOAP based webservices so you connect to the callmanager using http(s))

Then you have the CTI interfaces TAPI and JTAPI and connect to the CCM using the dedicated TCP port(s) for the protocol (see the guides http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/jtapi_dev/6_0_1/jtapi-dev.html and http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/tapi_dev/6_0_1/tapidev.html)

Finally you have applications that run on the phone (more here http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/all_models/xsi/6_0/english/programming/guide/XSIbook.html)

which can make use of the abovementioned technologies if necessary, or which can be completely separate and offer some kind of interaction with the user on the phone (whereas the other APIs are basially independent.. although you could put some information on the screen using a CTI API. Those have nothing to do with the callmanager except that you define an url to a webpage (which then returns XML that the phones understand, rather than html) on the callmanager so the phone knows what to list if you press the services button, and where to make a request when you select a service.

If you need to know more, I suggest you read through the documents I linked to.

And if you have an older Callmanager version and want to use an XML API or (J)TAPI here's the page with guides for all versions:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html

patricksaar · ‎02-22-2008

Hi,

this of great help, thanks. I have a Tomcat server up and running and, as it seems obvious to me, i would then start the approach to access CCM via XML.

Is there a reason to start with the TAPI/JTAPI approach, that might positionned differently in regards to XML access? My gues is that it's for developers that have no Webserver available, or is there anything that i can do via TAPI/JTAPI that can't be done via XML access?

Great thanks again, Patrick

msabir · ‎02-22-2008

With JTAPI/TAPI you have access to many telephony centric features that are not available via XML/SOAP interface. For example, with JTAPI you can start monitoring a phone for incoming calls and receive real time notifications about events such as CallRinging, CallAnswer and you can even access the media stream. XML is more focused on CUM database, such as retrieving phone list, user list, etc.

patricksaar · ‎02-29-2008

Can one tell me about the differencies in features while using one of these API's?

We would like to focus on JTAPI, but i don't know wether i loose acces to features that would be available on TAPI.

As far as i've read, the TAPI is conforming to Microsft's TAPI V2.1 and JTAPI is conforming to JTAPI V1.2 + proprietary Cisco features.

Thanks for reply, Patrick

stephan.steiner · ‎03-03-2008

It would take an insane amount of time to go into details.. each API has some functionality that it's best at, and you just need to compare the developer guides I linked to to get down to the details (and I figure most people settle for one API.. even though the syntax is similar, if you are used to Java you generally don't like going back to malloc and free, whereas if you're a hardcore C user, you probably like bothering with memory allocation and pointers)

One thing that can be said about TAPI versus JTAPI. Obviously it's a language thing.. TAPI is C whereas JTAPI is Java. Then, TAPI is meant for first party call control (meaning you install the TAPI Service Provider on the PC of the user who owns a particular phone.. and installing multiple TSPs to handle multiple phones concurrently is usually either a PITA or simply impossible), whereas JTAPI is meant for third party call control.. so you have your central application server that manages a bunch of phones.

And yes, you will lose certain features by going the JTAPI route.. e.g. there's no media playback (that's in the JTAPI specs but Cisco decided not to implement it for whatever reason.. many here are quite disappointed about that). But you also gain certain things besides the ones I already mentioned.. e.g. the super provider which allows you to monitor any device without having to configure an application user.