GoESL vs. Temporal: Der Anruf kommt nicht von einem bestimmten Punkt in FreeSWITCH

Frageninhalt

Ich integriere GoESL (https://www.php.cn/link/d9b64cee05c46d31b10b9869a3198a6d) mit Temporal, um über FreeSWITCH automatisch zu wählen. Dieses Setup ermöglicht 1.000 gleichzeitige Kanäle und 50 Anrufe pro Sekunde (CPS). Jeder Wählversuch startet einen temporären Workflow, der den Anruf über eine Aktivität initiiert.

Nach 96 erfolgreichen Anrufen (eine variable Anzahl) bearbeitet FreeSWITCH keine weiteren Anrufe mehr. Es gibt keine Protokolle in der CLI und keine Ereignisse in der Event-Socket-Schicht, die auf weitere Versuche hinweisen. Wenn ich jedoch den Temporal Worker stoppe, werden die zuvor „steckengebliebenen“ Anrufe in der FreeSWITCH-CLI angezeigt, was darauf hinweist, dass sie vom GoESL-Client in die Warteschlange gestellt wurden. Ich kann bestätigen, dass der Worker nicht hängen bleibt, während er weiterhin den Hauptworkflow startet.

Die folgenden Codeausschnitte sind relevant:

Lead-Verarbeitungsschleife:

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")
}

Einwahl-Anleitungslogik:

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
        // ...
    })
}

Workflow-Funktion aufrufen:

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]
}

Führen Sie die Anrufeinleitungsaktivitäten nacheinander aus:

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
}

Ist jemand bei der Verwendung von GoESL oder Temporal auf ein ähnliches Problem gestoßen, bei dem Anrufe scheinbar in der Warteschlange stehen und ab einem bestimmten Punkt nicht mehr ausgeführt werden? Irgendwelche Vorschläge zum Debuggen dieser Situation oder warum das Beenden des temporären Arbeitsthreads die Verarbeitung von Anrufen in der Warteschlange auslösen könnte?

Was ich versucht habe:

• Befolgen Sie unbedingt die Einschränkungen.
• Verwenden Sie die FreeSWITCH-CLI zum Debuggen und Überprüfen von CDRs.
• Überprüfen Sie die FreeSWITCH-Protokolle, um etwaige Anomalien zu finden.
• Es wird versucht, GoESL-Ereignisse im FreeSWITCH-Setup zu protokollieren, aber es werden keine Protokolle in die Datei geschrieben.
• Ändern workflow.Sleep die Dauer von einigen Millisekunden auf 5–10 Sekunden, um sicherzustellen, dass das Problem nicht durch die Netzwerklatenz verursacht wird.
• Bestätigt, dass in meinem Code oder meinen Protokollen keine Fehler ausgegeben werden, bevor der Workflow beendet wird.
• Die FreeSWITCH-Instanz wurde gestoppt, um sicherzustellen, dass es sich nicht um ein Kommunikationsproblem zwischen GoESL und FreeSWITCH handelt. Beim Stoppen einer FreeSWITCH-Instanz zeigt das Protokoll einen Kommunikationsfehler an. Ansonsten erhalte ich keine Protokolle.
• Recherche: Ich habe diesen Artikel bei Google gefunden (https://lists.freeswitch.org/pipermail/freeswitch-users/2019-May/131768.html), der mit demselben Problem zu tun zu haben scheint, das wir hatten. Es gibt jedoch keinen Lösung.

Richtige Antwort

Beschlossen, das GoESL-Paket (https://www.php.cn/link/d9b64cee05c46d31b10b9869a3198a6d) zu ändern, um ein anderes GoESL-Paket (https://www.php.cn/) zu verwenden. link/ 8c8566b78ac2b99c542bef8c37cac179) und das Problem wurde gelöst. Scheint ein grundlegendes Problem im ersten GoESL-Paket zu sein.

Ich habe hier (https://github.com/0x19/goesl/issues/40) ein Problem im Github-Repository angesprochen, für den Fall, dass in Zukunft jemand auf dasselbe Problem stößt.

Das obige ist der detaillierte Inhalt vonGoESL vs. Temporal: Der Anruf kommt nicht von einem bestimmten Punkt in FreeSWITCH. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!