Hello,

there is another proxy in the path of SIP signalling in the provider side because it adds Record-Route:

Record-Route: <sip:182.33.174.10;lr;ftag=as0b42eef3>

Having the ftag parameter, likely to be another Kamailio or one of its forks. But that proxy does wrongly nat traversal processing, replacing the contact address with the source ip and port (the old style with fix_nated_contact()), but nat traversal should be done only when the proxy is in the immediate vicinity of the NAT router, which is not the case here, so it should do no nat traversal.

If you can change that with the provider, then yours should be fine. If not, you can add contact alias with set_contact_alias() function to the requests/replies sent to the provider and then handle requests within dialog with handle_ruri_alias().

Alternative could be to use topos module, but it adds processing overhead. Other alternatives: use dialog module and recover the contact uri from it, or store the contact uri in a htable and recover it when needed.

Cheers,
Daniel

On 16.01.25 18:50, Barry Flanagan via sr-users wrote:
Hi folks,

Trying to hook up a new endpoint but am having an issue. Kamailio is in front of an Asterisk box. 

They send an INVITE, we send 100, then 200 OK. However, when they send their ACK, the RURI is not set to the Contact of the 200, instead it is<number>@<proxy ip>. This causes the ACK to get routed to the proxy itself and the call fails. 

82.160.190.100:5060 = Kamailio IP Port
198.201.240.242:5080 = Asterisk IP/Port
182.33.174.10:5060 = Provider endpoint

The far endpoint say they cannot fix the RURI - should I be able to handle this ACK below? My understanding is the ACK's RURI should be the Contact of the 200 OK.

200 OK sent from us to the Provider (Contact shows correct URI)
=========================================================
2025/01/15 17:14:49.470634 82.160.190.100:5060 -> 182.33.174.10:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 182.33.174.10;branch=z9hG4bKefc7.ad07f2d3.0
Via: SIP/2.0/UDP 182.33.174.39:5060;received=182.33.174.39;branch=z9hG4bK5bbf9591;rport=5060
Record-Route: <sip:1800715080@82.160.190.100:5061;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>
Record-Route: <sip:1800715080@82.160.190.100;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>
Record-Route: <sip:182.33.174.10;lr;ftag=as0b42eef3>
From: "0737965510" <sip:0737966610@182.33.174.39>;tag=as0b42eef3
To: <sip:1800715080@82.160.190.100>;tag=as4133584e
Call-ID: 480dc17b3f88516f364778dc4b2528da@182.33.174.39:5060
CSeq: 102 INVITE
Server: Asterisk PBX 18.9.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Contact: <sip:1800715080@198.201.240.242:5080>
Content-Type: application/sdp
Content-Length: 314 ,

ACK Reply from Provider to Us (RURI points to Kamailio ip:port now
===========================================================
2025/01/15 17:14:49.478119 182.33.174.10:5060 -> 82.160.190.100:5060
ACK sip:1800715080@82.160.190.100:5060 SIP/2.0
Via: SIP/2.0/UDP 182.33.174.10;branch=z9hG4bKefc7.ad07f2d3.2
Via: SIP/2.0/UDP 182.33.174.39:5060;received=182.33.174.39;branch=z9hG4bK55656469;rport=5060
Route: <sip:1800715080@82.160.190.100;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>,sip:1800715080@82.160.190.100:5061;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>
Max-Forwards: 69
From: "0737965510" <sip:0737966610@182.33.174.39>;tag=as0b42eef3
To: <sip:1800715080@82.160.190.100>;tag=as4133584e
Contact: <sip:0737965510@182.33.174.39:5060>
Call-ID: 480dc17b3f88516f364778dc4b2528da@182.33.174.39:5060
CSeq: 102 ACK


Thanks

-Barry


__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!



-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com