This document was generated from CDN thread
Created by: MichaelJ Lemen on 19-11-2008 08:14:39 PM
When the phone is controlled via JTAPI and CFW is enabled or disabled on they physical phone. A new call is created. Is there any way to detect a CFW enable/disable "call" from a normal call?
Thanks,
Mike
Subject: Re: Detect CFW enable/disable "call"
Replied by: Stephan Steiner on 20-11-2008 01:43:32 PM
Good question.. just noted that if we use the standard cfwd mechanism, I get calls I don't want necessarily want in the call log I'm keeping via JTAPI.
I haven't spent the time investigating yet but what I will do is change jtracer so that it dumps the result of CiscoCallEv.getCiscoCause and CiscoCallEv.getCiscoFeatureReason in the hopes that then the events will look different from the events I get for a regular call forward. Maybe this'll get me somewhere. If not, the only thing that comes to mind would be having a soft criteria.. e.g. if immediately after initiating the call, it is cleared again, it would be a callforward call (it is unfortunate that we don't get callforward state events like TAPI provides.. imho that would be a valuable addition to the existing termstate events). Looking at jtrace, it seems that a CallCtlConnOfferedEv is immediately followed by a CallCtlConnDisconnectedEv with CallControlCause.CAUSE_REDIRECTED.. I think this wouldn't happen in any regular scenario (unless you have cfwdnoanswer delay set to 0, but then I haven't tried if you can even do that.. it makes little sense.. and I suppose it would have to be at least 1 in which case we'd already have a noticeable difference in delay between the two events).
