简体   繁体   English

UCMA 4.0的呼叫队列方法

[英]Call Queue approach with UCMA 4.0

I need some help/suggestions on how to approach Call Queues using UCMA 4.0 and Lync. 我需要一些有关如何使用UCMA 4.0和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. 我一直在研究一些UCMA 4.0 Core文档,并深入研究了样本等内容,以找到开发呼叫队列的最佳实践。 I have been looking on Trusted Application User/Pariticipant, conference and audioroutes. 我一直在寻找Trusted Application用户/参与者,会议和音频路由。

But what approach should I use to create Call queues with UCMA 4.0? 但是,我应该使用哪种方法在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... 据我所知,受信任的会议用户可以与同一会议同时建立数百个音频连接,并确定谁可以听到谁的声音,并播放等待的音乐供其他人使用,将来电转移到企业内的另一个UserEndpoint等。 。

My approach would be to create a UCMA 4.0 application with a ApplicationEndpoint. 我的方法是使用ApplicationEndpoint创建UCMA 4.0应用程序。 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.). 然后将会议作为我的传入队列(可以是Lync或PSTN呼叫),在我的UCMA应用程序中拥有一个受信任的会议用户,以控制该队列(通过传输,处理AV路由以建立座席<>呼叫者会话,以及可能让主管默默地收听特定的音频路由等)。

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 ) (MSDN线程: 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. 我知道我可以使用UserEndpoint来做到这一点,后者会在线提示存在。 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? 但是,由于TCU无法发布状态并且被隐藏在会议花名册中,所以我的用户甚至可以呼叫会议吗? Or should I have a UserEndpoint that my callers calls to, which then proxy the caller to the conference queue?? 还是我应该有一个我的呼叫者要呼叫的UserEndpoint,然后将该呼叫者代理到会议队列?

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. 您可以让应用程序接听电话,并使用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). 应用方法将意味着您可以选择在用户等待时向其播放自定义音频(队列第4,队列第3等)。

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. 无论您选择哪种方法,如果规模足够大,您将开始达到需要添加额外硬件的极限,取决于您使用的方法,它只会在Lync基础结构的不同位置发生。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM