> A call session notification starts with a “Setup” event and ends with a “Disconnected” event.
> Basically, we can create a new active call object whenever we receive a “Setup” event.
> However, as I explained in my first blog, notification events may not arrive in the same
> order as they were generated due to some network situation.
This is exactly what I am doing, but instead of active calls per extension, I have a dictionary with the session-id (or telephony session-id) as the key and a sorted list of events for that call
> The out-of-order issue does not happen very often
It happens very often in my experience
> But we should still deal with that when it happens. There are 2 ways to solve the problem. The
> first way is to put all events from the same call session into an array then sort the array by the
> sequence numbers or by the event timestamp.
That is what I do, but how do I know in this case that the call ended and I am not going to receive more messages with the same session or telephony id in order to analyze the call? For Instance, if I receive this sequence:
```Setup, Setup, Disconnect, Procedding, Disconnect, ..., Aswered, Gone, Gone```
- How do I know the call ended based on the ```Disconnects```, because you will get a ```Disconnect``` per party involved?,
- How do I know I am not going to receive more messages after the last ```Disconnect```? (```Aswered, Gone, Gone```), so I can analyze the call and check/link to another call because it was parked?
- If the criteria to know a call ended is when all parties get disconnected, how do I know if I won't receive more messages with more ```Disconnects``` for other parties involved?
> The second way is to check the “activeCalls” array to see if an active call exists or not. If
> there is no active call with the same call party id, then we create a new active call object and
> add it to the “activeCalls” array. As we are preparing for the events out-of-order situation, we
> will check the event status from both cases. See the illustrated code below:
The last status of the call can be ```Disconnect```, and a new message comes with the status: ```Parked```, see my point?
@Phong Vu ?
Well, you can build your own logic to deal with the out-of-order events. I don't think that the delay is in minute, but rather just a second or (worst case a few secs). So when you receive the "Disconnected" event (remember that there are 2 "Disconnected" events, one for each call party), cause a delay for about 5 secs then sort the array using the event timestamps to put them in right order. Remember that for warm transfer call, the status of the original call is "Gone" and the "Disconnected" event will be sent when the transferred call is terminated.
You can try to use WebSocket subscription to see if the out-of-order is improved.
