我正在将 GoESL (https://www.codesou.cn/link/d9b64cee05c46d31b10b9869a3198a6d) 与 Temporal 集成，以通过 FreeSWITCH 自动拨号。该设置允许 1,000 个并发通道和每秒 50 个调用 (CPS)。每次拨号尝试都会启动一个临时工作流程，该工作流程通过活动发起呼叫。
成功发起 96 个呼叫（可变数量）后，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 %sn", lead)
dialLead(lead, selectedDialer.Id, callTimeout)
fmt.Print("lead dialednn")
}
拨号引导逻辑：
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)，该文章似乎与我们遇到的同一问题有关，但是，没有解决办法。
正确答案
决定更换 GoESL 软件包 (https://www.codesou.cn/link/d9b64cee05c46d31b10b9869a3198a6d ）使用不同的 GoESL 包（https://www.codesou.cn/link/8c8566b78ac2b99c542bef8c37cac179）和问题已经解决了。似乎是初始 GoESL 包中的一个根本问题。
我在此处的 Github 存储库上提出了一个问题 (https://github.com /0x19/goesl/issues/40）以防将来有人遇到同样的问题。
