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.