This is the query I use to get the hunt groups from my system: select d.name, n.dnorpattern, r.fklinegroup, a.moniker from numplan n   inner join typepatternusage t on t.enum = n.tkpatternusage   inner join devicenumplanmap m on n.pkid = m.fknumplan   inner join device d on d.pkid = m.fkdevice   inner join routelist r on r.fkdevice = m.fkdevice   inner join linegroup g on g.pkid = r.fklinegroup   inner join typedistributealgorithm a on a.enum = g.tkdistributealgorithm where t.moniker = 'PATTERN_HUNT_PILOT' The moniker that is returned will be one of these: DA_TOP_DOWN, DA_CIRCULAR, DA_LONGEST_IDLE_TIME, DA_BROADCAST ... View more

Thanks dlender, That's basically the conclusion I came to. It's just frustrating because I'm spending time building in a complex layer of software that just receives events from JTAPI and tries to order them the best it can based on what events "should" come before other events for any given call. Then I just feed the events (in a better order) into the rest of my application. For example, sometimes I'll get a CiscoTransferStartEv before a CallActiveEv on the same CallID. I can re-order these two events and then send it into my application. This reordering does delay the events a few hundred milliseconds, but improves the accuracy of my product. ... View more

If I understand correctly, the poor ordering of events is introduced on the CTI server, not in the JTAPI client code; is that correct? I've also done testing where I run multiple instances of the JTAPI test tool on the same machine, connected to the same UCM. Comparing the event logs after performing test calls shows that the event orders differ slightly between the different instances of the JTAPI test tool on the exact same calls. Is JTAPI also introducing another layer of potential re-ordering, or is it always the server determining the order? ... View more