Support

The issue is when the third person enters the conference ( the second switchVoiceApplication request ) - it disconnects the first leg.
The status shown in the status_update record is "answer", but you can see the error "Remote conference unexpected status: CANCEL" and that the callEndTime is 2023-09-13T15:24:56.566Z - one second after the second switchVoiceApplication request ( 2023-09-13T15:24:55.079Z )

This is the first status_update record with the error:

{
"path": "status_update",
"legToken": "c7f824061bd14adf906e047de55960e3",
"status": "answer",
"title": "Request - Body",
"payload": {
"id": 7764971,
"domainId": 502,
"subscriberId": null,
"destination": "13473151770",
"callerId": "18664636743",
"direction": "application",
"token": "c7f824061bd14adf906e047de55960e3",
"createdAt": "2023-09-13T15:20:39Z",
"modifiedAt": "2023-09-13T15:24:56Z",
"timeLimit": null,
"status": "answer",
"vappServer": "172.24.41.229",
"callStartTime": 1694618440037,
"startTime": "2023-09-13T15:20:40.037Z",
"callEndTime": 1694618696566,
"endTime": "2023-09-13T15:24:56.566Z",
"callAnswerTime": 1694618455980,
"answerTime": "2023-09-13T15:20:55.980Z",
"profile": {
"inbound-trunk-id": 471,
"inbound-trunk-name": "aws-inbound",
"callId": [
"d150b57f-1da0-4050-acf7-d95e77c570d7",
"20eb8eaf405040a50194d8d5351916f8@172.24.41.229:9067",
"f5cb6ecf-f922-48b1-86f1-74d3f15207f5",
"4b699e2312e888b979c3160840d1e79d@172.24.41.229:9067"
],
"application": [
{
"time": "2023-09-13T15:20:46.988774140Z",
"url": "https://api.medflyt.com/voice_application",
"source": "\n https://medflyt-ivr-recordings.s3.amazonaws.com/transfer-to-next-available-agent.87551aa8-8e59-4e5d-94b6-8bcf73b79cd0.mp3\n http://com.twilio.music.guitars.s3.amazonaws.com/Pitx_-_A_Thought.mp3\n https://medflyt-ivr-recordings.s3.amazonaws.com/we-will-get-back-to-you-shortly.e8fcaf62-6ad3-4ea3-bf74-9c33dc161edf.mp3\n "
},
{
"time": "2023-09-13T15:20:54.419570898Z",
"url": "",
"source": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>d5039f63-5202-464b-914e-720775e1aa97"
},
{
"time": "2023-09-13T15:24:56.078459664Z",
"url": "",
"source": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>d5039f63-5202-464b-914e-720775e1aa97"
},
{
"time": "2023-09-13T15:24:56.589874229Z",
"url": "",
"source": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
}
],
"errors": ["Remote conference unexpected status: CANCEL"]
},
"lastError": "Remote conference unexpected status: CANCEL",
"eventId": "d46de7a3-edd2-4a27-b5ec-a3ea515c49c6"
}
}

A few things first:

1. status "answer" is a terminal status that is assigned to a dial when it completes after it was answered. If a session has multiple dial commands issued in it (as is the case for c7f824061bd14adf906e047de55960e3 then you can get an "answer" status multiple times. The status for "the call is now connected and ongoing" is "connected".
2. The "Remote conference unexpected status" message is a report for an unexpected value (at the time that the code was written), but the code that logs this is not an error handling logic and it does not represent an action taken. In the context of the use case where an application dials to a conference call but is then switched to another application (instead of the caller disconnecting from the conference, for example by using the "disconnect from conference" DTMF signal) - the CANCEL result is expected, and as I've mentioned in my previous comment, a future version of the application runtime will not issue this error report for such a case.

I've reviewed the session logs in as much depth as I can find, and I can't figure out exactly what went wrong - unfortunately, our permanent log storage does not record sub-second timing information and it definitely seems that a lot of stuff happened at 15:24:56 UTC - including switching from one conference dial to another and multiple delete events, and I'm pretty sure some log lines are missing. From what I can gather, the second conference was in "ringing" state before being answered, when something happened and the call got disconnected - it is unclear if this was due to the caller SIP session disconnecting, an error that was then not reported, or an REST API call to delete the session - we see evidence for all three situations.

There are some things that have clearly gone wrong in the process, even without addressing the wrong error message, including:

• The <Dial> action on the first conference application wasn't acted upon - it should have been sent after the application switch, which it didn't.
• The "call disconnected session end" handler not reporting the cause that it handled.
• The internal "hangup application block" (that you can see at the end of the session application log) firing twice.

We will issue an application runtime update to address all these issues later this week.

If you can forward us session tokens for other sessions that encounter this issue, please do so - I would like to get to the bottom of this.

Also, can you please explain why did your application send a new "switch application" command, from the conference that was running to a new application block with a dial to the same conference? This is a behavior that we did not expect and if this is something that is core to your use case, we should put this behavior into our internal test suite.

Hi Oded,

Thank you for the clarification!
We found on our side an edge case that could cause this issue - we fixed it and will see if we are getting this kind of error in other situations.
If we did - we will let you know.

Thanks.