On Sep 30, 2021, at 1:32 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 30/09/2021 13.17, [ EXT ] Alex Balashov wrote:
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).
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?