two primary ways to observe addresses with Cisco JTAPI's CallObservers: an
application can observe all of the addresses with a single CallObserver object
or it can have a separate CallObserver object for each of address. These two
approaches cause slightly different events to be seen, mostly with regard to
application uses a single CallObserver to observe all the addresses, they are
connected with one object. When A calls B, both the events at A and at B are
sent to the same CallObserver object. If B redirects to C, and C was observed
with the same object, all its events are delivered to the same observer. The
application observes the CallCtlConnOfferedEv to C with reason REDIRECT,
because the observer at C knew all about the previous events on the call.
when an application uses an independent CallObserver for each Address, this
information is not so easily shared. When A calls B, call events of A go to the
observer for A, and B's go to the observer for B. They each know about the
other end, for example A will know that B is ringing, but they are no longer
the same observer. When B redirects the call to C, the observer at C knows
absolutely nothing about the call. The observer at C was not involved in the
original call at all, and does not know who is on it, what events had happened
previously. This information has to be made up by JTAPI to build an accurate
call model at C. All the call events for a basic call between A and B have to
be simulated so that the call model, from C's perspective makes sense.
done by using a snapshot event. JTAPI looks at the call, in this case the one
between A and B, and figures out what events have to have happened for the call
to exist the way it does. This makes up up the basic call events required, and
give them to the observer on C, so that it can build a proper call model.
event set is made up by JTAPI, the reason codes are not available. For example,
if A had originally called D, and D redirected to B, the made up snapshot event
set would not be concerned with the redirect at all. JTAPI does not store this
information anywhere, and when it generates a snapshot, it creates the simplest
event set possible to recreate the call model, and reports all the events with
So, when A
calls B, and then B redirects to C, the observer on C gets a snapshot event
that allows it to recreate the call model for a basic call from A to B. Also in
this snapshot event is the CallCtlConnOfferedEv for C. As part of the snapshot,
this event comes in with reason NORMAL, even though it is the result of a
redirect. CallObservers on A or B will see the CallCtlConnOfferedEv for C with
reason REDIRECT, but there is no way for the observer at C to know that.
creates a noticeable difference in the reason codes available to applications
depending on how they implement their CallObservers. There have not been any
issues regarding this from the customer side.
This is the
way it has been since Cisco JTAPI's inception and this is a clarification of
the existing behavior.