Call Queue approach with UCMA 4.0

Question

I need some help/suggestions on how to approach Call Queues using UCMA 4.0 and Lync.

I have been studying some of the UCMA 4.0 Core documentation, digged into the samples etc., to find the best practice to develop Call Queues. I have been looking on Trusted Application User/Pariticipant, conference and audioroutes.

But what approach should I use to create Call queues with UCMA 4.0?

Is it the right way to have a conference, where all incoming calls are being placed, and have a Trusted Conference User to control the audio routing? As I could understand, the Trusted Conference User can have hundreds of simultanous audio connection to the same conference, and decide who can hear whom, and play waiting music for some others, transfering incoming calls, to another UserEndpoint within the enterprise, etc...

My approach would be to create a UCMA 4.0 application with a ApplicationEndpoint. Then having a conference as my queue for incoming calls (which could be Lync or PSTN calls), having a Trusted Conference User in my UCMA app, to control that queue (with transfering, handling AV routes to make agent <> caller sessions, and possibly having a supervisor silently listening to a specific audio route, etc.).

But I'm not sure if this approach is correct, or if there is anything I need to change, due to limitation and/or other stuff. I seek some advices/suggestions, to get on the correct track.

(MSDN thread: http://social.msdn.microsoft.com/Forums/lync/en-US/16a13242-3e03-463c-b554-6b305e6cf00e/call-queue-approach-with-ucma-40?forum=ucmanagedsdk#16a13242-3e03-463c-b554-6b305e6cf00e)

EDIT: Another thought about this. In my studying about Trusted Conference User, I was thinking, is it even possible for a caller to call a conference/app endpoint? I know that I can do so with a UserEndpoint, who pusblish presence as online. But since a TCU can't publish presence, and is hidden in the conference roster, is it even possible to have my users calling a Conference? Or should I have a UserEndpoint that my callers calls to, which then proxy the caller to the conference queue??

Answer 1

You definitely can do it that way. You'd have to do a bit of extra work to make sure that all the people in the call queue couldn't talk to each other whilst they're waiting in the same conference (although that sounds like quite a fun way to pass the time whilst waiting to be connected!). However, that approach may scale better than the alternative, which would be:

You could have the application accept the call, and play music using an AudioFlow. The application can handle multiple accepted calls, and can hold onto them until the agents are ready, when it could transfer them. That might be easier than dealing with the conference.

I think either approach is acceptable. The conference approach would mean that if the bot got restarted, all the calls wouldn't drop. The application approach would mean you could choose to play customised audio to users whilst they wait (4th in queue, 3rd in queue etc).

Thinking about it more, I think the scale issue probably isn't an issue. Whichever approach you choose, if you scale high enough, you'll start to hit limits where you need to add extra hardware, it'll just happen in different places in the Lync infrastructure, depending on your approach.