PatchConversationsCallParticipantAsync to Answer call sometimes not working on first inbound call

  1. We log into Genesys PureCloud agent browser app.
  2. Then we log in with our Desktop .Net app
  3. Then we go on queue in Genesys PureCloud agent browser app.
  4. An incoming call comes in and the application receives the notification of it and records the conversation Id and knows the Participants and Calls and their ids in the conversation. Calls are indexed in a concurrent dictionary so they can be looked up by callID and related back to the conversation. The application receives events but due to a legacy interface, it tracks individual calls by call ID.
  5. The user sees the calls in the desktop application and can answer the call by double-clicking on it. And causes the following code to run called with the call ID of the call they double-clicked on.

From our logs we can see this code always runs and seems to work (from the perspective of the code), but sometimes on the first incoming call it doesn't actually connect the call to answer it. When it doesn't answer it the call can be answered from the Genesys Purecloud agent browser app, and then our desktop application gets the event that it is answered and displays the call as answered. Once a call has been answered from the Genesys Purecloud agent browser app, all the calls after that are able to be answered from our desktop app

`C#

    // To simplify the code example just do this here (we have a provider class that does this for us):
    private readonly IConversationsApi _conversationsApi = new ConversationsApi();

    // Mandatory method required for legacy interface
    // It was not async by design, but shouldn't block GUI
    public void Answer(string callId)
    {
        _logger.LogTrace($"For callId: {callId}.");

        var body = new MediaParticipantRequest
        {
            State = MediaParticipantRequest.StateEnum.Connected
        };

        // This is equivalent of what is done.  We have code that does essentially this
        // because we have all the calls indexed in a concurrent dictionary.
        // We know this is getting the correct conversationId and agent participantId from the logs.
        // Not including the code that does this because it is working 100% of the time.
        var (conversationId, agentParticipantId) = GetConversationIdAndAgentPariticipantIdFromCallId(callId);

        if (conversationId != null && agentParticipantId != null)
        {
            // We see this in the logs whenever the user clicks to answer the call:
            _logger.LogTrace($"For callId: {callId} using conversation ID: {conversationId}, agent participant ID: {agentParticipantId}.");

            // The enclosing method containing this code is not, by previous design,
            // an async method so we can't simply await with ConfigureAwait(false).
            // This locks up if we wait on the Gui thread where this gets called, so we 
            // have to wait for the task to complete on another thread.
            // This starts the async process and returns the task to track its completion
            var task = _conversationsApi.PatchConversationsCallParticipantAsync(
                conversationId, agentParticipantId, body);

            Task.Run(() =>
                {
                    try
                    {
                        task.Wait();
                        // We always see this, without exception thrown, whether it succeeded
                        // in answering (connecting) the call or not
                        _logger.LogTrace($"PatchConversationsCallParticipantAsync completed for callId: {callId}.");
                    }
                    catch (Exception e)
                    {
                        // We don't get an exception, whether it succeeded
                        // in answering (connecting) the call or not
                        _logger.LogError(e.ToString());
                    }
                }
            );
        }
        else
        {
            // We don't get this because it succeeds in finding the conversationId
            _logger.LogWarning($"No answer data found for call with callId: {callId}.");
        }
    }

`

If the API request is returning a successful status but the requested action is not being performed, first verify that the request it's making is in fact what you believe it to be (just to make sure it's not an unseen bug in your code). Then open a case with Genesys Cloud Care to continue to troubleshooting what's going wrong downstream of the API request. That investigation requires access to private information that is inappropriate for this public setting.

Thank you Tim.

If you are talking about the parameters to the PatchConversationsCallParticipantAsync method and the contents of the body, the contents of the body are constant and the parameters for conversationId and participant ID of the agent being alerted, I believe they are correct. I am logging that information as the events come in from the NotficationHandler subscription to topic v2.users.{userId}.conversations. The conversationId and agentParticipantId in the conversation that has match what is being passed into the PatchConversationsCallParticipantAsync method. By "agent" I mean the one that has the UserId of the logged in user retrieved by GetUsersMe().

Is there any possibility that even though I have received an event that indicates that the agent participant's call is alerting and it is has as its PeerId the call ID of the customer's call, that the system is not ready to answer the call? FYI: The code just requires the customer call just needs to be active (not disconnected or terminated), but I have observed that when the agent call alerting, the customer call is always connected already (even though it was initially Offering).

Also is there any possibility that for the first call to the conversation API, that "not working" is just "very slow" (I would add "unacceptably") such that I give up on in it and answer it in Genesys PureCloud agent browser app before the call rolls over? If so, is there a way to "prime the pump" so to speak?

*** UPDATED ***
Initially, by mistake, I was logging our call state as translated from Genesys PureCloud to the the legacy call state equivalent, which doesn't consider the customer "connected" until the agent answers. If fixed that and retried and got different results. Updated text below:

I a hunch, based on thinking about the possible call states of the customer call, I added a log to detect if when the agent call is alerting, the customer call might not already be connected. On all occasions where I observed it the customer call was already connected by the time the agent call was alerting. But I added a log to log the customer call state if that was not the case.

I just reproduced the issue and noticed that lack of the conditional log entry confirmed the customer call was already connected as expected, just as it is when it works. So that would not be the cause. That is probably a good log to keep in place though.

If and when it happens the log would read:
CallStateProvider GetAnswerCallDataForCall: Call being answered is not connected. It is Offering. Answering call by connecting agent being alerted may not succeed.

We have no ability to troubleshoot this further via the forum as we do not have access to your org's data to look into this. Please open a case with Genesys Cloud Care for further assistance.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.