Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager Release 7.1(3)
Caveats
Downloads: This chapterpdf (PDF - 356.0KB) The complete bookPDF (PDF - 10.49MB) | Feedback

Caveats

Table Of Contents

Caveats

Caveats for All Releases

Translation Pattern Support

DT24+ Limitation with PRI NI2 Trunk

Connection for Park Number Not Created

Inconsistency Between SIP and SCCP Phone

Failure to Route Calls Across Destinations

Incorrect Return Value for getCallingAddress()

Call Fails to Disconnect Held Shared Line

Limitation with sendData() API on CiscoTerminal

Caveats for Release 7.0.1

Inconsistency in getModifiedCallingAddress()

Conference Behavior for Selected and Active Calls

Change in GlobalizedCallingParty Behavior

Caveats for Release 6.0.1

Call History Might Get Lost When AAR Routes Over QSIG Trunk

Different Event Order if Consult Call Initiated on SIP Device


Caveats


This appendix provides details of the JTAPI caveats that are common across releases and those that are release-specific. This appendix contains:

Caveats for All Releases

Caveats for Release 7.0.1

Caveats for Release 6.0.1

Caveats for All Releases

This section lists the caveats that are common for all JTAPI releases.

Translation Pattern Support

If the callingparty transformation mask is configured for a Translation Pattern that is applied to the controlled addresses of JTAPI application, the application may observe some extra connections being created and disconnected when the application observes both calling and called party. Otherwise, a connection is created for the transformed callingparty and CiscoCall.getCurrentCallingParty() returns the transformed calling party address when the application observes only the called party. In general, JTAPI has a problem in creating an appropriate call connection and may not be able to provide correct callinfo such as currentCalling, currentCalled, calling, called, and lastRedirecting parties. For example, Translation Pattern X is configured with calling party transformation mask Y and calledparty transformation mask B; A calls X, and call goes to B. In this scenario:

If the application observes only B, JTAPI creates connection for Y and B, and CiscoCall.getCurrentCallingParty() returns Address Y.

If the application observes both A and B, connections for A and B are created, connection for Y is temporarily created and dropped, and CiscoCall.getCurrentCallingParty() returns Address Y.

Other inconsistencies could occur in callinfo if more features are used for basic call. It is recommended that you do not configure callingparty transformation mask for Translation Pattern which might get applied to JTAPI Application controlled Addresses.

DT24+ Limitation with PRI NI2 Trunk

When a PRI NI2 trunk used by DT24+ gateway is involved in a call scenario between two clusters, for example, A from cluster-1 calls B in cluster-2 via DT24+ PRI NI2 trunk, the LastRedirectAddress and CalledAddress may not be accurate on B's side. Besides, if there are any changes for A's side of the call in cluster-1 due to redirect, transfer, or forward, the changed information is not propagated to B's side due to protocol limitation of PRI NI2 truck.

Connection for Park Number Not Created

JTAPI does not create a Queued state connection for Park Number if the call is parked across the gateway. There are two possibilities here:

1. If CLI is configured, application sees an Unknown connection

2. If CLI is not configured, the calling does not see any Unknown connection.

For Example, If A calls B across gateway (with CLI configured) and B parks the call then A sees an unknown connection instead of a connection (with STATE=QUEUED) for Park Number.

But, if A calls B across gateway (with no CLI configured) and B parks the call then A does not see any new connection.

Inconsistency Between SIP and SCCP Phone

sendData() API on CiscoTerminal is used to send data to the phone. In case of SIP phones, if invalid byte data is sent by the application, the method throws PlatformException. However, in case of SCCP phones, the byte data sent in the request is not validated, and would return successfully without throwing an exception.

Failure to Route Calls Across Destinations

When a call is redirected to a device outside the cluster over an H323 gateway that is out of service, before call control can determine the Out-of-Service status of H323 gateway, the call is disconnected. This is because the default value of the service parameter CTI NewCallAccept timer is four seconds where as call control takes five seconds to determine that the gateway is out of service, so calls are disconnected due to expiration of CTI NewCallAccept timeout.

Implications of the above behavior is seen in JTAPI selectRoute() API which internally uses CTI redirect API to route the call. If applications specify multiple destinations with selectRoute() and the first destination is across an out-of-service H323 gateway, the call fails before JTAPI can route the call to the second destination. Hence JTAPI, cannot route the call to the second route specified in selectRoute() interface call.

To avoid this, the value of CTI New Call Accept Timer service parameter can be set as greater than H225 TCP Timer service parameter.

Incorrect Return Value for getCallingAddress()

In a transfer scenario, where caller and transferController are not observed, that is, where A calls B and transfers the call to C and the application is observing only C then before the transfer, JTAPI will not have any information about the first call (that is, call from A to B). So, when the transfer feature is invoked, the calling and called address are B and C respectively. On completing the transfer, application updates callInfo and JTAPI exposes the correct parties through getCurrentCallingAddress(), getCurrentCalledAddress(), getModifiedCallingAddress(), and getModifiedCalledAddress(). However, getCallingAddress() API which should return the original calling address still reports B, that is, the original calling party of B to C call.

To avoid this issue, application can observe the controller as well, so that JTAPI expose the correct party (that is A, in this case) with getCallingAddress() API.

Call Fails to Disconnect Held Shared Line

