GoESL vs Temporal : l'appel ne provient pas d'un certain point dans FreeSWITCH

Contenu de la question

J'intègre GoESL (https://www.php.cn/link/d9b64cee05c46d31b10b9869a3198a6d) avec Temporal pour la numérotation automatique via FreeSWITCH. Cette configuration autorise 1 000 canaux simultanés et 50 appels par seconde (CPS). Chaque tentative de numérotation démarre un flux de travail temporaire qui lance l'appel via une activité.

Après 96 appels réussis (un nombre variable), FreeSWITCH ne traitera plus d'appels. Il n'y a aucun journal dans la CLI et aucun événement dans la couche de socket d'événement pour indiquer d'autres tentatives. Cependant, si j'arrête Temporal Worker, les appels précédemment "bloqués" apparaissent dans la CLI FreeSWITCH, indiquant qu'ils ont été mis en file d'attente par le client GoESL. Je peux confirmer que le travailleur n'est pas bloqué car il continue de lancer le flux de travail principal.

Les extraits de code suivants sont pertinents :

Boucle de traitement des leads :

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

Logique de guidage par numérotation :

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

Fonction de workflow d'appel :

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

Exécuter les activités d'initiation d'appel dans l'ordre :

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
}

Quelqu'un a-t-il rencontré un problème similaire en utilisant GoESL ou Temporal, où les appels semblent être mis en file d'attente et non exécutés au-delà d'un certain point ? Des suggestions sur la façon de déboguer cette situation ou pourquoi la suppression du thread de travail temporaire pourrait déclencher le traitement des appels en file d'attente ?

Ce que j'ai essayé :

• Assurez-vous de respecter les restrictions.
• Utilisez FreeSWITCH CLI pour déboguer et inspecter les CDR.
• Vérifiez les journaux FreeSWITCH pour essayer de trouver d'éventuelles anomalies.
• J'essaie de consigner les événements GoESL dans la configuration de FreeSWITCH, mais aucun journal n'est écrit dans le fichier.
• Modifiez workflow.Sleep la durée de quelques millisecondes à 5 à 10 secondes pour vous assurer que ce n'est pas la latence du réseau qui est à l'origine du problème.
• Confirmé qu'aucune erreur n'est générée dans mon code ou mes journaux avant de terminer le flux de travail.
• Arrêt de l'instance FreeSWITCH pour garantir qu'il ne s'agit pas d'un problème de communication entre GoESL et FreeSWITCH. Lors de l'arrêt d'une instance FreeSWITCH, le journal indique un échec de communication. Sinon, je ne reçois aucun journal.
• Recherche : j'ai trouvé cet article sur Google (https://lists.freeswitch.org/pipermail/freeswitch-users/2019-May/131768.html) qui semble être lié au même problème que nous avons eu, cependant, il n'y a pas solution.

Bonne réponse

J'ai décidé de modifier le package GoESL (https://www.php.cn/link/d9b64cee05c46d31b10b9869a3198a6d ) pour utiliser un autre package GoESL (https://www.php.cn/ lien/ 8c8566b78ac2b99c542bef8c37cac179) et le problème a été résolu. Cela semble être un problème fondamental dans le package GoESL initial.

J'ai soulevé un problème sur le référentiel Github ici (https://github.com/0x19/goesl/issues/40) au cas où quelqu'un rencontrerait le même problème à l'avenir.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!