【问题标题】:Answering Machine Detection (AMD) with Twilio.. But after the fact使用 Twilio 进行应答机检测 (AMD) .. 但事后
【发布时间】:2014-11-16 20:34:08
【问题描述】:

问题

想要检测来电是由人还是机器接听。

详情

我正在使用 Twilio。 Twilio 确实有这个功能。但是,在他们的系统中实现它的方式似乎不适合我的用例。

Twilio 使用应答机检测来控制呼叫流程。因此,Twilio 会在呼叫连接后等待几秒钟,以分析呼叫中的音频以查看它是否是应答机。在延迟呼叫并执行此分析之前,它不会继续连接呼叫。

对于我的用例。电话由人或机器接听的天气不会影响呼叫流程......因此没有必要延迟。它只影响以后需要的统计信息。即在这种情况下“我付钱接听电话的人实际上接听电话的频率,而不是错过电话并让它转到语音邮件?”

所有来电都转接到电话。通常是手机。

问题

有没有一种方法可以在事后检测到呼叫是否由人或机器接听,但使用 Twilio 不会延迟?

如果没有,是否有另一种我没有想到的模式可以用来实现相同的目标? (检测员工接听电话的频率,而不是未接电话的频率)

我考虑过的其他事情

  • 延长手机响铃次数,然后让 Twilio 接收语音邮件,而不是手机提供商的语音邮件。
    • 此解决方案的问题在于,许多手机提供商不允许您更改在语音邮件接听之前电话响铃的次数。更难的是不设置响铃次数。手机提供商可能需要或多或少的时间来定位手机,这会计入手机在进入语音邮件之前响铃的时间。
  • 在我自己的应用程序中实现应答机检测 (Python)
    • 这可能是一个可行的替代方案。这里的问题是,我对如何使用 Python 分析音频文件以查看它听起来像是人还是机器拾取的声音知之甚少。

【问题讨论】:

标签: python twilio audio-analysis


【解决方案1】:

首先介绍一下如何使用呼叫进度分析 (CPA) 来检测答录机的背景知识。应答机没有标准,因此没有良好的一致检测方法。所有系统都使用 CPA 来检测电话被接听时语音的持续时间。一个典型的人只会用“你好”来回答,而答录机会有更长的问候信息。 CPA 只是在通话开始时寻找语音的长度,如果超过某个阈值,则它会假定一个应答机。有些人还可以检测到答录机在留言时发出的哔声,但同样没有用于哔声的标准音调,因此也可能不一致。

我的观点是,没有一个系统在检测语音邮件系统方面具有 100% 的准确性,有些人甚至试图通过在语音邮件中添加“Hello”作为他们的问候语来欺骗这些系统。如果您想要准确性,您可以在开始时提供一个需要 DTMF 响应的简单提示。如果它转到语音邮件,系统将无法使用 DTMF 输入响应,因此您知道 1)您有一个语音邮件系统,或 2)您有一个没有响应的人。听起来在您的业务案例中,用户响应是有好处的,所以他们会这样做。如果某些系统需要通过让用户输入可识别特定人员的 PIN 来识别特定人员,它们会更进一步。

我认为您无法使用 Twilio 进行事后检测。如果你真的需要这个,我会使用Call Control XML (CCXML)VoiceXML。对于 CCXML,它实际上并不会在事后发生,而是并行发生。当您的 VoiceXML 应用程序正在运行时,CCXML 可以继续在后台运行,执行 CPA。您甚至可以从 CCXML 向其他 Web 服务发送消息,以在语音应用程序继续运行的同时更新后台 CPA 的进度。 Voxeo 有一个很好的 CCXML 实现。他们的 CTO 是这个 W3C 标准的主编。他们的 CPA 实施也是我用过的最好的。他们对答录机的检测是最好的,通常甚至可以捕捉到哔哔声。 Voxeo 的 CCXML 在线文档有一个good description on implementing answering machine detection

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多