Support

So, for this setup - we can see that the 9f410e4d31394a94a8718311e0469730 was hanged up almost immediately: calls/cs.medflyt.com/sessions/9f410e4d31394a94a8718311e0469730 :

{
  "domain": "cs.medflyt.com",
  "destination": "13473151770",
  "callerId": "19292364749",
  "direction": "application",
  "token": "9f410e4d31394a94a8718311e0469730",
  "createdAt": "2023-08-17T08:53:43Z",
  "modifiedAt": "2023-08-17T08:53:44Z",
  "status": "cancel",
  "startTime": "2023-08-17T08:53:43.917Z",
  "endTime": "2023-08-17T08:53:44.607Z",
  "profile": {
    "inbound-trunk-id": 471,
    "inbound-trunk-name": "aws-inbound",
    "callId": [
      "7c835141-a929-4a1a-8d9f-b274fbc0fc4f"
    ],
    "errors": [
      "Caller hangup"
    ],
    "application": [
      {
        "time": "2023-08-17T08:53:44.576432782Z",
        "url": "https://api.medflyt.com/voice_application",
        "source": "<Response>\n                <Play>https://medflyt-ivr-recordings.s3.amazonaws.com/transfer-to-next-available-agent.87551aa8-8e59-4e5d-94b6-8bcf73b79cd0.mp3</Play>\n                <Play loop=\"3\">http://com.twilio.music.guitars.s3.amazonaws.com/Pitx_-_A_Thought.mp3</Play>\n                <Play>https://medflyt-ivr-recordings.s3.amazonaws.com/we-will-get-back-to-you-shortly.e8fcaf62-6ad3-4ea3-bf74-9c33dc161edf.mp3</Play>\n    </Response>"
      }
    ]
  },
  "lastError": "Caller hangup"
}

The call lasted from 08:53:43.917 to 08:53:44.607 - just under a second.

The agent's session - 20061b2b552841a5b1deb669367e0736 actually started at 08:53:49.354, after the call was disconnected. When your server sent the switch application command to Cloudonix - the call could not be switched and the Cloudonix API sent back an error response, as we can see in the server access log:

[Thu, 17 Aug 2023 08:53:50 GMT] "POST /calls/cs.medflyt.com/sessions/9f410e4d31394a94a8718311e0469730/application HTTP/1.1" 400 98 "-" "-" 65ms

The HTTP response should have had the body {"status":"false","message":"Session application may only be updated when the session is connected"}, but we obviously don't have logs for that.

I think in this situation, your application should detect that the call was disconnected - either immediately when the caller hanged up, by registering for the session status update callback, or just handle the response from the Application Switch command. If you're not sure why the Application Switch command failed (returned an error), you can retrieve the session object directly and look at it - in this case we can see that its status was cancel - which means the caller has hanged up.

One problem is that we current return error 400 "Bad Request" for various invalid conditions, and checking the body of the response may not be the most straightforward way of understanding the cause of the issue, so we are updating the API so that Application Switch commands that were sent to a session in invalid state (already disconnected), will return 404 - this basically means that the session was "deleted" (session disconnect is done by sending DELETE to the session canonical URL), hopefully it will be easier to figure out the meaning of the response.

Please let me know if you have any further questions, or if you'd like us to look at other cases.