/mcpIn normal Hunt List calls, there are three connections, Calling, Hunt Pilot, and Hunt Member. When a call is made to the Hunt Pilot Directory Number, the call is offered to one of its members depending on the algorithm. The initial state of the call is Offering at the member. If members are not observed, the connection to Hunt Pilot goes through the normal states as CallCtrlConnection or Connection. If members are observed, connection to member goes to Offering state and the connection to Hunt Pilot goes to Established state. Applications must use the states of the observed party to track the state of the call. call.getCurrentCalledParty() for a call to Hunt Pilot returns an address of type CiscoAddress.HUNT_PILOT. If the Hunt List member is the called address and is not observed by the application, connection to the member is created only when the call is answered. CiscoHuntConnection extends CallControlConnection and can get into states that a call control connection could transition to expect for the network states. Hunt pilots are represented by CiscoAddress objects and getType () would return CiscoAddress.HUNT_PILOT. Only addresses returned for Cisocall.getCurrentCalledAddres () and CiscoCall.getCurrentCallingAddress () will have CiscoAddress.HUNT_PILOT type. When calls to hunt pilot are involved in transfer or conference operations CiscoTransferStartEv, CiscoTransferEndEv, CiscoConferenceStartEv and CicsoConferenceEndEv are not delivered. Applications should use CiscoCallChangedEv to identify surviving call. If consult calls or final call have CiscoHuntConnection, the application should not expect Transfer or Conference start and end events. When configured in broadcast mode, all Hunt List members ring simulatenously. In JTAPI, call connections and terminal connections for Hunt List members are created only for members observed by the application. Applications must enable this feature using the setHuntListFeatureEnabled (boolean) on CiscoJtapiProperties. This feature is disabled by default and applications are encouraged to adapt to the above call model and enable the feature using setHuntListFeatureEnabled () API. Observing a hunt list member without enabling the feature using setHuntListFeatureEnabled () is not a supported configuration and if observed, results in inconsistent call model and events. setHuntListFeatureEnabled() is introduced to enable applications that are currently using unsupported call scenarios with Hunt List to migrate to a supported model without breaking the existing functionality. Applications can also enable this feature by adding, HuntListEnabled = 1, to jtapi.ini file and restarting the application. Interface Changes CiscoHuntConnection, on page 411, CiscoConnection, on page 386, CiscoAddress, on page 289, CiscoJtapiProperties, on page 435 Message Sequences Hunt List, on page 1000 Backward Compatibility This feature is backward compatible. Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 104 Features Supported by Cisco Unified JTAPI Hunt List