Telephony Session Events: How to know when a call was ended

> 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 ?