Support #2083
closed
Medflyt - conference using switchVoiceAppliction
0%
Description
We have noticed an intermittent issue and I saw it live while doing some tests.
Here's the situation: When the client initiates a call and an agent answers, we aren't adding it to the call - we create a new conference and add the agent. Then, we utilize the "switchVoiceApplication" function to include the client in the conference. However, there are instances where the agent is in the conference, and the call abruptly ends for the client. This occurrence happens multiple times a day.
It seems that the problem might be related to the "switchVoiceApplication" function? Could you please investigate further? The session legs involved in this issue are: 9f410e4d31394a94a8718311e0469730 ( caller ) and 20061b2b552841a5b1deb669367e0736 ( agent ).
This is the technical flow:
- Client calls
- Agent using "sipStartCall" with a conference token ( the "voiceApplication" webhook creates a new conference with "startConferenceOnEnter: false" property ).
- On "onSessionConnected" function - we are calling our server, create a new response with dial conference ( to the relevant conference number ), property "startConferenceOnEnter: true" and then using "switchVoiceApplication" function with the response and the caller source session token to connect the client to the conference.
It works 95% of the time, but 5% fails with the scenario I mentioned.
Updated by Oded Arbel over 1 year ago
- Status changed from New to Resolved
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.