30 Sep
2021
30 Sep
'21
8:46 p.m.
On 30/09/2021 13.34, [ EXT ] Alex Balashov wrote:
On Sep 30, 2021, at 1:32 PM, Richard Fuchs
<rfuchs(a)sipwise.com> wrote:
No there's no persistent state at all. I would suggest to always
explicitly select the appropriate set before every invocation of any
function (or at least once at the beginning of the script) regardless of
the use case.
Cheers
On 30/09/2021 13.17, [ EXT ] Alex Balashov
wrote:
Thanks for that. That accounts for how a Call-ID is mapped to a node within a set. But
what if the set ID chosen for a particular call is nonstandard, i.e. expressly overridden
with set_rtpengine_set()? Is that knowledge somehow available after a restart?
I’m not sure how the mapping works internally.
But whatever the operation is, is that value stored somewhere or possible to store
somewhere so as to persist across restarts in a turn-key way?
AFAICR the node is
selected based on a deterministic hash over the call ID. So as long as the config
doesn't change between restarts, the node selected from any particular call ID would
remain the same.
The exception is cases where the selected node was not available and the call then had to
go to a secondary fallback node. AFAIK this association is stored in memory only and would
be lost after a restart (which would become a problem if the previously unavailable node
is now back up).