[OpenSIPS-Users] Re-homing a large number of subscribers

[Ben Laing]

Hi folks,

I’m using OpenSIPs as a load balancer in an active/active setup. I’m trying to set up call re-homing when a node in the cluster goes down, largely following https://blog.opensips.org/2019/10/03/re-homing-your-calls-with-opensips-3-0/ . I’ve got separate shtags lb1 and lb2 for each node.

When the cluster down is detected, I am running a python script that sets the remaining node as active then aims to rehome the calls in progress. Currently, that works by getting dlg_list_ctx, then running dlg_send_sequential for each dialog with a shtag matching the down node (dialog[‘context’][‘values’][‘dlgX_shtag’].


That’s fine for a few calls, but fails when we get to a few hundred because the dlg_list_ctx throws an error:
Jul  9 09:47:00 ip-10-4-40-11 /usr/sbin/opensips[83438]: ERROR:core:print_mi_response: Failed to print JSON

Jul  9 09:47:00 ip-10-4-40-11 /usr/sbin/opensips[83438]: ERROR:mi_http:mi_json_answer_to_connection: failed to print json response


Any ideas recommendations on how to tackle this?

I could use dlg_list_ctx specifying an index/counter to complete in batches, but I’m not quite sure how the indexing works so there’s a worry we’d miss calls. E.g. we do calls 0-40 then 41-80 but if call 0 ends while processing 0-40, does that mean call 41 becomes call 40 so it’s missed from the 41-80 batch.

Probably the best solution I have at the moment is to query the DB directly to get the definitively list of call ids, then run dlg_list_ctx specifying and iID then dlg_send_sequential if appropriate. Or just don’t bother checking and run dlg_send_sequential on them all.

Any thoughts / suggestions?
Best,

‑‑‑‑‑
Ben Laing

He/Him
Senior Software Developer
Email: ben.laing at dals.co.uk
Website: www.dals.co.uk<http://www.dals.co.uk/>
Dals, Statham House, Talbot Rd, Stretford, Manchester, M32 0FP



Classified - General
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20250709/8f3cff0b/attachment-0001.html>