GoESL 与时间：呼叫并非源自 FreeSWITCH 中的某个点

Question

我正在将 GoESL (https://github.com/0x19/goesl) 与 Temporal 集成，以通过 FreeSWITCH 自动拨号。该设置允许 1,000 个并发通道和每秒 50 个调用 (CPS)。每次拨号尝试都会启动一个临时工作流程，该工作流程通过活动发起呼叫。

成功发起 91 个呼叫（可变号码）后，FreeSWITCH 不再处理任何进一步的呼叫。 CLI 中没有日志，事件套接字层中没有事件指示进一步的尝试。但是，如果我停止 Temporal Worker，之前“卡住”的调用会出现在 FreeSWITCH CLI 中，表明它们已由 GoESL 客户端排队。我可以确认工作人员不会陷入困境，因为它继续启动主要工作流程。

以下是相关代码片段：

线索处理循环：

for _, lead := range leadResult.Leads {
    // [omitted setup and checks]

    // Checking for channel availability and sleeping to respect CPS limits
    workflow.Await(ctx, func() bool {
        return dialerQueryResponse.AvailableChannels > 0
    })

    timeToSleep := time.Second / time.Duration(dialerQueryResponse.CallsPerSecondLimit)
    workflow.Sleep(ctx, timeToSleep)

    // Dialing the lead
    fmt.Printf("dialing lead %s\n", lead)
    dialLead(lead, selectedDialer.Id, callTimeout) 
    fmt.Print("lead dialed\n\n")
}

拨号导联逻辑：

dialLead := func(lead string, selectedDialerId, dialerCallTimeout int) {
    // Setup child workflow context with unique ID
    cwo.WorkflowID = fmt.Sprintf("Campaign_Call_%s", lead)
    childCtx := workflow.WithChildOptions(ctx, cwo)

    // Struct to pass input to the child workflow
    input := domain.CallWorkflowInput{
        Lead:                lead,
        DialerId:            selectedDialerId,
        CampaignName:        cds.CampaignName,
        DialplanExtension:   cc.Survey.DialplanExtension,
        CallTimeout:         dialerCallTimeout,
    }

    // Executing the child workflow and handling its future
    future := workflow.ExecuteChildWorkflow(childCtx, CallWorkflow, input)
    var dialerId int
    selector.AddFuture(future, func(f workflow.Future) {
        err := f.Get(ctx, &dialerId)
        // Error handling and updating concurrency state
        // ...
    })
}

调用工作流程功能：

func CallWorkflow(ctx workflow.Context, input domain.CallWorkflowInput) (int, error) {
    // [omitted setup]

    // Executing the originate call activity
    var dialLeadResult domain.DialLeadResponse
    if err := workflow.ExecuteActivity(ctx, activity.Dialer.OriginateCallActivity, dialInput).Get(ctx, &dialLeadResult); err != nil {
        // Error handling
    }

    // [omitted post-call handling]
}

依次执行发起呼叫活动：

func (a *DialerActivities) OriginateCallActivity(ctx context.Context, input domain.DialLeadRequest) (domain.DialLeadResponse, error) {
    // [omitted client selection]

    // Command to originate the call
    cmd := fmt.Sprintf("originate {%s}%s/%s/%s 704 XML default test %s 10", variables, protocol, gateway, input.DestinationNumber, input.OriginatingNumber)
    err := selectedClient.BgApi(cmd)

    if err != nil {
        // Error handling
    }

    // [omitted response preparation]
}}, nil
}

是否有人在 GoESL 或 Temporal 方面遇到过类似问题，其中调用似乎在排队并且超过某个点后未执行？关于如何调试这种情况或者为什么终止临时工作线程可能会触发排队调用的处理有什么建议吗？

我尝试过的：

• 确保遵守油门限制。
• 使用 FreeSWITCH CLI 进行调试并检查 CDR。
• 查看 FreeSWITCH 日志以尝试查找任何异常情况。
• 尝试在 FreeSWITCH 设置中记录 GoESL 事件的日志，但是没有将任何日志写入该文件。
• 将

  workflow.Sleep

  持续时间从几毫秒修改为 5 - 10 秒，以确保不是网络延迟导致问题。
• 确认我的代码或日志中不会抛出任何错误，直到工作流程被终止。
• 停止了 FreeSWITCH 实例，以确保这不是 GoESL 和 FreeSWITCH 之间的通信问题。停止 FreeSWITCH 实例时，日志指示通信失败。否则我不会收到任何日志。
• 研究：在 Google 上找到这篇文章（https://lists.freeswitch.org/pipermail/freeswitch-users/2019-May/131768.html），它似乎与我们遇到的相同问题有关，但是，没有解决办法。

Answer 1

决定用不同的 GoESL 包 (https://github.com/percipia/eslgo) 替换 GoESL 包 (https://github.com/0x19/goesl)，问题已得到解决。似乎是初始 GoESL 包中的一个根本问题。我将在 Github 存储库上打开一个问题，并在此处弹出链接，以防将来有人遇到同样的问题😊。