Can JTAPI control calls between different Providers

[Simon_New1]

Hi all,

Please give me some ideals about "call controls between different JTAPI Provider instances".

I use the Cisco JTAPI Test Tool to test JTAPI functions based on Devnet sandbox labs.

Some time when the JTAPI Test tool can detects the calls which are triggered out of the tool, and sometime, it only can get the calls which are made from itself. So, please help to confirm that one JTAPI provider can detect the call/conferences which are triggered by another JTAPI instance.

For example: (use the same connection strings)

Provider provider1 = JtapiPeerFactory(null).getProvider(".....");

Provider provider2 = JtapiPeerFactory(null).getProvider(".....");

provider1.makeCall()...

provider2.getCalls()

How to make the "provider2.getCalls()" contains the calls which are made via provider1? or the Cisco JTAPI implement does not support things like that?

I test the above, it cannot work (the provider2.getCalls() does not contains the call triggered by provider1, thought the call does exist there)

Simon

[mpotluri]

Hi Simon,

Can you confirm that userid/password used in both providers are same and that call observers are added to the same Terminals and addresses in both the providers?

If you have jtapi log for this scenario, can you attach them to this thread?

[simon_new11]

Hi Mohan,

Thanks for your reply.

Regarding your questions:

1. the connection strings (contains userid/password) are the same for both providers

2. regarding the observers, I do not think they are the same

    (when the made in provider 1, do we need to add observers to the call in provider 2, and can we do that?)

In fact, the use-case is that in a distributed environment, the provider 1 is used in JVM A, and provider 2 is used on JVM B.

My questions is that, when the JVM A crashed after the provider 1 makes calls, can the provider 2 detects/controls the calls (which are triggered in JVM A)?

In the Cisco JTAPI Test Tools, some times it can work as above (which I expect), sometime, it cannot.

So I want to know the key points for that.

Any suggestions?

Simon

[mpotluri]

Hi Simon,

   The use case you mentioned should work. You need to make sure that you add call observers the same way in both Provider1 and Provider2. You can run 2 instances of JTAPITestTools to see this.

• Start JTAPITestTool from a folder X. Login and add call observers on address A and B. Make a call between A and B.
• Start another instance of JTAPITestTool from folder Y. The folders are not important but separating JTAPI logs will be convenient. Login and add call observers to A and B. You should see the call and events for the call.
• Close the first instances of JTAPITestTool.
• You should continue to see the call in the second instance of Test tool and should be able to other features (redirect, drop, hold, etc) on the call as well.

[Simon_New1]

Hi Mohan,

Thanks very much for your detailed reply.

For my understanding, the key point is that the 2 providers have the call observers before take actions.

Thanks.

Simon

[mpotluri]

Yes.

[Simon_New1]

Hi Mohan,

Other question based on the above. If there are 2 clusters of CUCM, provider1 refers to the Cluster1, while provider2 refers the Cluster2, can we control the call between those providers?

I think in an enterprise, there are many CUCM clusters, how use JTAPI access the huge clusters? I mean how to specify the connection string? and the call between the different cluster can be controlled by JTAPI or not?

Simon

[mpotluri]

If both clusters are on the same CUCM version, it is easy to mange multiple clusters. When connecting to multiple clusters JTAPI from the lowest version CUCM should be used.

In multi cluster scenario, provider 1 is unaware of provider 2 and work independent of each other. Calls in the provider are its view from the corresponding cluster.

If a call is made from a phone1 in cluster 1 to phone2 in cluster 2 and  observed from provider 1 and provider 2, each provider will have a call. In Provider 1 the call will have connections and terminal connections for phone1 and connection of phone2 (no terminal connection for phone 2 as phone 2 can't be observed from provider1).

Similarly in provider 2, phone 2 will have connections and terminal connections and only connection for phone 1.

[Simon_New1]

Hi Mohan,

Thanks again.

Is there another way to handle the multiple cluster by JTAPI beyond the way that each provider for each cluster?

For instance, for the multiple CUCM cluster deployed with Session Manager, can we take all the cluster as one for JTAPI perspective? or is there an virtual host/IP for JTAPI provider?

Simon

[mpotluri]

JTAPI provider can handle one cluster only at a time. Info from multiple providers should be aggregated in application layer. I don't think session manager will help.

[Simon_New1]

Thanks very much, Mohan. Great help from you.

[Simon_New1]

Hi Mohan，

according the case

"

If a call is made from a phone1 in cluster 1 to phone2 in cluster 2 and  observed from provider 1 and provider 2, each provider will have a call. In Provider 1 the call will have connections and terminal connections for phone1 and connection of phone2 (no terminal connection for phone 2 as phone 2 can't be observed from provider1).

Similarly in provider 2, phone 2 will have connections and terminal connections and only connection for phone 1.

"

for the call, the call Ids are the same or different on provider 1 and provider 2?

Simon

[mpotluri]

Hi Simon,

CallId will be different. Each cluster creates its own unique callID and in the above scenario the probability of seeing the same GCID for example is close to zero.

[Simon_New1]

Hi Mohan,

Thanks a lot.

Simon.

[Vlad Polyakov]

Hi Mohan,

We have 3 UCM clusters in our environment, and we would like to be able to identify and process a cross-cluster call from a single application.

1. Is there a way to correlate the two call IDs in the scenario described above?
2. Is there at least a way to correlate software originated calls (perhaps by attaching an object to a call)?

Thanks ahead,

Vlad