Twilio实时音频流n8n解码失败及Deepgram转发适配问题求助

嘿，我来帮你捋捋这个问题！从你说的流程和贴的代码来看，核心问题大概率出在数据字段匹配和Deepgram的格式适配上，咱们一步步拆解：

首先排查最可能的坑：Twilio数据字段没取对 #

你代码里用的是$json.base64Audio，但Twilio通过WebSocket发送的实时音频数据，原始字段是嵌套在media.payload里的！也就是说，你的Webhook节点收到的JSON结构应该是类似这样的：

{
  "event": "media",
  "media": {
    "payload": "这里才是base64编码的音频数据",
    "track": "inbound"
  }
}

所以你代码里的$json.base64Audio根本取不到值，直接触发了base64Audio missing的错误，但n8n可能没把错误日志明显抛出来，导致你看到节点“没有输出数据”。

修正后的Function节点代码 #

我把代码调整了下，先确保能正确拿到Twilio的音频数据，同时优化了Deepgram的格式声明：

// 正确获取Twilio的media.payload字段
const base64Audio = $json.media?.payload;
if (!base64Audio) {
  // 加个日志方便你排查n8n到底收到了啥数据
  console.log('n8n收到的原始Twilio数据:', $json);
  throw new Error('未获取到Twilio的media.payload音频数据');
}

// 解码base64为Buffer
const buffer = Buffer.from(base64Audio, 'base64');

// 返回n8n可识别的Binary数据，同时明确Deepgram需要的音频参数
return [{
  binary: {
    audio: {
      data: buffer,
      // 明确指定采样率和声道，Deepgram对mulaw格式需要这些参数才能正确解析
      mimeType: 'audio/mulaw; rate=8000; channels=1',
      fileName: 'caller.mulaw' // 用mulaw后缀更贴合实际格式，避免混淆
    }
  }
}];

适配Deepgram的关键注意事项 #

Twilio的实时音频是mulaw编码、8kHz采样率、单声道，Deepgram完全支持，但要根据你用的接入方式调整：

• 如果用WebSocket实时转录（推荐，因为是流式场景）：
  • 你需要在n8n里新增一个WebSocket节点，先和Deepgram建立连接，连接时要发送初始化参数：

    {
      "type": "Settings",
      "model": "nova-2",
      "encoding": "mulaw",
      "sample_rate": 8000,
      "channels": 1
    }
    

  • 之后每收到一帧Twilio的音频，就把Function节点输出的binary audio数据通过WebSocket发送给Deepgram。
• 如果用HTTP接口转录（不推荐流式场景，适合批量）：
  • 用n8n的HTTP Request节点，选择「发送Binary数据」，选中audio字段。
  • 请求头设置Content-Type: audio/mulaw，同时在请求URL里加参数：?encoding=mulaw&sample_rate=8000。

额外排查步骤 #

• 先在n8n的Function节点里保留console.log($json)，运行后去n8n的日志里看，确认Twilio的media.payload数据确实传进来了。
• 你可以把解码后的buffer本地导出成文件，用Audacity导入测试（导入时选择mulaw、8kHz、单声道），确认音频数据是有效的。
• 检查n8n后续节点（比如WebSocket/HTTP节点）是否正确读取了Function节点输出的binary audio数据，有没有配置错误。

内容来源于stack exchange