我们如何使用 Firefoot 使我们的通话录音管道更加高效

sara428

的语音平台每天处理数百万个呼叫其中35%的呼叫被录音并上传到云端以供长期存储和客户访问。在当前的数据时代，通话录音是企业获取洞察并改善客户体验的重要信息来源。 到目前为止，Exotel 的录音管道由多个微服务组成，彼此紧密交互以将录音上传到最终目的地。录音必须遍历多个服务，其中每一跳都会为录音上传增加一些延迟。作为一家以客户为中心的初创公司，以及一支始终追求效率、可靠性和可扩展性的团队，保持服务的精益和务实对我们来说非常重要。因此，我们接受了改造录音管道以提高其效率的挑战。请随意跳至以下任何部分： 看看旧的录音管道及其带来的挑战 Firefoot 简介 – 新的录制管道 推出中的挑战： 结果 看看旧的录音管道及其带来的挑战 发起并桥接呼叫后，Cloud PBX 会将 Raw-WAV 格式的录音转储到电话服务器上的录音目录中。通话结束后，通话处理程序服务会执行一些音频处理步骤，例如混合、合并和编码。

呼叫处理程序完成音频处理后，会将音频文件存储在录音目录下。 者更新数据存储中的记录 URL 以获取呼叫详细信息。 上述管道中的挑战： 几乎有 4 个微服务紧密协作来完成一项任务。 音频文件的处理由负责处理呼叫执行的呼叫处理程序服务处理。在音频文件的处理过程中，每个调用（启用录音的情况下）都会阻塞一个线程，这意味 数据库 着此处理直接阻碍了调用处理程序服务可以处理的调用数量的可扩展性。 该管道在音频属性方面是静态的。音频编解码器、比特率、采样率等设置在此管道中不可配置或扩展。这使得实现传送不同类型录音（例如）等）的机制变得困难。 此管道需要额外的服务 (Recotrix) 来使用正确的记录 URL 更新数据存储。 有两种机制可以传送文件。一种是通拉取。从维护和监控的角度来看，这是额外的开销。 在云上的临时目录中存在额外的记录跃点，这需要一些额外的维护成本。 在服务器和云级别维护这些服务的额外开销也是一个挑战。 尽管录音上传的延迟不是很高（特别是考虑到它是一个管道），但由于涉及的组件数量较多，添加新功能会非常耗时。



此外，我们必须监控和维护管道中的多个服务，并根据需要额外运营工作的流量来扩展它们。最后，管道通过临时云存储将所有录音发送到最终的云存储目的地，可以对其进行优化以减少延迟和成本。 Firefoot 简介 – 新的录制管道 Firefoot 是一种队列工作服务，可以基于队列消息触发器执行多个任务。Firefoot 是处理整个录音流程的单一服务，客户现在将在最高效、最短的时间内收到录音。这将减少延迟并提高录制上传的可靠性。 新的录音管道流程 发起并桥接呼叫后，云 PBX 会将 WAV 格式的录音转储到录音目录。呼叫处理程序服务从流程执行器服务中读取音频编解码器、比特率、采样率等录音配置，这使得 firefoot 具有高度可扩展性/可配置性。呼叫结束后，呼叫处理程序服务将带有所有音频配置的录音作业排队到 Firefoot。呼叫处理程序服务还将记录作业保留在数据存储中作为后备路径。Firefoot 收到作业后，会对录音进行混合、合并和编码，最后将其上传到。 上述管道的改进： 使用单个服务来维护整个录音管道，而不是四个微服务。