Question about liveCalls array

[nbix0]

Hello,

Everything works perfectly with LiveStreaming, and the call-ids are immediately populated in the 'liveCalls' array upon capturing any inbound or outbound call through the SPAN port. However, I've noticed that occasionally, call-ids linger in the array even after the calls are terminated, particularly in cases of unanswered calls or when the person rejects the call.

For example, even when the call is terminated the liveCall may linger anywhere from around 1-2 minutes.

Ive noticed that its typically happening upon inbound calls into the system.

{
  "liveCalls": [
    "07214a06-85b3-4bbc-82e7-031f0e094025"
  ]
}

My guess is that even though the call is terminated, somehow the session is staying alive. Might there be a concise explanation for this behavior and a way to mitigate it? Ideally, the callid will be flushed upon immediate termination of the call, whether answered or unanswered.

It is important to also mention, that the streamCalls array does not exhibit this behavior.

Thank you!

[kingster]

The liveCalls array is populated from VoIpSessionsSingleton::instance()->getByIpAndPort(), which seems to remove the entries after some expiry period in some cases [Hoover construct] , and hence you see the same effect.

streamCalls is managed by the plugin and is cleaned up the moment a stop command is received.

[nbix0]

Thank you. Can this expiry period that is defined by the Hoover construct be modified, or is it a parameter within config.xml that can be changed?

[kingster]

I don't see the option there. What is the actual problem that you are facing?

[nbix0]

This may just be some weird fluke but I have simply noticed that when there is an inbound call that is terminated on the caller end (person calls and then hangs up without anyone answering) - the string that gets populated in the livecall array takes a while to clear.

[kingster]

And how is it affecting you? Could you explain what you are trying to achieve? Maybe there can be workarounds.

[nbix0]

I have developed a custom script that actively tracks the array contents and executes specific actions based on the array's data. Additionally, the script logs relevant events when strings are removed from the array.

I observed a minor latency in the expiration of stream keys associated with unanswered calls within the livecalls array. Consequently, a slight delay is noticeable between the caller terminating an unanswered call and the corresponding call-id key's expiration from the array.

Although this delay does not currently pose any significant challenges, I am interested in exploring the possibility of fine-tuning the expiration period to achieve real-time tracking of call terminations more precisely - however this is not at all blocking progress if this is not possible.

Please feel free to close this matter if you find it satisfactory. However, I welcome any input or suggestions you may have, as your feedback is valuable.

[kingster]

I have developed a custom script that actively tracks the array contents and executes specific actions based on the array's data. Additionally, the script logs relevant events when strings are removed from the array.

Is this to act something on the PBX or your other components in your eco-system? If that is so, I wouldn't recommend that it be based on the output of this /liveCalls, since this is purely from the recorder/streamer's point of view.

Although this delay does not currently pose any significant challenges, I am interested in exploring the possibility of fine-tuning the expiration period to achieve real-time tracking of call terminations more precisely - however this is not at all blocking progress if this is not possible.

Realtime tracking of call terminations would be better suited from a event_emitter of the PBX. What PBX do you have? If its a freeswitch you can probably look at mod_event_kafka which emits out event stream over kafka.

[nbix0]

Thank you for the response. That is certainly a valid proposal.

At this time this is currently not presenting any blockers for us, so I think this can be closed.

Thanks!