Please check INVITE message from the sbc-ext.5060 > provider.5060
Here no Record-Route header present

06:42:30.210381 IP (tos 0x60, ttl 64, id 3430, offset 0, flags [none], proto UDP (17), length 1377)
    sbc-ext.5060 > provider.5060: [udp sum ok] SIP, length: 1349
	INVITE sip:972xxxxxxx@xxxxxxxxxxx:5060 SIP/2.0
	Via: SIP/2.0/UDP xxxxxxxxxxxxxxx;branch=z9hG4bK2eca.40a7054ddf5f0d12a23adbd4f8f501b8.0
	X-OIP: 192.168.2.2
	X-SBC-Check: accepted
	Max-Forwards: 68
	From: "Dustin Marquess" <sip:214xxxxxxx@sbc.xxx.net>;tag=rm74ep7yFm4mm
	To: <sip:972xxxxxxx@sbc.xxx.net>
	Call-ID: 68dc6b49-cc32-123e-f9a0-f72abab18dff
	CSeq: 100863083 INVITE
	User-Agent: FreeSWITCH
	Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
	Supported: path, replaces
	Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
	Content-Type: application/sdp
	Content-Disposition: session
	Content-Length: 327
	X-FS-Support: update_display,send_info
	Remote-Party-ID: "Dustin Marquess" <sip:214xxxxxxx@xxx.net>;party=calling;screen=yes;privacy=off
	X-Group-SBC: 1001
	X-Routing-SBC: tr2un 
 Contact: <sip:btpsh-685b9a1a-a0c-1@xxxxxxxxxxxxxxx>

And please check "180 Ringing" from sbc-int.5060 > pbx.5080 

06:42:31.265799 IP (tos 0x60, ttl 64, id 39495, offset 0, flags [none], proto UDP (17), length 994)
    sbc-int.5060 > pbx.5080: [udp sum ok] SIP, length: 966
	SIP/2.0 180 Ringing
	From: "Dustin Marquess" <sip:214xxxxxxx@sbc.xxx.net>;tag=rm74ep7yFm4mm
	To: <sip:972xxxxxxx@sbc.xxx.net>;tag=gK0aa84cd5
	Call-ID: 68dc6b49-cc32-123e-f9a0-f72abab18dff
	CSeq: 100863083 INVITE
	Contact: <sip:xxxxxxxxxxx:5060;did=19d.2a212d95;transport=udp;alias=xxxxxxxxxxx~5060~1>
	Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,OPTIONS
	l: 220
	Content-Disposition: session; handling=required
	c: application/sdp
	Via: SIP/2.0/UDP 192.168.2.2:5080;received=192.168.2.2;rport=5080;branch=z9hG4bKrS9aSHDy40v8S
	Record-Route: <sip:xxxxxxxxxxxxxxx;r2=on;lr;ftag=rm74ep7yFm4mm;proxy_media=yes;nat=yes>,<sip:192.168.2.3;r2=on;lr;ftag=rm74ep7yFm4mm;proxy_media=yes;nat=yes>
	P-SR-XBranch: z9hG4bK2eca.40a7054ddf5f0d12a23adbd4f8f501b8.0

Here is added Record-Route headers but this headers is not present on the same message from the provider.

Looks like "record_route()" called on reply route, but this is not possible according function decscription
https://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.f.record_route

You need:
1) to make sure record_route() called during INVITE processing;
2) try find reason why Record-Route headers added durirng "180 RInging" processing.


On Wed, Jun 25, 2025 at 10:01 AM Dustin Marquess <dmarquess@gmail.com> wrote:
John,

This reply probably isn't going to be helpful, since I obviously misread your entire email. For some reason I was thinking enable_double_rr, so I set:

modparam("rr", "enable_double_rr", 2)

And tried again, same issue.

Sergey asked for the SIP messages. I didn't want to spam the list, so I put them at https://fdf.net/calls.txt

It's late now, I'll try record_route_preset in the morning and try again. 🤦

Thanks!
-Dustin

On Tue, Jun 24, 2025 at 5:17 AM Who AmI <myfriendjohn1@gmail.com> wrote:
Just to add here, double rr with putting the interface details in them using the record_route_preset (https://www.kamailio.org/docs/modules/devel/modules/rr.html#rr.f.record_route_preset) might be the way to go here. 

This will allow the BYE to have the correct routes to get back out hopefully. 

So on initial invite from private: in rr header 1st rr is from public, 2nd rr is private
and on initial invite from public: in rr header 1st rr is from private, 2nd rr is public

This orders the rr headers so on the way back they come in correctly if that makes sense.

I do this at the initial Invite and it works fine for me, but your mileage may vary. 

Hope this helps,

John. 

On Tue, 24 Jun 2025 at 10:25, Sergei Safarov via sr-users <sr-users@lists.kamailio.org> wrote:
Will be fine to check SIP messages.
Here is important Route, Record-Route and contact header values.

Sergey.

On Mon, 2025-06-23 at 20:24 -0500, Dustin Marquess via sr-users wrote:
All,

I've tried searching and have found similar posts before, but I have yet to find a real 'solution'.

I'm running Kamailio 6.0.1 & RTPEngine 13.3.1.7 (on a Linux VM)  as a "SBC" (at home) using the config from: 
https://github.com/voiceboys/sbcOS/blob/version_2.0/var/www/html/alpine/config/a0%3A36%3A9f%3Ae7%3A6a%3Ae2/etc/kamailio/kamailio.cfg

Except that I've added the following:

mhomed=1
modparam("rr", "force_send_socket", 1)

The SBC is dual-homed: one interface on the local LAN and another interface directly on the Internet/WAN (real public IP).

Everything works fine, EXCEPT if the remote end (the side on the WAN/Internet) hangs up first. If they do, the BYE never makes it past Kamailio to the local PBX and/or phone.

https://users.openser.narkive.com/1aK7n8Il/sr-multihomed-kamailio-and-enable-double-rr#post8 suggests to use $sht to save the information needed, but I have no clue where in the config to put that.

Any help would be greatly appreciated.

Thanks!

-Dustin