We are integrating with PureCloud trought REST api and we develop a custom connector for our custom CRM. We reproduced the way an agent sees the lifecycle of conversation in Purecloud on our front-end.
We built our code on the assumption that a conversation has the following lifecycle:
Your assumptions look correct. That is the lifecycle that the media goes through. The only caveat is that wrapup may still be pending when the interaction transitions to the terminated state. If wrapup is required, showing the interaction until it is applied is correct.
Can you elaborate on how this change has affected you? What we changed was that not all voice interactions were actually transitioning into the final terminated state. We are allowing that last state change to happen consistently now, where it previously only occurred in certain error cases.
The problem here is that since you've updated, all calls started transitioning from "connected" state to "terminated" state directly. And once we use the "disconnected" state to trigger some display and counter behaviors we are unable to transit states. Until now we have considered the "disconnected" state as a final state once the "terminated" state dont give us any logic meaning.
So it is the transition from "connected" to "terminated" correct? In wich situations it is used the "disconnected" state now?
That should not be the case. The change we made only applied to events that were previously being sent with the 'terminated' state but were being switched in-flight to suppress the terminated state. We did not change the number of events, or prevent an event which was in the 'disconnected' state previously from being sent. The interactions do now consistently end in 'terminated' which they were already doing in some situations. The only difference now is that they will always end here. But there should always be disconnected first, followed by terminated. If you have an example where you are not seeing that we can look into it as that sounds like a bug, but I have not been able to reproduce that yet.
If your application was not handling the terminated state at all it is likely that calls which encountered errors were not being handled correctly.
Logs indicate that every session on this conversation first sent a 'disconnected' state change followed immediately by a 'terminated' state change. None appear to have transitioned directly from 'connected' to 'terminated'. This is what we expected with this change. The 'disconnected' state is still sent exactly as it was before, but we follow up with the 'terminated' state consistently now where that was left technically incomplete before.
Can you elaborate on how you are observing these state changes? Are you polling the state of the interaction or using the stream of events provided by the platform?
We are using JavascriptSDK and we've created a connector to process websocket notifications. Our logic iterates through every notification sequencely and parse it into a local object that we will use to display the call.
What we are trying to say, is that along all this notifications, we cant find any with a state "disconnected". We have several with "alerting", "connected" and "terminated" states, but any in "disconnected". This behavior doesnt reflect the state cycle that you confirmed as a correct one.
The logs from our end clearly show the notifications being sent via the socket with the disconnected state present but we must be missing something in what we are diagnosing. Perhaps i'm looking at the wrong client receiving them, or some other transformation is happening.
for a sample call also shows me each individual state transition happening and events for both legs going through all the expected states.
I can say for certain that the actual code that was changed as part of this particular announcement cannot have suppressed the disconnect events. So if something else in the system is doing that, it’s a problem and not the expected result of this change. Let's handle this via the ongoing escalation.
We came to a conclusion that based on an assumption, (as we refered on the "escalation"), in the beggining of the project, we quickly verified that the information received in the websocket notification wasnt enought, and we started to use getConversation by id method to gather all the information every time a notification arrive. We use that information to process logic on our side, instead of websocktet notification info.
As we can tell, since your update, it appears that transition from disconnected to terminated state happens very quickly, and once we use another asynchronous method to gather the conversation information, we miss disconnected state.
We are going to do a deeper analysis in order to confirm this conclusion.
Everything you can get from a getConversation request should be available on the notification so if there's something missing from those notifications we can definitely look into augmenting that. We'll have to discuss timing since you've expressed a concern about the addition of new fields to any contracts, but the intention is for you to have enough information in those streaming updates to not need to poll the service.
The transition from disconnected to terminated will often be very fast. The only time there will be a significant delay between the two is in the event of some sort of connection problem where the call ends but the audio continues to play an error tone of some kind. This is the purpose of separating the two states. The final terminated state designates the end of the audio stream and the finalization of the call.
We found another issue, that we are wondering if that might be related with this same update.
When we start a transfer with consult Purecloud automaticaly set the attribute "consultInitiator" as true in the agent participant who have initiated the consult. We use that attr in our logic in order to manage the display behaviour. Since this update, as far as we call tell, this attr disappears from the conversation imediatly after a transfer is efffectivated (call changed to disconnected/terminated state).
Everything was working as expected, and the only thing that making our logic stop working is the fact that when the call change to disconnected state that attr isnt available anymore.
Can you please check if this behaviour is the one expected now, and if it changed during this last update?
There was no direct change to that fields behavior with the terminated state change. The change we made was a 1 line difference in the mapping of an enum of values. Previously, if the state was equal to 'terminated' in non-error session handling it was simply flipped to 'disconnected' to hide the terminated state. The change we made was to allow the 'terminated' value to persist. The same number of events and the same handling of those events should still be there.
It's possible that there's some other downstream impact that would be altering the consultInitiator field but I suspect that is unrelated. I'm also not completely clear on why you would be looking at the consultInitiator field on a disconnected/terminated session, but without the full details in front of me it's hard to say. If you can include an example and expand on the problem you are seeing we can take a look in more detail.
