cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2907
Views
10
Helpful
7
Replies

JTAPI Implementation

PVYAPA
Level 1
Level 1

Hello - Looking for some help with JTAPI implementation. Plan is to build a web softphone for 3rd party call control where the purpose is only to control the device through the UI. Reading the developer guide looks like I need to get provider (I read as the CUCM node) and add observers to the phone lines I need to listen/control events on ?

Is it a good idea to use CUCM end user and invoke this from every web softphone page? I am assuming this would create many CTI connections to CUCM CTI manager. (Talking  of 2000 addresses). Since these events are asynchronus , would I need to implement Socket or polling from my web page to JTAPI app sever? 

Or should I associate all phone lines of my interest to a CUCM app user and  start observing each of the address on my app server?On the front-end softphone webpage provide a free form box to the user to enter the directory number. Since,  I would already be observing all the addresses, I would send events related to directory number chosen to my user again through polling the app server ?

 Thanks for your help in anticipation.

 

3 Accepted Solutions

Accepted Solutions

To echo Anusha and maybe elaborate, I think there are two main considerations:

- Security: if you do not want to handle authenticating the user in your app, and simply collect/use the CUCM credentials of the user to open a separate Provider for each you could use the end-user approach mentioned.  If you use a single app-user, then you would probably want to authenticate each user and figure out which devices are associated to the user, allowing them to control only their devices - all possible using the AXL API, but additional work

- Performance: if you instantiate a Provider for each user, there can be a significant overhead in several areas: sockets used in your app and on CUCM (each Provider will use one), start up time to open each Provider, significantly more RAM usage on your side for Provider overhead, potential throttling of new Provider connections (e.g. during the busy morning login time), time to failover large #s of Providers in instances in the event of CUCM outage/reacability, etc.  Using a single Provider would be more efficient for both your side and CUCM, however requires some additional work, i.e. use of the 'Superprovider' feature and need to manage user authentication to enforce device associations.

 

In either model, you will likely be looking at a three-tier architecture, where you service talks JTAPI to CUCM, and the browser clients use some kind of event RPC (Ajax/websockets) downstream to receive events from the service.

View solution in original post

Thanks Anusha and dstaudt for the response. Really helpful insights!

 

Have 3 followup questions

 

1) I now understand  that having single app user would be the way to go. However, did not understand the "superprovider" feature. Can you please throw some more light on it ? We were able to initiate connection to the provider and add subscribe on a particular address which was taken as a input from the client. It seemed to return events like ringing ,call-established etc which using ajax would be passing back to the client(browser). In what scenario would I be using this "Superprovider" ? 

 

2)I did not implement any socket based programming when connecting to CUCM from my server, I am assuming this is managed by the JTAPI API internally when we open connection to CUCM and add the observer.

 

2) For implementing authentication in this kind of scenario to avoid others entering and controlling devices not assigned to them. Would I be querying the CUCM Db using AXL by using the end user credentials provider or is there some other way ?

View solution in original post

1. See this section of the JTAPI dev guide re Superprovider .  This repo of JTAPI samples includes a Superprovider example.

2. Correct, JTAPI handles all the low-level stuff

3. The CUCM User Data Services (UDS) REST API would probably be the way to go.  Authenticate the UDS request using the user's CUCM credentials, querying:

GET https://{host}:8443/cucm-uds/user/{userId}/devices

To retrieve the device names associated to to the user.  You can then have the user select one, which you would use with the JTAPI Superprovider feature to create the the terminal:

CiscoTerminal terminal = (CiscoTerminal) provider.createTerminal( deviceName ) );

From there you can get the available addresses on the terminal, add observers and start handling events/issuing requests.

View solution in original post

7 Replies 7

Anusha B R
Cisco Employee
Cisco Employee

Hi,

The app user vs end user question would depend on the security requirement of the application. Both options would have their own pros and cons and you would have to take those into considerations and then make a call. Using App User would result in only one Provider (connection to UCM), but it would also mean that each user can access any phone by just dialing/entering the DN on the web page. If this is acceptable then you can go this way. But if you want users to be able to access only their DN's then you would have to have an end user based implementation.

Best Regards,
Anusha B R

To echo Anusha and maybe elaborate, I think there are two main considerations:

- Security: if you do not want to handle authenticating the user in your app, and simply collect/use the CUCM credentials of the user to open a separate Provider for each you could use the end-user approach mentioned.  If you use a single app-user, then you would probably want to authenticate each user and figure out which devices are associated to the user, allowing them to control only their devices - all possible using the AXL API, but additional work

- Performance: if you instantiate a Provider for each user, there can be a significant overhead in several areas: sockets used in your app and on CUCM (each Provider will use one), start up time to open each Provider, significantly more RAM usage on your side for Provider overhead, potential throttling of new Provider connections (e.g. during the busy morning login time), time to failover large #s of Providers in instances in the event of CUCM outage/reacability, etc.  Using a single Provider would be more efficient for both your side and CUCM, however requires some additional work, i.e. use of the 'Superprovider' feature and need to manage user authentication to enforce device associations.

 

In either model, you will likely be looking at a three-tier architecture, where you service talks JTAPI to CUCM, and the browser clients use some kind of event RPC (Ajax/websockets) downstream to receive events from the service.

Thanks Anusha and dstaudt for the response. Really helpful insights!

 

Have 3 followup questions

 

1) I now understand  that having single app user would be the way to go. However, did not understand the "superprovider" feature. Can you please throw some more light on it ? We were able to initiate connection to the provider and add subscribe on a particular address which was taken as a input from the client. It seemed to return events like ringing ,call-established etc which using ajax would be passing back to the client(browser). In what scenario would I be using this "Superprovider" ? 

 

2)I did not implement any socket based programming when connecting to CUCM from my server, I am assuming this is managed by the JTAPI API internally when we open connection to CUCM and add the observer.

 

2) For implementing authentication in this kind of scenario to avoid others entering and controlling devices not assigned to them. Would I be querying the CUCM Db using AXL by using the end user credentials provider or is there some other way ?

1. See this section of the JTAPI dev guide re Superprovider .  This repo of JTAPI samples includes a Superprovider example.

2. Correct, JTAPI handles all the low-level stuff

3. The CUCM User Data Services (UDS) REST API would probably be the way to go.  Authenticate the UDS request using the user's CUCM credentials, querying:

GET https://{host}:8443/cucm-uds/user/{userId}/devices

To retrieve the device names associated to to the user.  You can then have the user select one, which you would use with the JTAPI Superprovider feature to create the the terminal:

CiscoTerminal terminal = (CiscoTerminal) provider.createTerminal( deviceName ) );

From there you can get the available addresses on the terminal, add observers and start handling events/issuing requests.

You are awesome !Thanks for talking time and responding to my questions. 

santanudee
Level 1
Level 1

Hi! I am Santanu,

I have some questions for you.

1.Which is CUCM_ADDRESS in JTAPI?

I got a java code from your cisco. From where to get cucm address, bob_dn these are in cucm's account.

2. How to run the jtapi java code.

When I am going to run the code it says Unable to create provider -- connect timed out.

 

The CUCM_ADDRESS would be the host name or IP address of the CUCM host, but more correctly: the CUCM host that is running the CTI Manager service that JTAPI connects to.

"Connect timed out" sounds like JTAPI was not able to make a network connection to the CUCM/CTI Manager service - probably related to your question above