Kamailio change rtpengine in mid-cal

[Myng]

I am encountering an issue regarding how Kamailio handles rtpengine node failures mid-call, and I would like to clarify the expected behavior.

The Scenario: I have a setup with multiple rtpengines (e.g., 4 nodes) all configured in the same pool with setid=0.

1. An initial INVITE arrives, and Kamailio successfully selects rtpengine-A for the call.

2. Later in the dialog, a re-INVITE occurs.

3. Coincidentally, rtpengine-A is unavailable at that exact moment.

4. Kamailio then automatically switches to a different rtpengine node in the set.

The Question: Based on my reading of an older issue (#2713), my understanding was that Kamailio should not change the rtpengine node mid-call, as a new node will not have the media state for the ongoing session.

Could you please confirm if my understanding is correct, or if Kamailio’s default failover behavior for mid-call transactions has changed recently?

Thank you for your time and insights!

[Richard Fuchs]

On 11/05/2026 12.37, Myng wrote:

The Question: Based on my reading of an older issue (#2713), my understanding was that Kamailio should not change the rtpengine node mid-call, as a new node will not have the media state for the ongoing session.

Could you please confirm if my understanding is correct, or if Kamailio’s default failover behavior for mid-call transactions has changed recently?

Out of curiosity, what do you expect to happen if a re-invite is made and the rtpengine instance responsible for the call is not available?

Cheers

[Tommy]

Hello Richard, 
Thanks for getting back to me.

To answer your question: if a re-INVITE is made and Kamailio cannot reach the original rtpengine instance responsible for the call, my expectation is that Kamailio should reject the re-INVITE without dropping the existing call.
For example, if the rtpengine_manage function fails to reach the node and returns an error, the Kamailio script could catch that result and return a "488 Not Acceptable Here" (or a 500-class server error) back to the caller. This allows the re-INVITE transaction to fail gracefully while keeping the underlying dialog alive.

[Myng]

Hi Richard, 
Do you have any comments? 

--
You received this message because you are subscribed to a topic in the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtpengine/gm3QCAtVOQc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/01fe9143-b0fe-45a7-aaee-da36ba20c5f9n%40googlegroups.com.

[Richard Fuchs]

I haven't had a chance to look at the code and compare it to what the docs say yet, but in general I would argue that the behaviour should be configurable at least. For you it might be beneficial to reject a re-invite when rtpengine isn't reachable, but for other users it might be beneficial to allow switching to a different instance mid-call, in particular since an unreachable rtpengine can easily mean that media has stopped flowing.

Cheers

You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/CAGBhiAmAhO2WS0Ab8ptyWqfgzoG40w0Wvnp4ZbJTyhj%3Dora3TQ%40mail.gmail.com.