I have to develop an application which should be capable of tracking any missed call and any established calls between 2 parties. In order to do that after I got the provider, I registered an observer on that to notify my application for IN_SERVICE state. When the provider is in service, I got the addresses under the control of my user. For every address retrieved I add CallObserver. By doing this I was able to receive events as CallCtlConnEstablishedEv for established calls and CallCtlConnDisconnectedEv for disconnected ones. For getting the missed calls I tried to check the cause of the event when CallCtlConnDisconnectedEv is thrown. My problem isK the cause returned by getCiscoCause() is never equal to CiscoCallEv.CAUSE_NOANSWERFROMUSER. It is always returning 16 or 0. Could you please let me know what should I do in order to correctly catch missed calls and stablished calls precisely. I have attached implementation of my CallControlCallObserver observer. Thanks
Subject: RE: Event cause is not returned correctly Replied by: Mohan Potluri on 16-11-2009 10:39:29 PM When call is not answered and caller drops off in ringing state the state transitions / events are: CallCtlConnAlertingEv (indicating ringing state) and CallCtlConnDisconnectedEv. When call is answered the events are: CallCtlConnAlertingEv and CallCtlConnEstablishedEv.
Your code should look for these transitions for incoming calls to catch the missed ones. cause would 16 when caller drops the call after a few rings. If call is disconnected after ring timeout (3 minutes or so) you will see ConnFailedEv with CAUSE_NOANSWERFROMUSER. You need to handle ConnFailedEv or CallCtlConnFailedEv to get this cause. Let us know how it goes with these changes.
Subject: RE: Event cause is not returned correctly Replied by: vahid M on 17-11-2009 07:09:34 AM Hi Mohan,
The problem with your solution is that when the call is RINGING on called party the CallCtlConnEstablishedEv event is thrown EVEN if the called party has not yet picked up the phone. When called party picked up the phone CallCtlConnEstablishedEv is thrown again.
In case of CallCtlConnFailedEv that you mentioned, It is not thrown for a missed call. I simulated a missed call situation CallCtlConnFailedEvis is not get called.
As a result, I can not find out if the call has been answered by the called party or it is just a missed call.
The event cause 16 = CAUSE_NORMALCALLCLEARING . I have to get 19 which is equal to CAUSE_NOANSWERFROMUSER.
Subject: RE: Event cause is not returned correctly Replied by: Mohan Potluri on 17-11-2009 09:06:30 PM 2 CallCtlConnEstablishedEv will seen one for calling party and one for called party. The 2nd CallCtlConnEstablishedEv for called address should be seen only when call is answered. Can you attach JTAPI logs to get a better undestanding of what is happening? You may want to run jtrace sample app (c:\program files\jtapitools\) to check the events delivered by JTAPI.
Subject: RE: Event cause is not returned correctly Replied by: vahid M on 18-11-2009 06:31:23 AM I've attached a log file. This is the result of monitoring a particular address in case a calling party places a missed call. As you can see , in the situation of ConnDisconnectedEv there is no indication of a missedCall. Even in this sample trace application, cause of the events are CAUSE_NORMAL What should we do?
Subject: RE: Event cause is not returned correctly Replied by: vahid M on 25-12-2009 03:20:22 PM I did come up with a solution. I'm just sharing it in case someone is interested (this is not the best solution I suppose, but this is one way to deal with the problem). There are some minor issues left unresolved. I'm going to revise it later. 1. Have a Provider observer to get the IN_SERVICE state. It seems that any operations on the Provider need to be performed after the state of it is changed to IN_SERVICE. 2. When the provider is IN_SERVICE get all the addresses available by: provider.getAddresses(); 3. Register an observer for any address your are interested in (in my case all). I implemented CallControlCallObserver. 4. In callChangedEvent method look for instances of CiscoCallEv event to catch. 5. If the event was equal to CallCtlTermConnTalkingEv AND called and calling numbers were not empty you have 2 parties talking to each other. 6. If the event was CallCtlConnDisconnectedEv, in order to get a missed call you have to first check if 2 parties were talking to each other or not(this can be done by keeping track of any established calls registered in the stage 5 (can be done by keeping the records in the database. Of course this should be performed for period of time e.g. curentTime - 30second)) If there were no records in the established calls this is most probably a missed call.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
