McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 1174

↗ View in doc context
page
1174
source
cucm/v15/jtapi-dev-guide/jtapi-dev-guide.md
chunk_id
cucm::v15::jtapi-dev-guide::jtapi-dev-guide::1178

For cases 3 and 4, the call information depends on the order of events that JTAPI delivers. If JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events before the GC2-CiscoCallChangedEv, then the call information, such as calling and called addresses, will be what was seen in GC2. Conversely, if JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events after the GC2-CiscoCallChangedEv, then the call information, such as calling and called addresses, will be what was seen in GC1. As an example, if JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events before the GC2-CiscoCallChangedEv, the Calling Address = C, Called Address = Pickup Number. If JTAPI delivers the GC1-CallInvalidEvent/CallObservationEndedEv events after the GC2-CiscoCallChangedEv, the Calling Address = A, Called Address = B. These test cases were run with auto-pickup enabled and disabled, and there was much difference in the functionality of the two. Most of the test cases are enumerated below. The basic call from A to B is the same in all cases, and is only shown in the first case below. Scenario One Observing all devices and auto-pickup enabled. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1110 Message Sequence Charts Message Sequence Charts

Page 1174 content