Hi,
When using a single RTPEngine, or a single RTPEngine per set, it is possible to make stateless RTPEngine calls from Kamailio, since everything is keyed by Call-ID + tag.
In other words, one can set up a call, answer it, restart Kamailio, and still send a 'delete' to RTPEngine successfully because there's no runtime state that needs to persist within Kamailio.
How does this work with multiple RTPEngines in a set? There is clearly some runtime state being kept to map (Call-ID, tag) => <RTPEngine instance within a set>, otherwise successive stream management commands would be round-robined within the set just like initial 'offer' commands.
I take it this association is lost across Kamailio restarts, since I see no mechanism to persist it. Does that mean that subsequent stream management commands (e.g. updated 'offer' / 'answer' on re-INVITE, 'delete' on BYE) are blasted out to all instances within a set prophylactically? Or is the recipient instance chosen at random as it would be with an initial 'offer' command?
Thanks,
-- Alex
I found this from 2015...
https://github.com/kamailio/kamailio/pull/390
If it's still holding true, looks like it's rehashed?
--fred
On Mon, 2020-05-25 at 18:02 -0400, Alex Balashov wrote:
Hi,
When using a single RTPEngine, or a single RTPEngine per set, it is possible to make stateless RTPEngine calls from Kamailio, since everything is keyed by Call-ID + tag.
In other words, one can set up a call, answer it, restart Kamailio, and still send a 'delete' to RTPEngine successfully because there's no runtime state that needs to persist within Kamailio.
How does this work with multiple RTPEngines in a set? There is clearly some runtime state being kept to map (Call-ID, tag) => <RTPEngine instance within a set>, otherwise successive stream management commands would be round-robined within the set just like initial 'offer' commands.
I take it this association is lost across Kamailio restarts, since I see no mechanism to persist it. Does that mean that subsequent stream management commands (e.g. updated 'offer' / 'answer' on re-INVITE, 'delete' on BYE) are blasted out to all instances within a set prophylactically? Or is the recipient instance chosen at random as it would be with an initial 'offer' command?
Thanks,
-- Alex
-
Alex Balashov -
Fred Posner