McDewey

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

Page 1780

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

Caveats for Release 8.0(1) This section lists the JTAPI caveats for Release 8.0(1). • Globalized Calling Party Number, on page 1716 • Conference Interaction with Chaperone Results in Unsupported Conference Chaining, on page 1716 • Wildcard Routepoint Interaction, on page 1717 • Inconsistent Address Type of ModifiedCalledAddress When a Call Is Made to a Hunt Pilot, on page 1717 Globalized Calling Party Number This caveat is a further clarification for Globalized Calling Party Number. With 8.0(1), there have been changes to the Call Processing and CTI layers that reflect the globalized calling party values that you see on the station more accurately. There are still some serious limitations with globalized parties: • The Globalized Calling Party Number is available on the called side. • The Globalized Calling Party Number is determined only when the call is offered. This applies to basic calls and for calls involving features. • The Globalized Calling Party Number does not change, even if the calling party changes. This is a clarification for the existing caveat Globalized Calling Party Number. • Globalized Calling Party will be applicable if the call is redirected, whether performed prior to call being connected or after call is connected. • Globalized Calling Party will not be provided after the these features are completed: Transfer, Conference, Unpark, Auto Call Pickup. Conference Interaction with Chaperone Results in Unsupported Conference Chaining If both caller and Chaperone complete conference, where caller completes conference before chaperone then the scenario results in Conference Chaining. As of release 8.0(1), such scenarios are not supported by JTAPI and currently connections for all the parties along with ConferenceChain connection are shown in a single call. For example, A calls B; call is intercepted by Chaperone (C1) which further consults B for conference. Before Chaperone completes conference, Caller(A) goes ahead and consults X for conference and completes the conference. After this, Chaperone(C1) completes the conference. This scenario would result in unexpected behavior from JTAPI Perspective. JTAPI could send CiscoConferenceStartedEv along with CiscoChainAddedEv. Also, after the conference, JTAPI shows connections for two Conference chains, A(caller), B, X, and C1(Chaperone) in the same call. This will be fixed in future releases by having connections of caller and X in one call which is chained to a different call with connections for C1 and B. The fix requires changes in multiple components which are tracked with CDETS: CSCtc76213(CTI), CSCtc76222(TSP), CSCtc76223(Conference) Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1716 Caveats Caveats for Release 8.0(1)