Hello, we have a call queue with simultaneous routing to around a dozen agents. When we receive an incoming call, it rings on all available agents' softphones, as desired.

We've recently integrated the RC API such that we now display contextual incoming call alerts on our web-based UI. For each agent using our UI, if the API reports that their extension is attached to the call session (via a 'Account Telephony Sessions Event' with a 'Proceeding' status), we show an 'Answer' button (tied to the 'Answer Call Party' endpoint), allowing them to answer the call within our UI. The party identifier given within the event data is passed to the answering endpoint, which works fine.

The problem is when multiple inbound calls are ringing at the same time, this only works for the first call received. No other calls can be answered until the previous one stops ringing, making it impossible for an agent to choose which call to answer (effectively, to answer out-of-order).

For whatever reason the aforementioned 'Proceeding' events are not given for subsequent simultaneous ringing calls until the prior call leaves a ringing state. Once the prior call stops ringing, these are broadcast and our UI can offer agents the ability to answer the call.

The same behaviour seems to exist in the RC softphone as well; the 'Active Calls' tab only ever shows one ringing incoming call at a time, despite two or three ringing inbound calls being present; so I'm not sure if this is a limitation of the 'Call Queue' feature.

We can't seem to work-around/solve this with the API, because we need the party identifiers from the delayed events to be able to answer a call. I don't see a way to create new parties and force them onto the call session for the purposes of invoking the answering endpoint.

- Is this a limitation of 'Call Queuing', and is there an alternative that gives us the same behaviour, but avoids this limitation?

- Can we work around this by manipulating the call session parties with the API?