Does Kamailio UAC auth changing $T_branch_idx cause session matching issues in rtpengine?

[xiaofang han (hance)]

Hi everyone,

I have a question regarding the use of the via-branch=extra flag in rtpengine when combined with Kamailio’s UAC trunk authentication. I am concerned that the branch ID change introduced by UAC auth might break rtpengine’s offer/answer matching.

My Environment:

Kamailio version: 6.1.1
rtpengine version: 13.5.1.2

My Routing Script Setup:

I am using extra_id_pv to handle potential forking scenarios. My routing block looks like this:

modparam("rtpengine", "extra_id_pv", "$avp(extra_id)")

route[NATMANAGE] {
    $var(rtpp_flags) = "replace-origin replace-session-connection";
   
    if (is_request()) {
        if (!has_totag()) {
            if (!t_is_failure_route()) {
                $avp(extra_id) = @via[1].branch + $T_branch_idx;
                $var(rtpp_flags) = $var(rtpp_flags) + " via-branch=extra";
            }
        }
    }

    if (is_reply()) {
        $avp(extra_id) = @via[2].branch + $T_branch_idx;
        $var(rtpp_flags) = $var(rtpp_flags) + " via-branch=extra";
    }
   
    xlog("L_INFO", "NATMANAGE branch_id:$T_branch_idx ruri: $ru, method:$rm, status:$rs, extra_id: $avp(extra_id), rtpengine_manage: $var(rtpp_flags)\n");    
    rtpengine_manage($var(rtpp_flags));
}

Scenario 1: Without UAC Trunk Auth (Working normally)

When there is no 401/407 challenge, the $T_branch_idx remains the same for both the INVITE and the 200 OK.
Logs:

NATMANAGE branch_id:0 ruri: sip:12...@abc.com, method:INVITE, status:<null>, extra_id: branch_xx_0, rtpengine_manage: replace-origin replace-session-connection via-branch=extra
NATMANAGE branch_id:0 ruri: <null>, method:INVITE, status:200, extra_id: branch_xx_0, rtpengine_manage: replace-origin replace-session-connection via-branch=extra


Scenario 2: With UAC Trunk Auth (Potential Issue)
When the trunk requires authentication, Kamailio handles the 401/407 and generates a new INVITE with credentials. This increments the branch index.
As a result, the initial INVITE (Offer) gets branch_id: 0, but the final 200 OK (Answer) comes back on the authenticated branch, which is branch_id: 1.
Logs:

NATMANAGE branch_id:0 ruri: sip:12...@abc.com, method:INVITE, status:<null>, extra_id: branch_xx_0, rtpengine_manage: replace-origin replace-session-connection via-branch=extra
NATMANAGE branch_id:1 ruri: <null>, method:INVITE, status:200, extra_id: branch_xx_1, rtpengine_manage: replace-origin replace-session-connection via-branch=extra

My Questions:

Since the extra_id passed to rtpengine_manage() is different between the initial Offer (branch_xx_0) and the Answer (branch_xx_1), will this cause rtpengine to fail to match the answer to the correct offer?
If this does cause matching issues or media leaks in rtpengine, what is the recommended best practice to handle via-branch=extra when UAC authentication is involved? Should I be generating the extra_id using a different pseudo-variable that remains consistent across UAC challenges?
Thanks in advance for any insights or advice!

Best regards,

[Richard Fuchs]

On 23/04/2026 03.32, xiaofang han (hance) wrote:
> Since the extra_id passed to rtpengine_manage() is different between
> the initial Offer (branch_xx_0) and the Answer (branch_xx_1), will
> this cause rtpengine to fail to match the answer to the correct offer?

Yes it would.

In practice this is only a problem if there actually are multiple
branches of course (i.e. the same offer done multiple times with
different branch tags). If there are, and the branch tags don't match,
then rtpengine will end up guessing which answer belongs to which offer,
and will likely get it wrong.

> If this does cause matching issues or media leaks in rtpengine, what
> is the recommended best practice to handle via-branch=extra when UAC
> authentication is involved? Should I be generating the extra_id using
> a different pseudo-variable that remains consistent across UAC challenges?

Personally I can't speak to that specific scenario as I'm not familiar
with the UAC trunk auth mechanism and what side effects it may have on
branch handling. The Kamailio mailing list is probably a better place to
ask about this.

The "extra" branch tag value is meant for specific scenarios where
manual handling of the branch tags is required. Do the other mechanisms
(like `via-branch=auto`) not work for you in this case?

Cheers

[xiaofang han (hance)]

Hi rfuchs, I understand what you mean. Thank you.

[xiaofang han (hance)]

When UAC trunk authentication is enabled, decrease the transaction index by one after receiving the reply.

Cheers,