RE: Jtapi intercom http://developer.cisco.com/c/message_boards/find_recent_posts?p_l_id= 2013-05-20T05:21:40Z 2013-05-20T05:21:40Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15387608 2013-05-18T19:46:32Z 2013-05-18T19:46:32Z

I dont see any obvious reason why the transfer would fail, you may want to open a support case with logs. Also, if reason for doing transfer is only to have caller appear as RP then you could look at selectRoute API which allows to modify callingParty.

Abhishek Malhotra 2013-05-18T19:46:32Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351609 2013-05-17T01:31:13Z 2013-05-17T01:31:13Z

CUCM upgrades are backward compatible with JTAPI applications(in allowed upgrade paths) but not forward compatible. So, with older JTAPI version you can connect to newer CUCM, but with Newer JTAPI cannot connect to older CUCM

Abhishek Malhotra 2013-05-17T01:31:13Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351497 2013-05-17T01:24:34Z 2013-05-17T01:24:34Z

What do you mean by remote destination profiles? Are you using EM cross cluster? Can you explain a bit more on what you really want to achieve?  

Abhishek Malhotra 2013-05-17T01:24:34Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351456 2013-05-17T01:21:32Z 2013-05-17T01:21:32Z

If CFA is set, all calls would be forwarded. So, you cant send a call back as that would also get forwarded. Instead of redirecting back to phone, is it possible that you forward the calls from Phone conditionally to RP. So, basically your JTAPI application controls the phone and on getting OfferedEv you apply your business logic to determine whether call needs to stay on phone or whether it needs to be routed to RP. If it neeeds to be routed then you can invoke Redirect() API to send the call to RP.  

Abhishek Malhotra 2013-05-17T01:21:32Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351424 2013-05-17T01:15:13Z 2013-05-17T01:15:13Z

Do you know how the calls are being routed to the representatives? Is it through your inhouse application or some other contact centre solution(UCCE/UCCX ?) If it is your own application, you could specify calling address as part of selectRoute request while routing it to representative

Abhishek Malhotra 2013-05-17T01:15:13Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351384 2013-05-17T01:07:05Z 2013-05-17T01:07:05Z

RTPInputProperties are going to give you the IP Address and Port of the near end(ie. your CiscoMediaTerminal) while RTPOutputProperties are going to give you RTP Details for the far end.  Can you explain on what information are you really looking for when you say, how to get right streams for the call?  

Abhishek Malhotra 2013-05-17T01:07:05Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351353 2013-05-17T01:01:49Z 2013-05-17T01:01:49Z

[quote=Manas Varma]Hi All,   We have successfully created standalone applications for making call, conferences and playbacks.Howeverm we need to host the application as a service to provide to our client. The issue with this is that once the session is established after the first request, the actually function of making call throws a null pointer exception, as its a stateless service.Has any one hosted these functions as web service.Would be great if you can light this up please! Thanks, Manas Varma  [/quote] How are you initializing JTAPI provider? If i were to do this, I would create a ServletContextListener and initiate JTAPI provider with contextInitialized and shutdown the JTAPI Provider when contextDestroyed. And then I would reuse the same JTAPI Provider with all my requests. So, client side would send a web request, and my servlets would use the JTAPI Provider on the server side  

Abhishek Malhotra 2013-05-17T01:01:49Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351309 2013-05-17T00:55:39Z 2013-05-17T00:55:39Z

You should be getting disconnected event for both the parties when either of them disconnects. Can you attach JTAPI log for the above said scenario

Abhishek Malhotra 2013-05-17T00:55:39Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351301 2013-05-17T00:51:49Z 2013-05-17T00:51:49Z

The callobserver would work on addresses which are in JTAPI's provider's domain (ie. the address should be in JTAPI application users control list) So, if you logout and device extension(address) changes then this new address(changed) would not work with call observer unless you have it in user's control list. If this is not really your problem, can you ellaborate a bit more on what exactly you are doing and at what point you see the above said exception.

Abhishek Malhotra 2013-05-17T00:51:49Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351293 2013-05-17T00:48:43Z 2013-05-17T00:48:43Z

Are you invoking multiple SendData API one after the other? If so, try giving some delay. There are other threads in the forum covering more details on this issue. You can also find these details in CAVEAT section in dev guide.

