30 Sep
2021
30 Sep
'21
11:49 a.m.
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/
30 Sep
30 Sep
12:44 p.m.
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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
1:17 p.m.
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(a)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:
--
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/
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(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
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)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
1:32 p.m.
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
1:34 p.m.
On Sep 30, 2021, at 1:32 PM, Richard Fuchs
<rfuchs(a)sipwise.com> wrote:
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?
--
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/
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).
1: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).
2 p.m.
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(a)sipwise.com> wrote:
On 30/09/2021 13.34, [ EXT ] Alex Balashov wrote:
--
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/
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
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 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).
943
days inactive
943
days old
6 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Richard Fuchs