In a scenario where A calls B (B is a shared line present on terminals T1 and T2); privacy is set as ON for T1 and initially CUCM service parameter Enforce Privacy Settings on held calls is set to True. B(T1) answers and goes to Talking state while B(T2) goes to Passive state (TermConn=Passive; CallCtlTermConn = InUse). B(T1) puts the call on hold, since Enforce Privacy Setting on held calls is set to True, B(T2) remains in passive state (TermConn=Passive; CallCtlTermConn = InUse). Now the service parameter Enforce Privacy Settings on held calls is set to False. This does not trigger any change in the state of TerminalConnection, so B(T2) still remains Passive-InUse (TermConn=Passive; CallCtlTermConn = InUse). At this point, if the application sets the requestController as B(T1) and disconnects the call at B, the connection of B is not disconnected and call does not go IDLE. Even on the phones, the call on A remains in Established state while the other party in call is B(T2) which remains in Passive-InUse (TermConn=Passive; CallCtlTermConn = InUse) state. Call is cleared when A disconnects the call.

Limitation with sendData() API on CiscoTerminal

If JTAPI applications make simultaneous back to back requests for sendData() API on the same CiscoTerminal, without any delay between requests, then some of these requests may fail. Applications cannot determine whether a request was successful or not, as Cisco JTAPI API returns successfully as soon as the phone receives data and does not wait for a response from the phone. Also, the IP phone might display a blank screen on sending simultaneous requests to send data.

To avoid these issues, JTAPI applications should ensure some time delay between two successive sendData() requests while pushing XSI data to the IP phones via Cisco JTAPI.

Caveats for Release 7.0.1

This section lists the JTAPI caveats for Release 7.0.1.

Inconsistency in getModifiedCallingAddress()

When a call is made to a shared DN (Address shared) on two Terminals (A and B), configured with different Calling Party Transformation CSS, and try to transform the Calling Party differently through two different Calling Party Transformation Patterns, then JTAPI does not provide modifiedCallingParty consistently. In such a scenario, both devices send localization signals to call control to transform the calling party number and the one picked by call control first is used to transform the same and JTAPI returns that through getModifiedCallingAddress().

For Example, +918055552222 (Globalized Calling Party) calls JTAPI observed shared Line 3100 on Terminals A and B. Device A is configured to transform the calling party by removing International escape character where as, B is configured to transform the calling party by removing International Escape Character and country code 91. Then JTAPI cannot guarantee whether getModifiedCallingAddress(), that is, the Localized Calling Party, will return 918055552222 or 8055552222.

Conference Behavior for Selected and Active Calls

Following is the behavior when application issues conference request but selected and active calls are not part of the conference request:

Active Call on a Terminal is always added to the resulting conference when conference is invoked on a call on any address on that terminal.

Consider B1 and B2 are addresses on same terminal

A --> B1- GC1

C --> B1- GC2

D --> B2- GC3 (active call)

The application invokes GC1.conference(GC2) and results in A-B1-C-D in conference with GC1, although call with D was not part of the conference request.

Active conference call on a terminal is added to the resulting conference when conference is invoked on a call on any line on that terminal. In this case, the active conference call becomes the surviving final call (provided the application specified primary call is not a conference call). In this scenario, the application specified primary call is cleared after the conference. It is possible that the application specified primary call may not join the resulting conference and in that case the call is not cleared after conference is over.

Consider B1 and B2 are addresses on the same terminal and conf1 is a conference call with A-B1-C in conference with B1 as the controller

B1 --> D - GC1 (on hold)

conf1 - GC2 (active call)

B2 --> E - GC3 (on hold)

The application invokes GC1.conference(GC2, GC3).

This results in A-B1-C-D-E in conference with GC2 as the surviving call. Although application had specified GC1 to be the primary call, GC1 does not survive after the conference.

The same behavior applies for user selected calls that are not part of the conference request, but become part of the resulting conference as mentioned above.

The same behavior would apply to a regular conference with common controller. Consider A, B, C,D as lines on different terminals

A-->B - GC1

C-->B - GC2

D-->B - GC3 (active call)

The application requests GC1.conference(GC2). This results in A-B-C-D in conference with GC1. Although direct call with D was not part of the conference request, D will join the conference

Change in GlobalizedCallingParty Behavior

getGlobalizedCallingParty() returns the correct globalized calling number only in case of a basic call. In a scenario where A calls B, B answers. A and B are connected. In this case, if application requests for getGlobalizedCallingParty(), the API returns the globalized number for A. In case of features such as transfer or redirect where any of the party gets updated, getGlobalizedCallingParty() may not return the correct globalized number.

Caveats for Release 6.0.1

This section lists the JTAPI caveats for Release 6.0.1.

Call History Might Get Lost When AAR Routes Over QSIG Trunk

When a call is forwarded due to insufficient bandwidth (Call Forward No Bandwidth - CFNB) to another cluster over a trunk or gateway using QSIG, call history might get lost. If Phone A calls Phone B, which is in a low bandwidth location, with CFNB set to forward calls to Phone C, which is in a different cluster, and the QSIG protocol is used on the trunk/gateway, then the original called party and the last redirecting party might not get passed to the destination party.

Different Event Order if Consult Call Initiated on SIP Device

Scenario: Terminal A initiates a call to the shared line B/B' and which Initiates a consult call to Terminal C.

If the Shared Line is SIP device then the call events are :

B (active) receives: CallCtlTermConnHeldEv -> CiscoTermConnSelectChangedEv -> CallActive

B' (remote-in-use) receives: CiscoTermConnSelectChangedEv -> CallActive -> CallCtlTermConnHeldEv

If the Shared Line is SCCP device then the call events are:

CiscoTermConnSelectChangedEv -> CallCtlTermConnHeldEv -> CallActive on both the Terminals.