not getting value of getTransferredCall() call Id in CUCM 10.5

[upchaurasia]

Hi All,

Facing strange behavior of app in CUCM 10.5. Actually my observed device is connected with non-observed device.

-Non-observed device transfers that call to other non-observed device.

- Application gets CiscoTransferEnd event

- Application collects previous callId using getTransferredCall() and do some operation

Above operation is gets executed successfully each time but fails with CUCM 10.5.

Is there any change in getTransferredCall() API?

2) Is there anyway to get version of JTAPI library? provider.getVersion() gives CUCM version.

Thanks,

Umesh

[mpotluri]

Umesh,

   I am not clear what is failing in CUCM 10.5? Can you explain what your are actually seeing and what is expected?

You can get the version of JTAPI using the updater API - updater.queryLocalComponentVersion ("jtapi.jar", "full path of jtapi.jar")

e.g: updater.queryLocalComponentVersion ("jtapi.jar", "c:\windows\java\lib");

Running  'java CiscoJtapiVersion' from command line also gives the version of Cisco JTAPI.

[upchaurasia]

Thanks for the reply Mohan.

I am getting getTransferredCall() API return as Null in CUCM 10.5 where as in CUCM 9.1 I am getting previous call which is correct.

Thanks & Regards,

Umesh

[mpotluri]

A calls B -GC1

B consults with C - GC2

B completes the transfer.

In this scenario the call at A remains the same before after transfer. After transfer the call at C changes to GC1.

Depending on how the transfer is completed, A could see a change i.e. the call at A could change to GC2.

In any case applications should be using CiscoTransferEndEv.getFinalCall() to get the final call. If app is not observing B or C, I am not sure transferredCall is useful.

[mpotluri]

A calls B -GC1

B consults with C - GC2

B completes the transfer.

In this scenario the call at A remains the same before after transfer. After transfer the call at C changes to GC1.

Depending on how the transfer is completed, A could see a change i.e. the call at A could change to GC2.

In any case applications should be using CiscoTransferEndEv.getFinalCall() to get the final call. If app is not observing B or C, I am not sure transferredCall is useful.