/mcpWildcard Routepoint Interaction Before 8.0(1), Wildcard Routepoint scenarios were not supported by JTAPI. This behavior is maintained in this release, in the spirit of Backward Compatibility, but is still unsupported. A new Service Parameter has been introduced in 8.0(1), WildCardDN as Called Party, which fixes several issues in the call model for Wildcard Routepoint scenarios. When this service parameter is turned on, Wildcard Routepoints are fully supported by JTAPI. Inconsistent Address Type of ModifiedCalledAddress When a Call Is Made to a Hunt Pilot When a call is made to a Hunt Pilot, although the API call.getCurrentCallingAddress() will return an address of type CiscoAddress.HUNT_PILOT, the address type of the address returned by the API call.getModifiedCalledAddress() will not be CiscoAddress.HUNT_PILOT. This is because the modified address, as the name suggests, might be modified by application and getType() on modified address would return CiscoAddress.UNKNOWN or CiscoAddress.INTERNAL and JTAPI currently has no way to determine if that corresponds to a Hunt Pilot or not. Caveats for Release 7.0.1 This section lists the JTAPI caveats for Release 7.0.1. • Inconsistency in getModifiedCallingAddress(), on page 1717 • Conference Behavior for Selected and Active Calls, on page 1717 • Change in GlobalizedCallingParty Behavior, on page 1718 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: Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1717 Caveats Wildcard Routepoint Interaction