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).