我需要一些关于如何使用UCMA 4.0和Lync处理呼叫队列的帮助/建议。
我一直在研究一些UCMA 4.0核心文档,深入研究示例等,以找到开发调用队列的最佳实践。我一直在关注可信应用程序用户/参与者、会议和音频路由。
但是,在UCMA 4.0中,我应该使用什么方法来创建呼叫队列呢?
召开所有来电的会议,并由受信任的会议用户控制音频路由是否是正确的方式?据我所知,受信任的会议用户可以有数百个同步音频连接到同一会议,并决定谁可以听到谁,并为其他一些人播放等待的音乐,转接来电,到企业内的另一个UserEndpoint,等等。
我的方法是使用ApplicationEndpoint创建一个UCMA4.0应用程序。然后让会议作为我的来电队列(可以是Lync或PSTN呼叫),在我的UCMA应用程序中有一个受信任的会议用户来控制该队列(转接、处理AV路由以建立座席<>主叫方会话,以及可能让主管静默侦听特定音频路由等)。
但我不确定这种方法是否正确,或者由于限制和/或其他因素,我不确定是否有需要更改的地方。我寻求一些意见/建议,以便走上正确的轨道。
(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)
编辑:关于这一点的另一个想法。在我研究受信任的会议用户时,我在想,呼叫者是否可以呼叫会议/应用程序端点?我知道我可以通过一个UserEndpoint做到这一点,他喜欢在网上展示自己的存在。但是,由于TCU不能发布状态,并且隐藏在会议花名册中,是否有可能让我的用户呼叫会议?或者我应该有一个呼叫者呼叫的UserEndpoint,然后将呼叫者代理到会议队列??
发布于 2014-03-26 15:52:38
你绝对可以这样做。你必须做一些额外的工作,以确保呼叫队列中的所有人在等待同一会议时不能相互交谈(尽管这听起来是一种在等待连接时打发时间的有趣方式!)。然而,这种方法的伸缩性可能比替代方法更好,后者将是:
您可以让应用程序接受呼叫,并使用AudioFlow播放音乐。应用程序可以处理多个接受的呼叫,并可以保留这些呼叫,直到座席准备就绪,然后再转接这些呼叫。这可能比与会议打交道更容易。
我认为这两种方法都是可以接受的。会议方法将意味着,如果机器人重新启动,所有呼叫都不会掉线。应用程序方法将意味着您可以选择在用户等待时向他们播放定制的音频(队列中的第4位,队列中的第3位等)。
再想一想,我认为规模问题可能不是问题。无论您选择哪种方法,如果您的可扩展性足够高,您将开始达到需要添加额外硬件的极限,这只会发生在Lync基础架构中的不同位置,具体取决于您的方法。
https://stackoverflow.com/questions/22638794
复制相似问题