Re: Multiple double record routes in one BYE message

Hi


> Should the rr module be able to handle multiple double record routes? Or
is this an exotic use case?


It should be able to. It might seem weird, but it should work. In my
experience, kamailio removes the top Route header field when relaying - but
removes the top two if "r2" or "r2=on" is present - keeps the others, and
relays.
I have flows where there are four RR for a proxy that loops calls back to
itself and then four Route header fields when relaying a BYE, which works
because the request is relayed on the loopback interface to itself and
comes in as a new request with two fewer Route fields (so the whole request
is processed twice and makes two SIP transactions in memory, etc).
When troubleshooting this, I've two suggestions.
1. Enable siptrace (or maybe verbose logging if you can't load that
module), so that you can see exactly what happens in the "middle" section
of your ladder diagram.
2. Take a look at the Max-Forwards and Via fields in the BYE at different
hops. They can tell you if the request is actually making a different
number of hops from what you're thinking/expecting.

>From your first message, though, it looks like something is going wrong
with kamailio if it's removing lower Route values while leaving higher ones
in place. I've never seen that happen.

James

On Fri, 20 Feb 2026 at 13:42, Ibe Van de Veire via sr-users <
[email protected]> wrote:

> Hi,
>
>
>
> I do expect the same. There are no error messages or warnings related to
> the rr module in the logs.
>
> The topology hiding module is also not present.
>
>
>
> Should the rr module be able to handle multiple double record routes? Or
> is this an exotic use case?
>
>
>
> I did also try to understand how rr matches the record routes and decides
> what records to remove from the source code.
>
> But no success so far.
>
>
>
> Do you know any alternatives to double record routing that would solve our
> use case?
>
>
>
> Kind regards
>
> *Ibe Van de Veire*
>
> *System Engineer*
>
> +32 470 39 84 86
>
> +32 2 741 51 00
>
> [email protected] <[email protected]>
>
> Auguste Reyerslaan 52
>
> B-1043 Brussel
>
> [image: VRT logo] <https://www.vrt.be/>
>
> [image: VRT Banner] <https://www.bit.ly/VRTHandtekening>
>
>
>
> *Van:* Henning Westerholt <[email protected]>
> *Verzonden:* donderdag 19 februari 2026 18:34
> *Aan:* Kamailio (SER) - Users Mailing List <[email protected]>
> *CC:* Thomas Botte <[email protected]>; Ibe Van de Veire <
> [email protected]>
> *Onderwerp:* RE: Multiple double record routes in one BYE message
>
>
>
> U ontvangt niet vaak e-mail van [email protected]. Ontdek waarom dit
> belangrijk is <https://aka.ms/LearnAboutSenderIdentification>
>
> Hello,
>
>
>
> interesting problem, I would expect that Kamailio removes the route header
> starting from the top and not in the middle. Just to clarify, are you
> seeing any error messages or warnings related to the rr module in the logs?
> Do you use one of the topology hiding modules?
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Kamailio services – https://gilawa.com
>
>
>
>
>
> *From:* Ibe Van de Veire via sr-users <[email protected]>
> *Sent:* Donnerstag, 19. Februar 2026 16:44
> *To:* satyaprakash ch via sr-users <[email protected]>
> *Cc:* Thomas Botte <[email protected]>; Ibe Van de Veire <
> [email protected]>
> *Subject:* [SR-Users] Multiple double record routes in one BYE message
>
>
>
> Dear Kamailio User Group,
>
>
>
> I am working on a project that uses Kamailio as an SBC.
>
> The SBC is configured as a multihomed device. It has an interface on the
> public side of the network and an interface on the internal (lan) side of
> the network.
>
>
>
> I successfully configured the SBC to handle calls in all directions (ext
> to ext, int to ext, ext to int).
>
> However, the call termination using BYE SIP messages does not seem to work
> in some situations.
>
> When performing a call from an external device to another external device
> (hairpinning), the termination sent from the callee does not reach the
> caller.
>
> Using sngrep, I can see the following flow for the BYE message:
>
>    1. BYE leaves callee
>    2. BYE is received by public interface of the sbc
>    3. BYE is passed to the private interface of the sbc
>    4. BYE is passed to the registrar on the internal network
>    5. BYE is passed back to the internal interface of the sbc
>    6. SBC responds with 404 not here
>
>
>
> CALLEE            SBC (Public)      SBC (Private)        REGISTRAR
>
>      |                    |                 |                   |
>
>      |-------BYE--------->|                 |                   |
>
>      |                    |                 |                   |
>
>      |                    |~~~~(Internal)~~>|                   |
>
>      |                    |                 |                   |
>
>      |                    |                 |-------BYE-------->|
>
>      |                    |                 |                   |
>
>      |                    |                 |<------BYE---------|
>
>      |                    |                 |                   |
>
>      |                    |<~~~~(Internal)~~|                   |
>
>      |                    |                 |                   |
>
>      |<---404 Not Here----|                 |                   |
>
>      |                    |                 |                   |
>
>
>
> The bye message contains the following record routes in the first step:
>
> Route:
> sip:6EAVHmFKfnIZxwFfgit29EJXQU1aMHI=@SBC_PUB_IP:62530;r2=on;lr;nat=yes
>
> Route: sip:6EAVHmFKfnIZxwFfgit29EJXQU1aMHI=@SBC_LAN_IP;r2=on;lr;nat=yes
>
> Route: sip:REGISTRAR_IP;lr;ftag=DomYqO1BCMhe-giL2X3KfBsMzgI7lEa9
>
> Route: sip:SBC_LAN_IP;r2=on;lr;nat=yes
>
> Route: sip:SBC_PUB_IP:62530;r2=on;lr;nat=yes
>
>
>
> As you can see, the SBC uses double record routing to handle the
> multihomed setup.
>
> In the next step (step2 -> step3), the SBC does remove two record routes,
> and the record route list looks as following:
>
> Route: <sip:6EAVHmFKfnIZxwFfgit29EJXQU1aMHI=@SBC_LAN_IP;r2=on;lr;nat=yes>
>
> Route: <sip:REGISTRAR_IP;lr;ftag=DomYqO1BCMhe-giL2X3KfBsMzgI7lEa9>
>
> Route: <sip:SBC_LAN_IP;r2=on;lr;nat=yes>
>
>
>
> The loose_route() function seems to remove the wrong pair from the list. I
> would expect the following output:
>
> Route: sip:REGISTRAR_IP;lr;ftag=DomYqO1BCMhe-giL2X3KfBsMzgI7lEa9
>
> Route: sip:SBC_LAN_IP;r2=on;lr;nat=yes
>
> Route: sip:SBC_PUB_IP:62530;r2=on;lr;nat=yes
>
>
>
> I feel like the rr module can not handle the multiple “double record
> routes” and matches the wrong entries.
>
> RR does in fact recognize the SBC_LAN_IP as an “own IP” because in the
> last step, the last 2 parts of the double record routing are also removed.
>
> Because all of this, in the last step, the internal interface of the SBC
> receives a BYE message without any record routes.
>
> This results in a dead end.
>
>
>
> Does someone know how I can tell Kamailio to remove the right pair of
> record routes.
>
> Is there a workaround for this?
>
> Am I doing something wrong?
>
>
>
> Kind regards
>
> *Ibe Van de Veire*
>
> *System Engineer*
>
> [email protected] <[email protected]>
>
> Auguste Reyerslaan 52
>
> B-1043 Brussel
>
> [image: VRT logo] <https://www.vrt.be/>
>
> [image: VRT Banner] <https://www.bit.ly/VRTHandtekening>
>
>
>
>
>
> -- Disclaimer --
> Vlaamse Radio- en Televisieomroeporganisatie
> Auguste Reyerslaan 52
> 1043 Brussel
>
>
>
> nv van publiek recht
> BTW BE 0244.142.664
> RPR Brussel
> *VRT Gebruikersvoorwaarden <http://www.vrt.be/gebruiksvoorwaarden%20>*
>
> -- Disclaimer --
> Vlaamse Radio- en Televisieomroeporganisatie
> Auguste Reyerslaan 52
> 1043 Brussel
>
> nv van publiek recht
> BTW BE 0244.142.664
> RPR Brussel
> VRT Gebruikersvoorwaarden <http://www.vrt.be/gebruiksvoorwaarden>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!