Hi,
Sorry if I missed any developments on this, but:
Kamailio does keep a runtime association of Call-ID+Ftag => RTPEngine instance, which is significant if an RTPEngine set with multiple members is used, or if a non-default set is used for a given call.
When Kamailio is restarted, this runtime association goes away, so any subsequent offer/answer cycles or any other commands will (maybe) go to the wrong RTPEngine and/or the wrong set.
Last time I checked a few years ago, there was no way to persist this association across restarts. Has this changed?
Thanks!
— Alex
Hello,
wasn't it hashing them to get the hash id, and that was used for selection of the rtpengine instance?
Cheers, Daniel
On 30.09.21 17:49, Alex Balashov wrote:
Hi,
Sorry if I missed any developments on this, but:
Kamailio does keep a runtime association of Call-ID+Ftag => RTPEngine instance, which is significant if an RTPEngine set with multiple members is used, or if a non-default set is used for a given call.
When Kamailio is restarted, this runtime association goes away, so any subsequent offer/answer cycles or any other commands will (maybe) go to the wrong RTPEngine and/or the wrong set.
Last time I checked a few years ago, there was no way to persist this association across restarts. Has this changed?
Thanks!
— Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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?
On Sep 30, 2021, at 12:44 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
wasn't it hashing them to get the hash id, and that was used for selection of the rtpengine instance?
Cheers, Daniel
On 30.09.21 17:49, Alex Balashov wrote:
Hi,
Sorry if I missed any developments on this, but:
Kamailio does keep a runtime association of Call-ID+Ftag => RTPEngine instance, which is significant if an RTPEngine set with multiple members is used, or if a non-default set is used for a given call.
When Kamailio is restarted, this runtime association goes away, so any subsequent offer/answer cycles or any other commands will (maybe) go to the wrong RTPEngine and/or the wrong set.
Last time I checked a few years ago, there was no way to persist this association across restarts. Has this changed?
Thanks!
— Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone)
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).
Cheers
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?
On 30/09/2021 13.34, [ EXT ] Alex Balashov wrote:
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?
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
Yeah, but what happens if I handle an offer/answer with an overridden set ID — let’s say that ID value comes from a database query or API or whatever at initial INVITE processing — and then I restart Kamailio, and then a reinvite occurs.
If I don’t know which set was used, the offer/answer cycle will audio for the call, since whatever RTPEngine is hit up by default will say “I don’t know that Call-ID” and the SDP substitution of media endpoints won’t take place.
I deal with this now by storing the set ID in an RR attribute. A custom $dlg_var(…) would work in modern Kamailio too, I’m sure.
But both are a little messy. What I was trying to ascertain is whether there is some way, non-obvious to me, that the RTPEngine control module can persist these associations.
— Alex
On Sep 30, 2021, at 1:46 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 30/09/2021 13.34, [ EXT ] Alex Balashov wrote:
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?
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
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Alex Balashov -
Daniel-Constantin Mierla -
Richard Fuchs