ucma threading model/behavior question

I've read what's in the UCMA SDK doc on the threading model, and I gathered that each conversation (call) has its own queue of events, and I presume that multiple event queues can be serviced simultaneously by different threads.  We are curently load testing our application and when I look through the logs, what I see from a threading point of view doesn't seem to line up with this threading model (and at the moment makes no sense). The question I am leading up to is under load it appears that calls don't appear to be executing as if they were all running in their own event queues/threads. For example, we will see a few periods during our load tests where calls don't seem to be having their events serviced (and hence delayed), and then finally when they do, the event servicing seems to happen with several calls being serviced at exactly the same time, and by the same thread! Why would that be? This is actually happening while the call is still getting initialized (so we have done teh beginAccept and are waiting for the call to go to Established and for the flow to go to Active, so at this point the application is not doing anything, so it is not holding up any event servicing threads or blocking on anything. What I see in the log is a single thread start servicing the call state changed method for a bunch of different calls all at the same time, almost like something was preventing the call initialization to proceed for all these different calls, and then it this one thread finally runs and services the events for many different calls all at once. The same thread also appears to service the tone controller for a session (call). Each session has its own tone controller (as well has speech recognizers and synthesizers)

In our application there is one application endpoint that receives call and creates a new 'app session' object which implements the application. Each session registers for call state change events on the call it encapsulates. Here is some log output. The thread IDs are in square brackets ([]). You can see a bunch of calls all have their call state change events get serviced at the same time, when I am almost certain this should have been happening in a more distributed even fashion, and probably by different threads.

Note the CallIds from the log output are from the CallId of the Audio Video call being handled.

Note: The average CPU utilization during this test was less than 20% with a Max CPU utilization of around 50%, so the machine wasn't pegged; it's a new box with I think 16 cores or maybe 24, so I would expect a more nice even parallel behavior than what I see.

I've gone over the code many times. There no locks, not blocking calls that seem to apply here. Maybe if I understood better how threads are used by UCMA I could track down the issue.

Thanks for any help/advice on this.