我需要一些关于如何使用UCMA 4.0和Lync接近呼叫队列的帮助/建议。
我一直在研究一些UCMA 4.0核心文档，深入研究样本等，以找到开发调用队列的最佳实践。我一直在寻找受信任的应用程序用户/参与者，会议和音频。
但是我应该使用什么方法来创建使用UCMA 4.0的呼叫队列？
是否有正确召开所有来电的会议，以及拥有可信会议用户来控制音频路由的正确方式？据我所知，可信会议用户可以与同一个会议进行数百次同步音频连接，并决定谁可以听到谁，为其他人播放等待音乐，将来电转接到企业内的另一个UserEndpoint等。
我的方法是使用ApplicationEndpoint创建UCMA 4.0应用程序。然后将会议作为我的来电队列（可能是Lync或PSTN呼叫），在我的UCMA应用程序中拥有一个可信会议用户，以控制该队列（通过转移，处理AV路由以进行代理＆lt;＆gt;呼叫者会话，并且可能让主管静静地听取特定的音频路线等。）。
但我不确定这种方法是否正确，或者由于限制和/或其他原因我是否需要更改。我寻求一些建议/建议，以便走上正确的轨道。
编辑： 另一个想到这个。在我研究可信会议用户时，我在想，调用者甚至可以呼叫会议/应用程序端点吗？我知道我可以通过UserEndpoint这样做，他可以在网上找到存在感。但是，由于TCU无法发布在线状态，并且隐藏在会议名单中，是否可以让我的用户呼叫会议？或者我应该有我的呼叫者呼叫的UserEndpoint，然后将呼叫者代理到会议队列？
答案 0 :(得分：0)
你绝对可以这样做。您需要做一些额外的工作，以确保呼叫队列中的所有人在他们在同一会议中等待时不能互相交谈（尽管这听起来很相似一种有趣的方式来等待连接时间来消磨时间！）。但是，这种方法可能比替代方案更好地扩展，即：
您可以让应用程序接受呼叫，并使用AudioFlow播放音乐。应用程序可以处理多个已接受的呼叫，并且可以保留它们，直到代理准备就绪，何时可以转移它们。这可能比处理会议更容易。
我认为任何一种方法都是可以接受的。会议方法意味着如果机器人重新启动，所有呼叫都不会下降。应用程序方法意味着您可以选择在用户等待时播放自定义音频（排队第4位，排队第3位等）。
考虑更多，我认为规模问题可能不是问题。无论您选择哪种方法，如果您扩展得足够高，您就会开始达到需要添加额外硬件的限制，它只会发生在Lync基础架构的不同位置，具体取决于您的方法。