Abhishek Malhotra 2013-05-17T00:48:43Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351252 2013-05-17T00:46:38Z 2013-05-17T00:42:06Z

These were implemented in release 8.5. (You can refer to 8.5 Dev Guide) Please refer to Agent Greeting feature for "addMediaStream" API. For "updateMonitorType", details are covered in "Whisper Coaching" feature section but I am not sure from which release this was supported, so I will let someone else comment on this. 

Abhishek Malhotra 2013-05-17T00:42:06Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15351069 2013-05-17T00:35:22Z 2013-05-17T00:35:22Z

While handling CiscoRTPOutputStartedEv, why are you invoking run() method of your RTP sender thread directly instead of calling thread's start() method? This is going to block the JTAPI event thread itself as it will process your play file logic on on the current thread(JTAPI's Event thread) itself. Also, look at packet traces on whether your RTP sender is sending RTP packets from your host machine, and see if the firewall is allowing RTP stream(s)

Abhishek Malhotra 2013-05-17T00:35:22Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15347585 2013-05-16T22:03:22Z 2013-05-16T22:03:22Z

Any particular reason why you are answering the call on RP before transferring? You could actually redirect/route(selectRoute) the call when it is actually Ringing(ie. after accepting the call) on RP

Abhishek Malhotra 2013-05-16T22:03:22Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=15347338 2013-05-16T21:56:25Z 2013-05-16T21:56:02Z

Are you setting RTP parameters for RP after the call gets connected? If not, the call might go down by the time transfer is done and might result in InvalidStateException.  

Abhishek Malhotra 2013-05-16T21:56:02Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13317257 2013-03-20T21:35:31Z 2013-03-20T21:35:31Z

CTI Port should be added to JTAPI user's controlled device list. Once added, you can refer it via following API: CiscoProvider.getTerminal(CTI_Port_Device_Name);  

Abhishek Malhotra 2013-03-20T21:35:31Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=13272413 2013-03-19T23:08:31Z 2013-03-19T23:08:31Z

CTI Ports needs to be registered by an application. Once registered it will show status and registered and IP Address of application registering it. Please refer to Javadocs of Register() APIs on CiscoMediaTerminal  

Abhishek Malhotra 2013-03-19T23:08:31Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7928287 2012-10-22T11:30:10Z 2012-10-22T11:30:10Z

Have you registered feature that enables register/unregister event for a terminal? Application needs to use registerFeature api to register feature "CiscoFeatureID. TERMINAL_REGISTER_UNREGISTER_EVENT_NOTIFY" in order to get CiscoProvTerminalRegisteredEv/CiscoProvTerminalUnRegisteredEv events when device registers/unregister.

Abhishek Malhotra 2012-10-22T11:30:10Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=7709010 2012-10-16T16:24:33Z 2012-10-16T16:24:33Z

What CUCM / JTAPI Version are you using?  

Abhishek Malhotra 2012-10-16T16:24:33Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=6325945 2012-08-22T13:36:54Z 2012-08-22T13:36:54Z

CallCtlTermConnTalkingEv for calling side doesnt indicate that the far-end(called party) has answered the call. Pleae look at Connection and TerminalConnection state diagrams in javadocs.   TerminalConnection for calling side will go to Talking state as soon as call is initiated.   The far-end(Called party) answering the call would trigger called party connection state to be changed to Established. This is where you get ConnEstablishedEv for Called side. If the called side is internal and observed, you would also get TermConnTalkingEv for called side TerminalConnection here. For Media handling you should rely on ConnEstablishedEv for called side along with media events (RTP Input/Output Started Ev). These RTP events would actually indicate if media stream is up or not.

Abhishek Malhotra 2012-08-22T13:36:54Z Abhishek Malhotra http://developer.cisco.com/c/message_boards/find_message?p_l_id=&messageId=6293871 2012-08-16T11:51:56Z 2012-08-16T11:51:56Z

Yes, As far as the numbers are instance of CiscoIntercomAddress. Please refer to javadocs for CiscoIntercomAddress and connectIntercom API.

Abhishek Malhotra 2012-08-16T11:51:56Z